Hacker News Reader

Comment by DoofusOfDeath | Hacker News Reader

Sometimes C++'s evolution reminds me of the quote from Antoine de Saint-Exupery: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." [0]

When the topic of C++'s huge and growing complexity comes up, opinions mostly fall into two groups: (a) the language is way way too complex, and (b) ... yeah, but modern C++ is really clean and you can just ignore all the complexity that's been retained for backwards compatibility.

I don't find (b) persuasive because every line of C++ code is interpreted by the entire language standard. If (b) really is true, then I'd be interested in seeing a new language that has only the subset of the C++ standard considered "modern". If that language was actually useful, I'd eagerly use it in practice.

[0] https://www.brainyquote.com/quotes/antoine_de_saintexupery_1...

View on HN

Stroustrup has written quite a bit fighting against complexity:

> There are two fundamental ways of approaching the unavoidable uncertainty in a design:

> • add “improvements” until everybody feels well served

> • cut until there is nothing left to cut and all there is left is principled and fundamental

> After both approaches, experience will show the need for changes (pre-release) and additions (all we can do post-release). I clearly favor the second approach and consider it proper engineering based on principles and feedback. I consider the former hacking and politics. In a standards process, compromises are necessary, but we must try to ensure than compromises are not between irreconcilables or just union-of-features bloat.

He continues:

> Stability is a feature as well as a serious design constraint. [....] I can summarize most people’s attitude:

> • “C++ is too complex. We need to make it smaller, simpler, and cleaner.

> • And please add these two features.

> • And whatever you do, don’t break my code!”

Source: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p196...

> I can summarize most people’s attitude

I’m skeptical that there is a significant body of critics that share these patently conflicting views. More likely there are different groups who each value one of these, or more likely still, lots of individuals like me who are fine with specific, entirely consistent concessions from each of these major categories. For example, I would like to see C++ support some sane build and package ecosystem and I’m ok if it breaks my projects. I would also be happy to do away with the C compatibility requirements.

It would probably be too much to ask to re-evaluate every design decision that was predicated on C compatibility, but I would be okay with reevaluating them gradually over decades, deprecating language features here and there. In general we need to get rid of the idea that we only need to write software once and then every future version of the toolchain will support it. Instead I would like to see a world where the language changes gradually and project maintainers simply have to make small, almost mechanical changes every 5 years or so.

> I’m skeptical that there is a significant body of critics that share these patently conflicting views.

If I take a serious look at my own C++ needs I do find myself having those contradicting views. Essentially what I find is that for areas of the language that do not pertain much to my day to day work I'm fine with "simplifying" (even if it means removing features, because I don't need those features) but for the things I work on (which I'll be the first to admit are likely quite rare in the general C++ population) it would be a deal breaker if the features that I use but most other people don't get removed.

Those aren’t contradictory views; you are consistent, but your views aren’t consistent with those of the “other people” you refer to, which is my point.

I think it depends on how you frame it. "If we could just add this one feature, we could get rid of these five crufty features that I think are obviated by it" is a fairly common sentiment in my experience.

The problem is that everyone's ideal subset of C++ is different because everyone has different requirements!

"A lot of software developers are seduced by the old ‘80/20’ rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

Unfortunately, it’s never the same 20%."

https://www.joelonsoftware.com/2006/12/09/simplicity/

C++ is probably a little different. There’s a lot of ways to do things due to accumulated cruft, for example. I’d wager at least a good 20% of C++/STL is to some degree redundant.

Worth keeping in mind: Joel's pulling stats from a very dark spot, located somewhere behind.

In reality, there are common features, and there are rare features - there's just rarely a product manager willing to give up users for clarity of vision.

> but modern C++ is really clean and you can just ignore all the complexity that's been retained for backwards compatibility.

I actually think the opposite. Modern C++ is painful, but a subset of it, mostly the stuff prior to the introduction of templates, is very useful and clean.

But I also think this is a strength of C++: you really can realistically decide what parts are appropriate to use in a project and what parts to ignore.

idk, I think some of the things added after templates were added in 1990 are pretty useful, like `bool`, `static_cast`, `std::vector`, etc

I'd also add unique_ptr. Being able to have a heap-allocated object under RAII is a godsend.

Yes, I agree. My objection is really the template syntax itself. There have been many things added over the years that are good.

With due respect - prior to the introduction of templates is _super old_ C++.

"Modern C++" means C++11 and later versions. It uses templates extensively, leaning towards more compile-time computation rather than relying on run-time polymorphism.

Could this essentially be achieved with a linter rather than a whole new language?

I am sort of agree.

In practice however I use comfortable subset of it and then it is simple. This is my (b). I know that everyone has their own idea about what said subset should be but I do not participate in large C++ teams and hence it is not a real problem for me.

So yes in general you're right, in practice some people are ok. What's the real percentage of those I have no idea.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses" is his other famous quote. I agree with you that (b) isn't that persuasive. C++ is one of those languages where the organisation using it kind of has to enforce their own subset for things to stay sane.

Rust is close enough to that language.

Language keywords are like ingredients. You don't have to use it all when cooking. Something that most organizations and folks don't do is constraint what they are going to use. They figure, it's all out there for the taking, so use it all. It's always a pleasure when one comes across a group that have thought deeply about the nature of the work and selected a subset of the language they need to use. This is very important when dealing with a huge beast like C++. Just like if you go to AWS, figure out what you need, don't try to use all their services, decide on what you will not use too.

C--

C-- is a pretty weird language basically only useful as a backend for GHC.

I was utterly unaware that it was real. I was in fact trying to make a joke. Thanks for the enlightening.

Reply on news.ycombinator.com