> If anything I feel the failure of OO languages

What failure exactly?

OOP has flaws but it has certainly proven to be extremely versatile and adaptable over these past decades since even today, it's still the dominant paradigm to solve modern problems in computing.

Seriously? Have you watched any of the demos Alan references? They were doing things with computers in the 1960s/70s that still haven't reached mainstream use as yet. Computers as used today are still absolutely dumb machines that are little more than super-fast calculators, and in most cases increases the mental burden of their users instead of reducing/augmenting them. Nicholas Negroponte had a great quote in '94 that's still true today - "those infra-red urinals in public restrooms know more about what we are doing than our computers today."

Can you summarize what those things might be? (That haven't reached mainstream use)

Here are 2 that he often brings up:

Ivan Sutherland's Sketchpad demo - Object oriented graphics using a constraint based system (https://www.youtube.com/watch?v=6orsmFndx_o)

Douglas Englebart's demo - too many innovations to list, but includes real time collaboration (he demoed in a convention center while the system ran 30 miles away in his lab, connected by a leased line operating at 1200 baud!). People think he just invented the mouse, but the overarching theme in his work was augmenting human capabilities... http://dougengelbart.org/firsts/dougs-1968-demo.html

Which of those things are not in mainstream use? We have Skype and Google Docs and AWS for collaboration and client/server computing.

I hadn't seen the Sketchpad, thanks for the link.

One of the things that consistently impresses me about 1960s computing demos is the clarity of meaning and lack of jargon.

Do you have links to any of those demos?

See infinite8s' post above. The "Engelbart's demo" mentioned is called The Mother of All Demos, which you can find by that title on youtube.

I have to admit I never really got further than the first 5-10 minutes or so. My first computer experiences are from the late 80s (and indeed didn't have a mouse) but this demo is so old, I kept having to mentally translate for myself which bits might have been new or ground breaking, and which just plain archaic. I keep meaning to watch it in full some day, but the first bit that I saw, I keep feeling I'm missing something important. People are lyrical about this demo (hence the name!), but I don't quite feel it or something. Then again, while I appreciate the great work of engineering that went into it, I'm not really one to sit down and watch a documentary about the moon landing program either.

Maybe somebody here knows a good link or article about The Mother of All Demos that explains which things I should be in awe about and why they were so novel then?

Part of it kind of looks like a simple database table system, which reminds me of a stupid story from my childhood. When I was young (~1990 I guess), I was playing with the MSX BASIC on a friend's computer whose family had a farm. They wondered if I could write anything to keep track of their cows or something--sure thing! (though I really preferred to write graphics code, later joined the demoscene, way more fun). Now I had no idea about business or their requirements (let alone requirements engineering), so I just wrote some whatever that let them enter data, but in the back of my mind I wondered how this was going to be useful for anything. Neither did I know (yet) how to actually save the data so it'd be available after reboot, which was probably a big reason for my doubts. And they were still impressed (that it could repeat names of many cows, I guess). I never finished it (nor any idea of what "finished" would mean).

Sorry, I mean "drawbacks". One of the reoccurring complaints about OO is that it leads to huge codebases. Lots of articles about how X rewrote some Java program in Y and it's not 10x smaller and 100x more maintainable. This is a consequence of languages being designed to be minimal in terms of keywords - trying to push off as much as possible on to library writers. Unfortunately this seems to have serious limitations and all the boilerplate can't seem to be hidden in library wrappers

"Huge code base" is a pretty vague metric. Huge in what, lines of code? Binary size?

I'd argue that neither of these are really a good measure, I'm more interested in the concepts that a source file captures than its size in kb, because these concepts correlate directly to how easy it will be to evolve that code base in the future. There is a point of diminishing return in trying to make the code too compact, which basically means you're optimizing in one dimension at the detriments of all the others.

The problem there is that any re-write, even staying within OO, is going to result in the codebase being smaller.

All that versatility and adaptability comes at the expense of various kinds of boilerplate, most of which can be avoided by employing other styles. In other words, it's not more versatile, it's only "Turing complete", and versatility would mean using a number of different styles and being efficient in each.

I can think of a good list of OO languages that don't have anything to do with C.

Also the pImpl is a consequence of C++ not adopting modules and instead rely on C linkers, nothing to do with OOP.

Yup. We were looking at alternate runtimes in some OS / userland projects at Apple in the late 80s. You don't need vtables, and you can do better than static struct layout. You have to do some work at code load-time.

C++'s initial lack of a real string type and simple collection types pretty much doomed the language. (Instead they did iostreams? I've been using C++ since early CFront days, and have never used that misbegotten API).

I guess I am one of the few people on the planet than enjoys using iostreams when I need to use C++. :)

Then again, I never needed to know all their little details.

Yeah implementing string, array and collection types was a kind of rite of passage for every C++ developer, back when the compilers were still trying to catch up with C++ARM.

I believe appealing to the C culture was one of the reasons those types weren't initially available, as C++ was already considered too bloated by the C community even without them.

Nowadays their three major compilers are written in C++.