OO is good for programmers to model problems, not for yielding the best result. I find that thinking in terms of functional code (info being passed from one place to another; not diluted into a lot of objects with state) yields the best result in terms of stability and lack of bugs
Why OO Sucks by Joe Armstrong (2000)
221–230 of 396 posts
Re: Why OO Sucks by Joe Armstrong (2000)
#222I have a different opinion about why OO was popular. I think it can work well for small programs. But it doesn't scale well to bigger problems. It just becomes too confusing. Once people used it for bigger things, possibly because programs got bigger with Moore's law, it can just be untenable. (But, then again, in some places it still can make sense.)
You are right, but not wrt small vs large. Instead, OO works well for artificial situations (classic case - UI frameworks) vs. real world situations (classic case - person isa contractor vs. person isa employee).
As soon as you start modeling real world situations (like bill being an employee but at the same time working a late shift as a contractor), then you're in the world of complex stuff that single inheritance, multiple inheritance, or anything less than insanely complex relationships requiring tens or hundreds of underlying entities to enact just can't handle.
IMO one reason for these fruitlesd ideological arguments -is OO good? Is it bad? - is that OO was originally sold using these real world examples. Which anyone who's worked on a real world system knows is BS.
Re: Why OO Sucks by Joe Armstrong (2000)
#223> Objection 1. Data structure and functions should not be bound together I don't understand the above: a. functions do things, b. objects don't do things, therefore, we shouldn't combine them together? Why? I'm not convinced? what's the logic? doesn't seem to be a strong argument to me. factories make things. warehouses don't make things. so we should build them together?
We should be forced to combine them together.
Re: Why OO Sucks by Joe Armstrong (2000)
#224It really should be noted that years later Joe changed his mind about OO and came to the realization that perhaps Erlang is the only object-oriented language :) From a 2010 interview: ..."I wrote a an article, a blog thing, years ago - Why object oriented programming is silly. I mainly wanted to provoke people with it. They had a quite interesting response to that and I managed to annoy a lot of people, which was par…
If pretty much every single implementation of OO languages misunderstood Kay that just means Kay either didn't explain himself well or OO as he intended it is so easy to misunderstand it's almost useless as a programming paradigm. At this point, it really doesn't matter anymore. OO is what OO languages like C++ and Java have made it. The original author in no way has a monopoly or even a privileged viewpoint in the matter. And frankly, I agree with the original article. OO is very poor and leads to a lot of misunderstandings because it has a lot of problems in its core design. It "sucks." It never made much sense to me and clearly it never made much sense to even the people designing languages such as C++ or Java because it's taken decades to come up with somewhat useful self-imposed limitations and rules on how to use OO to not come up with an ugly mess. It's completely unintuitive and out of the box misleads just about every beginner who tries to use it. A programming paradigm should make it obvious how it's supposed to be used but OO does the opposite. It obfuscates how it should be used in favor of paradigms like inheritance that lead users down a path of miser and pain due to complexity and dead ends that require rewriting code. In most cases, it's mostly a way to namespace code in an extremely complicated and unintuitive manner. And we haven't even touched the surface as to its negative influences on data structures.
Re: Why OO Sucks by Joe Armstrong (2000)
#225I disagree with every point he made.
Data structures shall be bound to functions. It increases modularity. That does not mean common code shall not be refactored and be standalone.
Data types are instantiated to objects. When in Erlang a time variable is declared, that variable is an object. OOP has data types too, called classes, and having everything to be an object does not mean it has to be the same data type.
In some languages classes can be in the same file, so point #3 is actually about specific implementations.
Inside point #3 he also mentions inheritance. Not all OOP languages require inheritance from a specific class.
I also disagree with his 4th point about hidden state: hidden state enhances modularization tremendously. I don't need to see how something is implemented, treating it as a black box increases my chances of using it correctly through a predefined interface. If the interface is lacking or is not defined correctly, that's an entirely different problem and it's not due to hidden state.
Re: Why OO Sucks by Joe Armstrong (2000)
#226Earlier quoted context omitted.
Agreed. I remember thinking "what don't I get? Why do we need getters and setters?". After some years (and discovering Python), I realized there's nothing to get, it's just ridiculous overengineering 95% of the time. Same goes for a lot of stuff in OO. I attribute it to the corporate mindset it seems to thrive in, but I could be wrong.
The important thing is restricting your public interface, hiding implementation details, and thinking about how easy your code (and code that uses it) will be to change later. It's not an OO vs anything thing. When you want a value from a module/object/function/whatever, whether or not it's fetched from a location in memory is an implementation detail. Java and co provide a short syntax for exposing that implementati…
> The important thing is restricting your public interface
That is the important thing sometimes. At other times the important thing is to provide a flexible, fluent public interface that can be used in ways you didn't intend.
It really depends on what you're building and what properties of a codebase are most valuable to you. Encapsulation always comes at a cost. The current swing back towards strong typing and "bondage and discipline" languages tends to forget this in favour of it's benefits.
Re: Why OO Sucks by Joe Armstrong (2000)
#227Earlier quoted context omitted.
Admittedly I'm somewhat of a FP fanboy, but I seriously cannot disagree with you more on this. Functional Programming (and Logic Programming) are better than other paradigms because, unlike Java (or C++, or C#...) there is an emphasis on correctness , and the people working on FP compilers (like Haskell and Idris) are utilizing mathematics to do this. No idea on your opinion on mathematics, but to me Math/Logic reign…
> I realize that I'm picking on Java, but Java is the biggest target when it comes with OOP as the industry understands it. I personally cannot stand having to create fifty files do to something like a database wrapper, and in Java that's effectively the only way to program. I had this experience once in a Rails shop. A simple database table mapped to a CRUD API endpoint would take from five to ten files. That amount…
We are currently in a swing back in favour of statically typed languages. People seem to have forgotten why we previously had a huge trend towards more expressive, less strict, dynamically typed languages.
Maybe we learn something each time the pendulum swings but as someone knee deep in C# at the moment, the quality of the APIs I have to deal with are far below those I was used to in Python (at least in terms of elegance and usability).
I'm not sure whether these flaws are inherent or whether it's possible to have one's cake and eat it.
Re: Why OO Sucks by Joe Armstrong (2000)
#228Earlier quoted context omitted.
Isn't a method call a message, and the return value a message back? Or is it that "true OO" must be asynchronous?
> Isn't a method call a message, and the return value a message back? It is! In my view, the point that Alan Kay and Joe Armstrong are trying to make is that languages like C++/Java/C# etc have very limited message passing abilities. Alan Kay uses the term "late binding". In Kay's opinion, "extreme late binding" is one of the most important aspects of his OOP [1], even more important than polymorphism. Extreme late b…
what does late binding by you? That sounds like an argument for non-strictly typed languages. Isn't in the strict typing that prevents late binding? The compiler wants to know at compile time the types of all the messages and whether or not an object can handle that message hence all messages must be typed and all object must declare which messages they accept.
Re: Why OO Sucks by Joe Armstrong (2000)
#229It really should be noted that years later Joe changed his mind about OO and came to the realization that perhaps Erlang is the only object-oriented language :) From a 2010 interview: ..."I wrote a an article, a blog thing, years ago - Why object oriented programming is silly. I mainly wanted to provoke people with it. They had a quite interesting response to that and I managed to annoy a lot of people, which was par…
Both Alan Kay and Joe Armstrong struck me as having had the same attitude of trying to capitalize on the topic of object oriented programming, failing to recognize its importance, and then later trying to appropriate it by redefining it. Not the best moment of these otherwise two bright minds.
This is way off. Please try to do more homework.
Re: Why OO Sucks by Joe Armstrong (2000)
#230Earlier quoted context omitted.
Didn’t Alan Kay coin the term “object oriented”?
I don't believe he claims to, no. He coined the term “object,” but what he meant by a computational object was different than what it came to mean: a data structure with associated operations upon it. Kay meant a parallel thread of execution which was generally sitting in a waiting state—one could make a very strong analogy between Smalltalk's vision of “objects” and what we call today “microservices,” albeit all liv…
I didn't coin the term "object" -- and I shouldn't have used it in 1966 when I did coin the term "object-oriented programming" flippantly in response to the question "what are you working on?".
This is partly because the term at the time meant a patch of storage with multiple data fields -- like a punched card image in storage or a Sketchpad data-structure.
But my idea was about "things" that were like time-sharing processes, but for all entities. This was a simple idea that was catalyzed by seeing Sketchpad and Simula I in the same week in grad school.
The work we did at Parc after doing lots of software engineering to get everything to be "an object", was early, quite successful, and we called it "object-oriented programming".
I think this led to people in the 1980s wanting to be part of this in some way, and the term was applied in ways that weren't in my idea of "everything from software computers on a network intercommunicating by messages".
I don't think the term can be rescued at this point -- and I've quit using it to describe how we went about doing things.
It's worth trying to understand the difference between the idea, our pragmatic experiments on small machines at Xerox Parc, and what is called "OOP" today.
The simplest way to understand what we were driving at "way back then" was that we were trying to move from "programming" as it was thought of in the 60s -- where programs manipulated data structures -- to "growing systems" -- like Smalltalk and the Internet -- where the system would "stay alive" and help to move itself forward in time. (And so forth.)
The simplest way to think about this is that one way to characterize systems is that which is "made from intercommunicating dynamic modules". In order to make this work, one has to learn how to design and maintain systems ...