I am not sure whether C++ is a good target for this criticism. The most frequently used libraries (STL and Boost) don't use class hierarchies extensively.
Also, some domains are easily modelled using class hierarchies, such as GUI widgets, where more specialized widgets override or extend behaviour (or painting) of more general widgets. I have programmed Qt for years, and the class hierarchy model works exceptionally well there.
Algebraic datatypes and pattern matching have been around for years,
They come with advantages and disadvantages. E.g. adding a constructor potentially requires you to update every pattern matching case. This can get quite ugly quickly if you add a constructor to some commonly-used library.
I do like them in cases where you know up-front what constructors there will be. E.g. lightweight error handling with Maybe/Either. Or when their visibility is limited.
Parallel programming has been around for years, and is becoming CRITICAL for modern applications. If your language doesn’t EASILY support it, it sucks.
Luckily, parallel programming is very easy in C++ using e.g. OpenMP or Intel TBB. In the case of OpenMP it is usually a matter of adding pragmas to your embarrassingly parallel loops. It is concurrency that is more of a problem. C++11 has standardized lot of 'old-world' constructs for threading, but it's not as if you can find a mature technology like Erlang's OTP or Akka on top of C++.
C++ has a RIDICULOUS amount of boiler plate.
I agree that there is a lot of boilerplate. But then the author goes off ranting about constructors. I don't find it that convincing. There used to be a lot of boilerplate in iterator and <algorithm> use, but C++11 makes things much more compact with auto et al. IMO one of the biggest sources of boilerplate in C++ is writing libraries such that you have ABI compatibility. You usually end up using PIMPL for every class, maintaining two versions (PIMPL and actual) of each class.
Then, there are other languages that come with a lot of boilerplate, such as Java, but the difference is that Java is much easier to parse, process, and incrementally compile. As a consequence, Java IDEs tend to be much better at code generation and refactoring than C++ IDEs.
The same problems that make highly-parallel code a nightmare in C++ also make it an unsuitable language for security-critical, or mission-critical projects.
Yes, it is extremely easy to blow your foot of. Forgetting a 'virtual' keyword can lead to subtle, difficult to find bugs. You can read or write beyond bounds by accident. Etc. These are well-known critiques. Use C++ (or another unsafe language) when it's necessary to trade off safety for performance. Rust will probably bring performance while sacrificing less safety. But it's not there yet.
I am not sure whether C++ is a good target for this criticism. The most frequently used libraries (STL and Boost) don't use class hierarchies extensively.
Also, some domains are easily modelled using class hierarchies, such as GUI widgets, where more specialized widgets override or extend behaviour (or painting) of more general widgets. I have programmed Qt for years, and the class hierarchy model works exceptionally well there.
Algebraic datatypes and pattern matching have been around for years,
They come with advantages and disadvantages. E.g. adding a constructor potentially requires you to update every pattern matching case. This can get quite ugly quickly if you add a constructor to some commonly-used library.
I do like them in cases where you know up-front what constructors there will be. E.g. lightweight error handling with Maybe/Either. Or when their visibility is limited.
Parallel programming has been around for years, and is becoming CRITICAL for modern applications. If your language doesn’t EASILY support it, it sucks.
Luckily, parallel programming is very easy in C++ using e.g. OpenMP or Intel TBB. In the case of OpenMP it is usually a matter of adding pragmas to your embarrassingly parallel loops. It is concurrency that is more of a problem. C++11 has standardized lot of 'old-world' constructs for threading, but it's not as if you can find a mature technology like Erlang's OTP or Akka on top of C++.
C++ has a RIDICULOUS amount of boiler plate.
I agree that there is a lot of boilerplate. But then the author goes off ranting about constructors. I don't find it that convincing. There used to be a lot of boilerplate in iterator and <algorithm> use, but C++11 makes things much more compact with auto et al. IMO one of the biggest sources of boilerplate in C++ is writing libraries such that you have ABI compatibility. You usually end up using PIMPL for every class, maintaining two versions (PIMPL and actual) of each class.
Then, there are other languages that come with a lot of boilerplate, such as Java, but the difference is that Java is much easier to parse, process, and incrementally compile. As a consequence, Java IDEs tend to be much better at code generation and refactoring than C++ IDEs.
The same problems that make highly-parallel code a nightmare in C++ also make it an unsuitable language for security-critical, or mission-critical projects.
Yes, it is extremely easy to blow your foot of. Forgetting a 'virtual' keyword can lead to subtle, difficult to find bugs. You can read or write beyond bounds by accident. Etc. These are well-known critiques. Use C++ (or another unsafe language) when it's necessary to trade off safety for performance. Rust will probably bring performance while sacrificing less safety. But it's not there yet.