"The problem that I have with them today is that... C++ is too
complicated. At the moment, it's impossible for me to write portable
code that I believe would work on lots of different systems, unless I
avoid all exotic features. Whenever the C++ language designers had two
competing ideas as to how they should solve some problem, they said
"OK, we'll do them both". So the language is too baroque for my taste.
But each user of C++ has a favorite subset, and that's fine."
In fact, they do so even better than they did back then. E.g. I eagerly anticipated C++11, but virtually every codebase that's older than three or four years and not a hobby project is now a mixture of modules that use C++11 features like unique_ptr and modules that don't. Debugging code without smart pointer semantics sucked, but debugging code that has both smart pointer semantics and raw pointers sucks even harder.
There's a huge chasm between how a language is standardized and how it's used in real life, in non-trivial projects that have to be maintained for years, or even decades.
I am currently on a team maintaining a giant codebase and migrating to C++11 (and beyond) for a new compiler. We do not have issues with the deprecation of auto_ptr, the use of raw pointers or general debugging COM problems. The code base is 20 years old and we do not complain to debug it.
Debugging pointers seems a poor reason to criticize an entire language!
C++ may be complicated but the English language is also complicated; just because people tend to use a smaller vocabulary than others doesn't make the language irrelevant or worthless.
Looking at how English has been used to create a raft of rich and diverse poetry, plays, prose and literature in general, the same should be applied to C++ because the unique use of it in a variety of varying circumstances surely is its beauty.
> Looking at how English has been used to create a raft of rich and diverse poetry, plays, prose and literature in general, the same should be applied to C++ because the unique use of it in a variety of varying circumstances surely is its beauty.
I don't think this is a valid argument, though. Natural languages have to be rich. Programming languages should be terse and concise because we have to keep most of them in our heads at one time and our brain capacity is limited. You don't need to know all of English/French/Romanian but you kind of need to know all of C++/Python/Javascript to do your job well when developing C++/Python/Javascript.
I think the C++ designers lately kind of agree with me but the backward compatibility requirements are really stringent and they can't just deprecate a lot of the older features.
That was obviously (I hope?) just one example. C++ has a huge set of overlapping features, some of which have been introduced as a better alternative of older features. Their interaction is extremely complex. It's great that your team manages to steer a large, old codebase without trouble, but most of the ones I've seen can't, and this complexity is part of why they can't.
Looking at contrieved legal texts, which is a better comparison with code than poetry, I don't agree. I don't even agree that there would be the english language.
Legalese uses a ton of latin ididoms, arcane rights and philosophies. This is comparable to the cruft of C or C++ standards. For a microkernel of some thousand LOC you shouldn't need a multi-paradigm language.
seL4 did it in Haskel, which is a step in the right direction. Then it was ported to a provably safe subset of C.
A large chunk of his argument doesn't hold at all. This:
"At the moment, it's impossible for me to write portable code that I believe would work on lots of different systems, unless I avoid all exotic features."
Is just not remotely true anymore. Modern toolchains entirely obsoleted that. Modern C++ compilers are nothing like what Knuth used in 1993.
If anything it's easier to write portable C++ than it is portable C due to C++'s STL increasingly covering much of the POSIX space these days.
"The problem that I have with them today is that... C++ is too complicated. At the moment, it's impossible for me to write portable code that I believe would work on lots of different systems, unless I avoid all exotic features. Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said "OK, we'll do them both". So the language is too baroque for my taste. But each user of C++ has a favorite subset, and that's fine."
In fact, they do so even better than they did back then. E.g. I eagerly anticipated C++11, but virtually every codebase that's older than three or four years and not a hobby project is now a mixture of modules that use C++11 features like unique_ptr and modules that don't. Debugging code without smart pointer semantics sucked, but debugging code that has both smart pointer semantics and raw pointers sucks even harder.
There's a huge chasm between how a language is standardized and how it's used in real life, in non-trivial projects that have to be maintained for years, or even decades.