Let's start with C. I work on Linux because aside from its security, stability, and the genius of the BASH shell, it has not devolved into a marketing platform for a giant corporation. There's a good reason it powers nearly every web site and actually, I believe, every supercomputer. So with those accolades in mind, let's consider the first of the icons: Linus Torvalds. He might be difficult to get along with, at lest according to reports, but he had the flash of a vision that he pursued to what became the predominant operating system in the world. (In case you didn't know, if you have an Android phone, that's really Linux under the hood.) Linux, at least for the most part, is written in C.

I remember when I first learned C. I paid $100 for the DeSmet C compiler suite, and and was immediately impressed with how concise the language is. Though not nearly as wordy as COBOL, both FORTRAN and BASIC took a lot more typing. I could make C do all kind of things and hardly have to type anything at all. It was spectacular! DeSmet C was at least very close to the original Kernighan and Ritchie C, which was permissive enough to allow a programmer to introduce all manner of elegant and difficult bugs, but that was OK. It was like programming in assembly but a whole lot faster.

I can see why Torvalds is a C advocate: it's concise, efficient, and compiles fast.

But he hates C++.

That is a position I have trouble understanding. I once said in a job interview that C++ was the Language of the Gods, a claim which received an enthusiastic response even though I did not get the job. Not surprisingly, the second icon is Bjarne Stroustrup, its creator. I don't know what happened to my copy of the original "The C++ Programming Language," but I actually read it like a novel, stunned at the what I perceived to be the sheer genius of some of its constructs. In fact, I went through the book again, maybe a third time, discovering awe-inspiring wisdom that I had missed the first time through. A brilliantly constructed language. Just think: if you use objects and exceptions wisely, you can virtually eliminate the memory leaks that will probably always plague C.

If you suggest that any C++ code should go into the Linux kernel, Torvalds would probably punch you in the nose. He calls it a horrible language.

I'll admit, the first time I looked at C++, there were some show-stoppers, such as with function overloading. Consider the two functions:

int something(); int something(int start=0);

It was perfectly legal. But what if you call:

int result = something();

which function do you get? The one with no parameters or the one with a single default parameter? It's ambiguous. Looking into that at the time, I got the answer: it's compiler dependent. Well, that's no good! Granted, you shouldn't overload functions like that, but those rough edges were enough for me to put C++ on the shelf for a while until it matured, which, of course, it did. Now, such poor programming generates a warning.

But is C++ a horrible language? Of course not! It's still the Language of the Gods. I really like Dart, too; it has some powerful features, but also omits many that C++ has and their absence makes me feel crippled at times. I just finished the core of an application in C++ that I'm sure would have taken me five or ten times as long in C and left some memory leaks. Linus Torvalds is wrong about C++.

What he is right about is that's it's a horrible language for the Linux kernel. I agree with him there. I also do down-to-the-metal embedded microcontroller projects, and for those I use C. For the beginner, there are a lot of pre-written libraries for interfacing to hardware such as LCD displays, and many of those are in C++. They are designed to work with about everything, which includes a lot of code to determine exactly what they are working with, which in turn explodes the size of your code footprint like Mount St. Helens. I prefer to craft my own from C and end up with a fraction of the size and twice the speed. In the embedded world, code size and processor cycles mean a lot more than they do with 4GHz desktops sporting 64GB of RAM.

There is a place for both languages.

But I will confess that I'm worrying more and more about the future of C++, not because the language is obsolete, which it isn't, but because of the C++ Standards Committee, formally known as JTC1/SC22/WG21. My apprehension dates back to the 1970s. There were other programming languages at the time, like LISP, Algol, and Simscript, and I tried everything the university had a compiler or interpreter for. But by and large, if you were programming science or engineering you did it in FORTRAN and if business you did it in COBOL, each language well suited for its purpose.

But at that time there was another creature lurking, one born in the dungeons of IBM: PL/I. Programming Language One, conceived to the the ultimate all-purpose computer lingo for everything. It was a bold idea that wasn't thought out ahead of time. To me, it looked rather like the bastard child of FORTRAN and COBOL, though I haven't touched it in half a century, so my memory is vague on that point. It felt like a chimera of programming language fragments all jumbled together. Find another language with some other feature? Toss it in! Fortunately, they didn't try to throw LISP or Simscript into the mix that I know of. My final assessment was that, yes, you could do about anything with it, but it didn't do science and engineering as well as FORTRAN and it didn't do business as well as COBOL.

Are there any surviving PL/I programs in operation?

Anyway, it's starting to feel like the C++ Standards Committee is doing the same thing. Every three years, they look at what language features C++ doesn't have yet and try to fit it in. Granted, some have been helpful, especially lambdas, but I have my doubts about others. I've lost track of how many ways there are to express a for loop now, but their proliferation has destroyed the simple consistent syntax of classical C++. Then there's the auto keyword. I don't like that it replaces a C keyword (albeit a useless one) with a different meaning, but I can live with that, and I'll admit to using it sometimes, but that's only when I'm being lazy. It's still compile-time binding, but it's like a little pseudopod reaching out toward run-time. Auto. What does that mean? Sure, it might be obvious to the compiler and obvious that your loop runs from pork.begin() to pork.end(), but you might have to scroll through 10,000 lines of code spread across 200 files to find out what pork is. I'm much more confortable just typing out

std::vector<std::map<std::string, int>>::iterator ii = pork.begin()...

while it's on my mind because now its immediately clear what pork is and I don't have to remember it or look it up. Instant documentation.

It turns out that a lot of C++ programmers, myself included, end up using a subset of C++ (at this time C++23) because there is just so much to keep track of, much of which doesn't contribute anything you couldn't already do. My eyes are rolling prematurely at what might come out in C++26. It already feels far too much like PL/I, burdened with every language feature that crosses someone's mind. If they add real closures or garbage collection, it wouldn't even be C++ anymore because they would obliterate the design of the language. They'd have to come up with another name, like D--. Or maybe JavaScript. I'm not sure I would use it. C++ doesn't need garbage collection anyway, as evidenced by Rust. All Rust does, basically, is to enforce what a competent C++ programmer does anyway. I haven't said anything about templates yet. They're great if you're writing a library, like the Standard Template Library, but rarely useful at the application level.

So no, C++ is not a horrible language no matter how horrible it would be for the Linux kernel. But I fear that it is on the road to becoming a twisted mess composed of so many features that it lacks any consistent structure. Linus Torvalds is currently wrong about C++, and I hope the Standards Committee doesn't make him right.