4 ms·

Maybe we should just put the conclusion of these sorts of discussions somewhere in here as well: This criticism applies essentially to any higher abstraction,

by iofj 10y ago

Maybe we should just put the conclusion of these sorts of discussions somewhere in here as well: This criticism applies essentially to any higher abstraction, not just to C++. Higher abstractions make it easier to do complex things, and thus they scale to bigger total software systems. The maximum complexity you can control using C++ is higher than the maximum complexity you can build into a C program before things spiral out of control. However, higher abstractions work by figuring things out for you. Code in the libraries or compiler will decide when things happen, in what order, and how they relate to one another. This has 2 consequences of note. Firstly they make it very hard to predict when things will happen. This is very good: you don't have to know or care in the "vast majority of cases". But yes, God help you when you do need to know. I find numpy code is similar: you almost never have to care about the internals, but when you do, the rabbit hole is miles deep. In a related effect, abstractions make it hard to predict the exact sequence in which things will happen, and mostly this does not matter. When it does matter, it is really, really hard to find. Second, those abstractions mean that tiny changes in the source code frequently result in large changes in the sequence in which things happen. So tiny, seemingly unrelated changes in the source code can result in very different runtime behavior. These things are very good, and very bad, depending on your viewpoint. You want to get complex new things working ? Higher abstractions are your friend. You want to get complex new things working fast ? C++ is your friend. If on the other hand, you want a stable, productionized and bug-free implementation of simple processes that you have to maintain and keep running and keep stable and predictable for long periods of time ? Abstraction is the enemy. It will bite you in the ass time and time again. Don't use anything high-level. There's a related problem. You need to know higher abstractions. When working with C++ math libraries or numpy you quickly find this out. If you don't have a very good math education, those abstractions will make very little sense indeed. This means that a large cohort of programmers without the old-style "math first, programming second" education quickly run into insurmountable issues. Not because the issues are necessarily hard to a math Phd, but because they don't have a math background. Hating abstractions is far easier than fixing your math understanding. The right tool for the job. As for the programmers, there are many incredibly good C++ programmers. As a rule of thumb, any successful long-lived language will have tons and tons of bad programmers using it. This has to do with managers trying to cut costs and the resulting effects on the marketplace for developers. It's (sadly) beginning to be true for python these days. Doesn't have anything to do with the language and it won't affect you if you don't screw up your hiring.

benjcooley 10y ago
Don't use abstractions.. unless they're high enough that the compiler or runtime can optimize their implementation better and faster than you could - and the compiler/runtime environment actually does this (naturally C++ doesn't and can't). Higher level abstractions aren't necessarily the enemy of optimal code. Modern tracing jitted JS runtimes are great examples of how higher level code can be transformed under the hood by an intelligent compiler into more efficient concrete code at compile/runtime. The problem with C++ isn't that it exposes abstractions, it's that there is no way to make the abstractions responsive to where/how they are used, no simple automated way to optimize by use case, and there is no reliable tooling that exposes the cost of abstractions during development thus concealing their potential costs. That being said.. abstractions are probably the greatest single potential untapped source of massive performance gains as it allows performance optimizations to be automated by machine learning and runtime performance analysis.

by iofj 10y ago

benjcooley 10y ago

Don't use abstractions.. unless they're high enough that the compiler or runtime can optimize their implementation better and faster than you could - and the compiler/runtime environment actually does this (naturally C++ doesn't and can't). Higher level abstractions aren't necessarily the enemy of optimal code. Modern tracing jitted JS runtimes are great examples of how higher level code can be transformed under the hood by an intelligent compiler into more efficient concrete code at compile/runtime. The problem with C++ isn't that it exposes abstractions, it's that there is no way to make the abstractions responsive to where/how they are used, no simple automated way to optimize by use case, and there is no reliable tooling that exposes the cost of abstractions during development thus concealing their potential costs. That being said.. abstractions are probably the greatest single potential untapped source of massive performance gains as it allows performance optimizations to be automated by machine learning and runtime performance analysis.