I hope that, with the assistance of time, we can now adopt a more aristotlean/catholic "and" vs. a platonic/puritan "or" with respect to these various language features.<p>Object oriented programming is a perfectly reasonable way to organize a code base and the basics provide for good encapsulation. Elaborate object hierarchies and the design pattern maximalism of the early java community that lead to the hilariously germanic ThingDoerFactoryFacadeFactoryInstaniatorService abominations are obviously bad, but the basics of OO do a good job if used reasonably.<p>Increasingly we are seeing pragmatic integration of different language features: for example using classes/objects for data modeling but using functional-style closures for data structure manipulation. Pragmatic static type systems with 'escape hatches' when needed, or dynamically typed language adding support for some static typing. Etc. This is the right thing.<p>Not "either/or" but rather "both/and" and using the right tool for the job. The manichaeism of early language discussions can be set aside and, rather than fighting about which language is "the right thing" we can talk about which language feature(s) is/are the right thing <i>for this particular problem</i>.
> But with C++ and Java, the dynamic thinking fostered by object-oriented languages was nearly fatally assaulted by the theology of static thinking inherited from our mathematical heritage and the assumptions built into our views of computing by Charles Babbage whose factory-building worldview was dominated by omniscience and omnipotence.<p>><p>> And as a result we find that object-oriented languages have succumbed to static thinkers who worship perfect planning over runtime adaptability, early decisions over late ones, and the wisdom of compilers over the cleverness of failure detection and repair.<p>And, there you have it. This is a big part of the reason that I never migrated from Objective-C to Swift. When I was programming in Objective-C, I always felt challenged by the idea that I had something to learn by embracing dynamic programming, and that it would be difficult, because the rest of the "OOP" world had forgotten all about it. What's left now is only a choice of straitjackets.<p><i>"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things."</i> – Alan Kay<p>I wish OOP had <i>explicitly</i> forked, all those years ago, and the C++/Java stuff could have been called something else. That would have at least cleared things up, conceptually.
I'd say the <i>most</i> ridiculous thing that has occurred in this space is something I'm personally dealing with in the workspace:<p>Governments (even well meaning, I mostly don't have a problem with this) sometimes get a say in promulgating teaching standards in higher ed, and now, not merely "programming," but "Object-oriented programming" is a required prerequisite in my college program. Sigh.
It should be noted that this documented one of the starting positions of a panel discussion at OOPSLA 2002: <i>Resolved: Objects have Failed</i>.<p><a href="http://www.oopsla.org/2002/fp/files/pan-1.html" rel="nofollow">http://www.oopsla.org/2002/fp/files/pan-1.html</a><p><a href="http://www.oopsla.org/2002/fp/files/pan-9.html" rel="nofollow">http://www.oopsla.org/2002/fp/files/pan-9.html</a><p>The starting position of the "Objects have not failed" panelists is also on dreamsongs: <a href="https://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html" rel="nofollow">https://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html</a><p>And if you take both of these seriously, I think it becomes clear that the main failure of object-orientation is that it hasn't really been done yet. From Guy Steele's remarks:<p><pre><code> Procedural programming still has its place in the coding of methods.
</code></pre>
This is true, but it is an understatement. And the crux of the problem.<p>The place that procedural programming has is absolutely central, and there is actually little else, because even object oriented programming is ~90% writing (attached) procedures, except we call them methods. So in a way OO wrote a check that it then didn't let us cash.<p>We should be able to construct structures of objects, with attributes and substructure, and then connect those objects to each other using various communication mechanisms. But we can't. Well, we can <i>implement</i> it, but we cannot <i>express</i> it.<p>All we can express is procedures and procedure invocations. So we can invoke procedures to create an object, and capture creating that object in a procedure. We can connect that object to another object using another procedure call, and the communication will also be mediated using procedure calls.<p>Where's the structure, the connecting, the communication? Hidden. Invisible in the program's source text. ("In the comments". Ha!) Just like loops and other control structures were hidden in the patterns of gotos that Dijkstra complained about.<p>So while OOP has delivered a <i>lot</i> it actually has failed to deliver on one of its core promises. Because it wasn't fully implemented.
Here we go again.<p>I will note that this is from 2002. But the fact that it is being recirculated now suggests that this is a timely topic.<p>I've been a programmer for 30 some odd years. 25 of those professionally. I started on BASIC, learned C as fast as I could because I wanted to program games and all the cool kids were writing games in C. Then OOP became hot and I learned C++ and Java and was introduced to OOP design patterns and threw myself into studying Gang of Four, PLOPD and other classic works on the subject.<p>Yes, I remember the "hot-ness" of OOP in the 90s. Next, Java, even the marketing forces that led to calling ECMAScript "Java"Script and shoe-horning objects into what was intended by Brenden Eich to be a functional language came out of this idea that OOP was the next big thing in software development.<p>But what I don't remember was anyone, at any point in my 25 year career history, saying that OOP is the "only way."<p>In fact, I remember having a keen interest in LISP and FP as an aspiring novice in the 90s. I wanted to learn everything about languages, language theory and computer science that I could. People encouraged me to pursue that and never once said "stick with OOP and forget other paradigms."<p>But what I do see today, are people being so trendy and fashionable that they ARE saying these things about Functional Programming. OOP is being thrown with the bathwater HARD while people claim that it has "failed" and that everything should be Functional.<p>Both paradigms solve problems in different ways, have their own strengths, weaknesses and value judgments. OOP values custom types and encapsulating state whereas FP favours primitives, immutability and statelessnes. OOP sees conditional logic and the root of all complexity whereas FP views state as the root of all complexity. Neither is right or wrong and both points of view are provide better tradeoffs in different situations.<p>In other words, do your job as an engineer and pick the right tool for the problem at hand. Stop pretending that we are going to achieve some utopian panacea where we finally resolve the Church / Turing hypothesis and can say, objectively and absolutely, that one approach is always better in every situation.
"java trying to force its world view" is the correct way to design a programming language, just java is a bad language, and only half way forces its world view when it has to be 100% for this idea to work. in the sense that there shouldn't be things like int32 in a high level language.<p>also the OOP paradigm makes no sense and is just pseudoscience. i can't even think of a valid reason to use objects once you get past the cat/dog/animal example which only makes no sense because the proposed problem has no concrete requirements. there are no small examples where objects make sense, and for any big example it would require days of analysis to reach a conclusion. there are lots of invalid reasons, like some syntactic convenience of x.fff().zzz(), this example being invalid because that syntactic benefit can be better achieved by a composition operator like in bash: x | fff | zzz<p>if i look at any OOP codebase the first thing ill see is someone pointlessly loads up some data into an object and calls obj.method() which then just unloads the data as if they were just parameters to that function. why did you even make the object in the first place? because OOP braindamage, simple. you've been trained that this is somehow the ethically correct way to do things.<p>the idea that objects provide some new type of abstraction is just nonsense. those constructs were already doable in ML as well as by convention in C or any imperative language, which is how most such languages are in fact written. all OO adds is interfaces which are done better by many other languages, and inheritance which is just a joke.
Related ongoing thread:<p><i>Objects Have Not Failed (2002)</i> - <a href="https://news.ycombinator.com/item?id=34996807" rel="nofollow">https://news.ycombinator.com/item?id=34996807</a> - March 2023 (3 comments)
Just slightly tangential, but the quality of writing and thought from this person, whom I've read quite a bit at this point, just towers above the rest. Where did all the developers like this go? People who can talk seriously about fundamental things almost totally unattached from the business world or hype cycle. It's the kind of dev I imagined was everywhere before greeting reality. More a Stanley Cavell than a Steve Jobs. Its like a little portal into a world where the humanities are (correctly) taken seriously and actually used in a field that needs it most of all.<p>Why are the good thoughtful writers like this? Why are the ones who do exist always lisp guys?
(2002)<p>The worm is probably about to begin turning; the strict typing and bondage and discipline fads will fade and we'll have self modifying code seen as a cool thing again. One might argue that the "API / SaaS" fad is the 2nd coming of Objects, we just misinterpreted where the independent black boxes fit in the overall architecture.
I'm interested in object orientation from the perspective that an object is a process and it has behaviours with other objects and internal mechanisms.<p>Similar to message passing. Unfortunately I rarely see interaction diagrams of compositional nature of objects, so it's not obvious how most software is meant to work without an example sample.<p>Am I alone that Javadocs or Doxygen docs are not enough to understand an object orientated product?<p>I think referring to "local understanding" of objects is a really good point. The more you can understand locally, the more you can actively include in your thinking.
I believe objects have failed because you want to compose types (data) and functions in a different way. So any form of encapsulation (not to be confused with modularity) is too limiting.
OOP is still a good model for systems where most objects are long-lived, local, mutation latency is low, and the number of objects is reasonable. Like GUIs and simulations. (Not coincidentally those are the domains where OO was introduced.)<p>It’s not a good fit for systems that respond to short-lived requests. If your objects’ lifetimes are never longer than a HTTP request, you shouldn’t be using OOP. It’s not the right model! (I call this “kamikaze OOP”: you build a complex piece of machinery in memory and crash it down the next instant.)<p>At the other end of the spectrum, if your real-time system deals with potentially huge amounts of objects, then OO isn’t a good fit either because it doesn’t easily let you optimize memory layouts so you could loop over all that data. Something like ECS (entity component system) is probably a better fit.
Sure, it's obvious when you look at the code. There's hardly any "objects" per se, but there's tons of classes and class definitions and boilerplate regarding classes.<p>What we generally call "object-oriented" is actually "class-oriented".
Whatever Tesla's teams in sw/hw/fsd are doing appears to be state of the art at industry scale, improving year on year. Certainly, more sophisticated than F-35 sw/hw vtol control.