What a coincidence. This sounds exactly like what happens with OOP. Every discussion here gets swarmed with clueless people who think Java is the apex of OO programming, because that's what gets taught in universities these days. They don't understand any of the core concepts that prompted Xerox Park to develop the OO paradigm in the first place. They aren't aware of any of the relevant research. They operate under the assumption that OO was born out complete ignorance of functional programming, even though people who kick-started its rise were keenly aware of Lisp (for example, Alan Kay frequently references McCarthy's work and research papers in his talks). Etc, etc.
Good OOP is good FP - they swim in the same water.
composition, generics/adt's, elegance, encapsulation...
In it's ideal form it's about taming the metal like a trick pony.
I'm nowhere near that level, being a fortran in any language sorta guy lol, but when I see well-built stuff, I take notes. Matryushka dolls, lol
Kay et al were swimming in the same water as Hewitt etc, conceptually. He said that the key takeaway from OOP was objects passing messages (actor model), not so much the inheritance story (the composition)
I think the Smalltalk paradigm is deeply defective and the Actor model (the purest form of OOP to my mind) remedies most of its faults but perpetuates some others. A few flaws:
- Modeling all communication as synchronous message-passing. Some communication (such as evaluating mathematical functions) is naturally modeled as synchronous procedure calls, while communication which is naturally modeled as message-passing should be asynchronous by default (to address unpredictable latency, partial failure, etc.).
- Emphasizing implementation inheritance as the primary means of code reuse. This is now generally acknowledged to be a mistake, so I won't elaborate.
- Deferring all method resolution to runtime. This makes the amazing introspective and dynamic capabilities of Smalltalk possible, but it also makes it impossible to statically verify programs for type-correctness.
- Relying on mutable local state rather than explicit, externalized state. This is controversial, and it's a defect of the Actor model as well (yes, passing new parameters into a tail-recursive message receive loop is equivalent to mutating local state). The partisans of OOP and the Actor model believe this to be a virtue, enabling robust emergent collective behavior from small autonomous software agents, but it makes predicting large-scale behavior difficult and debugging nearly impossible.
There was an article on state in OOP posted here a few days ago that I found very thought-provoking[1]. The blog post and related youtube videos are pretty interesting as well[2][3][4].
All of this has been addressed zillion times. Modern Smalltalk dialects have actor libraries and have code reuse mechanisms that don't involve inheritance. There are ways of doing static analysis on late-bound code. (Obviously, guarantees are not going to be the same. I take that as a reasonable trade-off.) OOP isn't predicated on mutable state and there are ways for the system to manage it anyway. (Although, to be fair - that is one thing from the list that hasn't been fully addressed in any practical OOP system I'm aware of.)
Even if none of the work I mentioned above existed, this sort of criticism is amateurish at best. Real engineering requires considering trade-offs in real-life contexts. For example, compile-time checks aren't going to help you figure out that some vendor supplies incorrect data via a web service. An early prototype, however, can do exactly that.
> Every discussion here gets swarmed with clueless people who think Java is the apex of OO programming, because that's what gets taught in universities these days.
Realistically, Java (or something very much like it) is the apex of OOP, at least as most people will experience it. The Ur-example of OOP might be a beautiful, internally consistent vision of mathematical purity, but most of us will never experience it.
Similarly, Agile-fall is the most common form of Agile that people will experience, which is why we always fall into "no true Scotsman" territory when ~~arguing about~~ discussing it.
There is, I think, a disconnect between people who are primarily concerned with the beauty of software - simple models, elegant algorithms, and so on - and the people who are primarily concerned with getting their feature branch merged to master so their manager will let them go to their kid's soccer game.
The beauty of software is important, and there's value in trying to bring the useful, but more esoteric concepts of CS into the mainstream, but at the same time we need to be aware of the ground truth of software development.
>Realistically, Java (or something very much like it) is the apex of OOP [...]
By this logic Java Streams are the apex of functional programming and anyone who uses them is fully qualified to dismiss the paradigm, even if they don't know anything about proper functional languages.
This makes me appreciate working somewhere that feels kids' soccer games will always take precedence over merging features. I also use hybrid actors/oop extensively. I'd never really considered that these probably go hand in hand.
The thing about these discussions is they seem to have two different questions mixed together. One question is "what's the best way to produce good software in a circumstance where everyone start on top of their game and the right thing" and the other is "what's a sort-of natural, slightly better average, way that programming can be." The answer to the first can be "Good functional Programming" or "Good OOP" or maybe something even more exotic. But it doesn't matter that much for the second question. Because usually the question of "how can this code we have already be better" mean "how do you take a general mess and make salvagable?" I don't know what the FP's answer to this is. I generally get the feel the FP people don't want to have an answer to this because then there'd be a lot of better-but-still-bad installations out there. But there are plenty answers to improvement using OOP - most say just encapsulate everything or similar things. All sorts of things can be thinly encapsulated, better, but still far from good. That seems to me explain the prevalence of OOP.
