I mean you're just using different words to talk about the same thing. In your terminology inheritance is just extending a namespace and overloading names.
How does that discredit or put into question the "mental model of command and control, or structured design concepts"
If anything I feel the failure of OO languages is that they have been afraid of baking in proven design patterns/principles that reoccur over and over (ie. Gang of Four and a few more since then). Yesterday i was staring at some undocumented OpenCV code trying to figure out why there was some pointer that kept showing up in random places. After a very confusing 30 minutes i figured out it was actually the pImpl idiom. Now why do we have to have to reimplement the pImpl idiom each time? why can't this be a keyword?. The amount of code bloat and confusion that a visitor introduces is the prime reason I never use them. (There was an interesting proposal at CppCon 2 years ago that addressed this, but as far as I know it's not gone anywhere)
The problem is that the most OO language trace back to C which IS a half-assed language from the perspective of "concurrency, state, and hell even the basics such as cyclic loops within a event based system" and most languages that do OO have been half baked on top of that foundation.
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.
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
One of the things that consistently impresses me about 1960s computing demos is the clarity of meaning and lack of jargon.
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).
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.
Also the pImpl is a consequence of C++ not adopting modules and instead rely on C linkers, nothing to do with OOP.
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).
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++.
I don't think you understand Alan Kay's version of OOP, if you think inheritance is a key part of OOP.
I was interested in this stuff during the summer and I wrote up the following question/answer if you're interested on what Alan Kay's version of OOP was:
https://cs.stackexchange.com/questions/51847/what-is-the-dif...
I answered my own question so I might be wrong, but I have put in a reasonable amount of research effort into it.
I saw you made the comment `o be concrete - object oriented programming is easy in python, because it's possible to program methods of an object in a way that doesn't assume a particular representation.`
I thought you would be really interested in usage of polymorphism in python (http://neverworkintheory.org/2016/06/13/polymorphism-in-pyth...).
Quote from the article: `Our findings show that the receiver in 97.4% of all call-sites in the average program can be described by a single static type`.
It looks like even when that restriction is removed it doesn't really help that much.
Another great podcast on evidence based programming: https://www.functionalgeekery.com/episode-55-andreas-stefik/
Evidence-based programming language design : a philosophical and methodological exploration: https://jyx.jyu.fi/dspace/handle/123456789/47698
Is another great read if you've got the time.
The whole notion that everyone has their own perspective on oop makes it a mute point.
But yes, the number of variant perspectives on OOP make it a less descriptive term than would be ideal.
No but seriously, I think both you and hackits make it clear that there's a lot of discussion over what OOP actually is. Which makes me curious: is there any research on the characteristics of OOP as it implemented in practice across languages? I'd be very interested in such research, because it seems to me that what is possible is often not practiced.
So, for example, Ruby might be all about 'message passing' as others, and all the tutorials and books I've read indicate, but in practice it might be indistinguishable from just calling methods on objects, or whatever distinguishes message passing from other OOP styles.
If no such research exists, how difficult would it be to scan codebases on Github to analyse this? I might be wrong, but it seems like this would be a worthwhile investigation: how do people actually use languages and what is 'OOP' or 'FP' actually like in codebases that claim to be one or the other.
Otherwise we're just getting tangled up in definitions and it's all a moo point.
Since 1960 till 2012, there are only 22 research papers that used empirical evidence with randomised cross over studies for language design.
As of which, Class inheritance had 4 randomized controlled experiments. With a collection of other studies. That is mostly of the information I have come across.
There is a research paper on Java that looked at how programmers use inheritance. It's a interesting read and its a good source. (https://researchspace.auckland.ac.nz/handle/2292/16840)
I think Google published another paper looking at development time and I believe the result was the biggest time consumer for programmer was dependencies not necessary the programming langue.
I agree. I would say a lot of things people do in OOP isn't really OOP it's just object modeling principles. You can apply the same principles in a different language without notions of objects/classes (javascript) comes to mind.
One half, see it in terms of computer and data science. For these, data-structures, algorithms and ADTs are paramount. Organization of the problem is through modularity and functional decomposition. An object (as in OO) might be useful for encapsulation, data and implementation hiding, and code organization.
On the other hand, there are people involved in business, commerce, industry etc, who need to model concepts, real and abstract, and the complex relationships and constraints between them, into code. For them, an object can be the best way to represent a concept and an OO approach can be the best way to represent how concepts interact with each other.
Though I keep hearing from Alan and other prominent language designers that we still are holding onto this old 1960 mental model of command and control, or structured design concepts. Even some well spoken people suggest that the whole notion of object's are worthless to programmers because it takes place within the notion of classes and constraints of the machine.
This whole philosophical debate about understanding/miss-understanding/correct usage of OOP is just a complete waste of time.
For what its worth I consider object's simply as a basic level category of procedures and data tied to a namespace. If the category requires state then consider it as a object otherwise its considered a module.
I've seen too many project's that have drunken the cool aid and has resulted in 5-10 level deep inheritance tree's with their own branching logic trying to fit behavior to a specific taxonomy.