Lambda the Ultimate

As someone paid to code C++, the hate is probably warranted. C++ has so many inconsistencies leading to gotchas that whenever I'm trying to explain an element of the language to someone I warn them that it's 'pedagogically crippled.'

What's the point of hating something that no one on the planet understands?

If you don't understand something, how can you justify hating it?

While C++ has lotsa flaws, I do understand it and definitely don't hate it. I much prefer it, I'm sorry to admit :), to several of its supposed successors.

Scott Johnson: If you don't understand something, how can you justify hating it?

Well, if the point of the thing is to aid communication and understanding, as a programming language is intended to do, it becomes easy to justify hating it if it isn't understandable.

Pithy Abelson and Sussman quotes aside, I reject this assertion. For decades in the natural science, machine learning, statistics, and optimization communities, the purpose of published papers has been to aid communication, while the purpose of programming languages has been to quickly and efficiently implement these ideas. One doesn't explain how a support vector machine works by saying "look at the code to SVMLight!" It's pretty clean code as these things go, but its main goal is to efficiently implement an SVM, not to illustrate how one works. To understand that, you read the literature.

For those of us who do this sort of thing for a living, C++ (or even Fortran!) can actually be quite convenient. So while I might hate C++ if I had to write a GUI with it, I see little reason to do so in using it for my purposes.

At the very least, programs serve as communications to the machine, as well as to future programmers who are working on it. So programming languages certainly need to aid communication and understanding, if programs are to actually work, and be more than just write-only creations that cannot be revised, and instead need to be completely rewritten.

I think the Abelson and Sussmann perspective largely comes from exploring this fact and extending its scope in certain ways.

"One doesn't explain how a support vector machine works by saying "look at the code to SVMLight!""

I respectfully disagree.

In my experience, that's the only thing to know how things really work. Either documentation is out of date, simply wrong, or the person who wrote the undocumented code has left the company a long time ago and one needs to read the code to not only know how something works but also distill the intent (or 'tao of it's design' if you allow me to be pithy).

I think this is more the case in academia, where most code is written to (cynically) generate a couple of pretty pictures in some paper. Since the documentation (i.e. the paper) comes before the code, and since you get credit for publishing papers rather than writing code, the docs don't tend to get out of date.

Documentation is useful (and potentially out of date) for complicated interfaces, but not so much for complicated algorithms with simple ones.

If it has a simple interface and it works, then I don't care what's in it. You would be correct in saying it can be just for implementation's sake. However, the fact that it has a simple interface and works properly implies that the interface was indeed designed to be self documenting to communicate with people.

Complicated algorithms with simple interfaces is the self documenting code that we're all talking about!

I guess you work in statistical machine learning. Me too. I'm curious about what tools you use to write code, because in my experience, when it comes to array manipulation, they all suck. You can have expressive but slow (the array languages), or inexpressive but fast (C++, O'Caml). SAC is the most interesting thing I know of for array munging, but they've made several decisions that aren't optimal for my uses -- primarily by optimising exclusively for fast and expressive array operations, at the expense of expressivity in any other part of the language (no higher-order functions, no pattern matching etc.)

I code in a mixture of C++ and Octave, with Perl to beat the data into a format I can digest. Octave has a pretty decent C++ interface for writing extensions, so I can write fast components and use them interactively from the Octave REPL in Emacs. I've looked at more expressive array packages for C++, and at least in theory things like Blitz++ are very cool, but usually anything regular enough to benefit from expressive C++ arrays seems fast enough in Octave, while rich arrays don't help too much dealing with fancier data structures and irregular access. I keep meaning to check out Ocaml and Bigloo, but haven't summoned the tuits to give either a serious shot.

While C++ has lotsa flaws, I do understand it

"Just what is a 'protected abstract virtual base pure virtual private destructor' and when was the last time you needed one?" -- Tom Cargil, C++ Journal

That was thirteen years ago, and C++ hasn't gotten one whit simpler to understand since then. If you've actually got a firm understanding of the entire spec, I bow to your superior knowlege. Most people just pick up a big enough to get by, and firmly avoid the rest.

In some ways, Java and C# simply formalized that approach.

...because the string, as written, is nonsense. I often use pure virtual private destructors--pure virtual destructors are a common C++ way of saying "abstract"; and making the destructor private is one way to mark a class final in C++. Unlike Java, C++ has keywords for neither concept.

Virtual inheritance of abstract base classes is rather similar to inheritance of Java interfaces. Protected inheritance (which is what I assume what is meant by "protected"; otherwise combining private and protected is nonsensical) is pretty much useless.

However, to combine the two phrases into a single clause--one referring to a type of inheritance relationship; the other referring to a specific class method--is nonsense.

While the entirity of the C++ spec/language is complicated, the 90/10 rule comes into play: You can write REAMS of programs without having to worry about the more arcane features of the language--many of which are only appropriate/intended for niche tasks/applications. If you're a library writer, you might need to know the finer points of such things as pointers-to-member, non-public inheritance, reinterpret_cast, etc. If you're an application programmer, OTOH, these things simply don't come into play.

While the entirity of the C++ spec/language is complicated, the 90/10 rule comes into play: You can write REAMS of programs without having to worry about the more arcane features of the language--many of which are only appropriate/intended for niche tasks/applications.

Well, you can ignore those features, but only if your co-workers did ignore those features. That includes the junior coders you just hired, that guy you had to fire last year because he turned out to be a drunken idiot, and your manager who hadn't coded in five years but was pressed into service the last time you were all under deadline.

For most computing professionals, programming is a team sport. In that environment, language features you don't understand can easily bite you.

Well, you can ignore those features, but only if your co-workers did ignore those features.

That doesn't refute the 90/10 rule. Pretty much everywhere the same subset of C++ is spoken. It's already so easy to convolute everything with the 90% that most people don't even feel the need the venture into the 10% bit.

Pretty much everywhere the same subset of C++ is spoken.

I don't think that's the case, actually. Different teams run into different problems, and expand their subsets to tackle them.

In my (limited) experience, only the experts will use the more obscure features of C++. The lesser programmers stick to the small subset they know. The Obscure stuff in C++ is hard enough to make compile that only the experts will stick around long enough to make it work, while the less programmers will find a simpiler way that works good enough (Which is to imply that using the more obscure stuff would be better in this case, but they can't deal with it).

The experts know to only use the obscure stuff when required, and they write pretty good code, so I rarely have to maintain their stuff.

There are a lot of things in C++ that I do not use because I have not found a need. In some cases I should have used them, but didn't feel it was worth the effort. In others the options were all worse so I learned the obscure way.

I spend my of my C++ time in the same 10% as everyone else. I know another 40% that I step into once in a while, but only when I must. I'm aware of another 30% that I have never used, but I could learn if there was a need. (The rest is things I'm not aware of so I won't use even when I should)

A true C++ expert will try to keep as much of the code as possible in that same 10% that everyone uses. Everyone uses it for good reason - that is where things get done. Now the expert himself is likely to spend 50% of his time in the more obscure parts, but that is because the expert is the one who the others go to when that 10% fails to work nicely.

There are other languages that don't offer much beyond that 10% that C++ does. People write useful programs in them all the time. C++ lets you go farther if you need to. Mind there are other languages that offer as much or more than C++, but do so in a way that is much easier for non-experts to work with.