> those 5 lines generate hundred thousands of lines of code behind the scene.

That's part of the problem; most of the time, the "thousands of lines of code" that are created from type-generic code have a lot of useless duplication, and the compiler has trouble coalescing the duplicated and redundant code (I don't even think a serious attempt is made, AIUI). There's a lot of scope for improvement.

There is an alternative: writing simple C++ instead of Modern C++, or even using plain C.

Then you increase the time you need to spend writing your program. You will also most likely end up cutting some corners, and the result will be of questionable quality in one way or another.

Holding in my brain and using all these "modern" features increases the time I need to think about code, data, and algorithms, and that's usually where most coding spends my time -- thinking.

And "modern" compile times... increasing the time between results and further thinking and writing. Don't forget that; the article doesn't.

And "modern" debugging... well, good luck.

Well, people have been known to hold in their brains information pertinent to their trade. Professional training helps, too. I can only guess the extent of what a mathematician, a physicist or a medical doctor must remember to be successful in what they do.

Musicians are able to hold complete compositions on their heads, some of them several minutes long.

It is all a matter of focus and pratice.

Code is not music. When thinking about code you must keep track of possible branches executed code might take and properties of the physical machine it runs on. C++'s complexity can hide code's underlying logic and make some types of bugs more common.

As someone that learned music and several instruments before getting into computing, and having spent several evenings with musician friends, I beg to differ.

Writing a composition score for an orchestra falls under similar conditions, how each instrument sounds, how they sound together, when each comes and goes into play, and so forth.

Most complaints about C++'s complexity can be equally applied to languages that look deceivably simple like Python.

Complexity is like thermodynamics, it gets pushed somewhere, if it isn't on the code, it gets shoved either into boilerplate, or architecture.

If we can compare C++'s complexity to Python's, then C++ has lost its way. You're saying the same thing as the article and my comment, that C++ is trying to hide complexities, and we're arguing that doing so is instead adding more complexities.

Sure, Python makes it easy to listen on a socket, parse HTTP, and send HTML down -- hiding a lot of complexity. But it's made it impossible to do so very efficiently and scale up. Try and dive into Python's stack for that (Re: 'hold in your brain all the "modern" features'), and you'll get lost in a myriad of CPython (or whatever flavor you choose) generics and indirection that you can't optimize. Startup times matter, because you are all about hiding complexities and went "serverless" and constantly eat cold starts (Re: '"modern" compile times').

I think it's apt to compare "modern" C++ as moving towards something like Python. Not great for a lot of applications of C++ (Re: games, in the article and my focus) or its perceived goals as a better C. That's the point. Many of the C++ additions are being slagged for making a worse C. It's looking nothing like C any longer. It's a giant ball of complexity with dozens of ways of doing the same thing and hoping you learned them all.

This is why I think languages like Rust (or even Go) get a lot of attention. They have a good interop story with C, like C++ has. And if we're going to learn a bunch of non-C looking language grammar, C++ is doing a worse job.

My point about Python is that it is always presented as begginer friendly language, yet is it quite complex for anyone that whats to fully master it.

The language + standard library + C API references are around 2392 pages, not counting the other minor documentation like the 500 PEPs, release notes and differences across each Python release, even minor ones.

Then there is the whole set of meta-classes, decorators, mixins, generators, operator overloading, multiple inheritance, abstract classes, fp like programming and much more.

The big difference to C++, is that the community doesn't care about performance, leaving the PyPy guys a Quixotic battle regarding adoption, which isn't the case with C++ compilers.

Even C isn't as simple as many think, with its 200+ documentated cases of UB, and the days that C mapped 1:1 to PDP 11 Assembly are long gone.

How C code looks like, and what gets generated via auto-vectorization, GPGPU code, SIMD intrisics are very much two worlds appart.

You're absolutely right that Python has also become more and more complex and often not for the best.

As for Python performance, on the contrary, I think there was a large portion of the Python community that did care during my years with it. I think 3.x adoption was hurt a lot by being slower than 2.7.x. I think a lot of the community jumped ship to Golang or similar, for both performance and complexity reasons.

I would absolutely love for C++ to tackle C UB or make incompatible insecure C. Instead, we get stuff like Ranges, time and again. I'm struggling to understand what complexities you are finding it covers that are worth supporting forever, committing gray matter, committing productivity loss, committing debug travesties, &c. Say I'm a musician that can hold complete compositions in my head; why should I commit this feature and its baggage to memory?

> Say I'm a musician that can hold complete compositions in my head; why should I commit this feature and its baggage to memory?

Because C++ is the sane alternative to C on OS SDKs, HPC, GPGPU programming, regarding portable code.

Now, ideally as memory safe systems advocate, I would like to see more of Swift, .NET Native, D, Go, Rust, Java (AOT), OCaml, ...

However, when using languages not endorsed by vendors, it always means inferior IDE/debugging experience, lacking IDE support, manually writting FFI integration code, tracking down which layer is responsible for certain bugs,..., so switching to something that looks easier turns out to become harder in the long run as the whole stack experience suffers.

There are already signs of OS vendors finally improving a bit the situation, with Apple continuously pushing for Swift, Google restricting what is at all possible to do with NDK, Windows teams focusing on .NET Native in spite of C++/WinRT (nee C++/CX), Rust adoption by all big names.

However we are still at least a decade away of any of those languages enjoying a similar industry position in platform SDKs as C++ enjoys nowadays, after 30 years fighting against C.

So I rather keep that baggage in memory, while doing my best to use modern C++, alongside the other more type safe languages, also part of the respective platform SDKs, than additing additional attrition to my production code toolbox.

I imagine my opinion is not unique.

As someone who also learned music and played several instruments (violin, piano) before getting into computing I still don't get what's the point of comparing musical memory to being able to recall programming language rules. Programming is largely about managing complexity and our mammal brains are not very good at keeping track of all the exceptions and special cases a language like C++ is full of (as opposed to remembering music). Just to be clear: Yes, writing music, especially for an orchestra, IS hard and complex.

By simple you mean without the STL?

C with polymorphism

Including virtual/dynamic polymorphism?

If you really have a serious performance problem, the answer these days is more likely to be a GPU, DSP, FPGA, or even an ASIC. The era of C++ on CPUs being the right solution for most high performance computation problems is coming to a close now that Moore's Law is ending.

If you deploy the code on a large number of machines, especially out of your control, most of those don't apply. There is a large scale of problems that require/benefit from optimised non-GPU code: - OS and related tools - applications (e.g. image processing, spreadsheets, engineering applications) - browsers - games - compilers - low level libraries - databases

Yyou are probably using many of those and would not enjoy them being slower.

Even though I do like C++, I kind of agree.

As Wirth languages fanboy, I belive that if Java 1.0 had AOT compilation from day one, instead of leaving it to commercial third parties, and proper value types, the amount of C and C++'s adoption would have looked much different.

I wonder what Wirth would have to say about Java...

As you might imagine, not kind words.

"Modern languages like Java and C# may well be superior to old ones like Fortran, PL/I, and C, but they are far from perfect, and they could be much better. Their manuals of several hundred pages are an unmistakable symptom of their inadequacy. Engineers in industry, however, are rarely free from constraints. They supposedly they must be compatible with the rest of the world, and to deviate from established standards might be fatal."

https://www.inf.ethz.ch/personal/wirth/Miscellaneous/IEEE-An...

"In 1995 Sun Microsystems presented its language Java , fully 6 years after Oberon. It incorporated much of the "philosophy" of Oberon, but, alas, chose the style and syntax of C. Around 2000 Microsoft released its language C# as a strong competitor of Java, and Google followed in 2007 with its language Go, even more strongly following (the 18 years old) Oberon. The crux with these languages, which all became wide-spread due to strong industrial support, is their size and complexity. The ambition to provide everything to everybody prevailed and let them grow into complex bodies difficult to master."

https://www.inf.ethz.ch/personal/wirth/Miscellaneous/Compute...

Using complexity as an argument against Go is not really accurate in my point of view.

It is, because after Modula-2, Wirth's goals have been to produce the minimalist, type safe, systems programming language.

Oberon-2, Concurrent Pascal, Active Oberon and Zonnon variants were designed by students or together with ETHZ fellow researchers.

Oberon is smaller than Modula-2, and Oberon-07 lost features on each language revision.

So from our point of view Go isn't complex.

From my point of view Go still lacks several features, which Go 2.0 will kind of address.

However, from Wirth's point of view, which after being retired was still trying to design such minimal language, Go is indeed complex.

You can see this by reading the language reports.

https://www.inf.ethz.ch/personal/wirth/Oberon/index.html

This shouldn't have been downvoted.

I totally disagree, I think that era has been over for the last 20 years.

I keep coming back to a talk by Daniel J. Bernstein, that the assumptions computer science teaches about performance are wrong. His claim is for real programs most code is ice cold and a tiny percentage is hot. And that's getting worse not better as time goes on.

What important is; correctness, latency, compile time. Not raw speed.

In my experience that claim is very true before you fire up your profiler. But once you've optimized your program for a bit the profile gets a lot flatter.

I think if your programs profile is flat it means none of your code is actually in the hot path. It's buried behind library functions and OS calls.