Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why OO Sucks by Joe Armstrong (2000)

cs.otago.ac.nz

Post reply on HN
Print view View original

31–40 of 396 posts

Re: Why OO Sucks by Joe Armstrong (2000)

#31

Post by vhb »

Well, I disagree with 99% of this... I'm a guy that started with C, moved to functional programing, added C++, and now do all 3.

> Objection 1. Data structure and functions should not be bound together

Well, in my experience, in every almost every code-base (either from functional, or imperative programing), we end up with modules, witch are a set of function taking the same type as a parameter. This is very close to binding the functions and the types...

> Objection 2. Everything has to be an object.

I don't get the example. The only thing that this show, is the benefits of having a range type built in the language. Then it's just type aliases.

"There are no associated methods.", yes, but you will need functions to manipulate those types (just translate one type into another), at the end, it's going to a module, which is almost an object.

> Objection 3. In an OOPL data type definitions are spread out all over the place.

That's true. It also makes thinking about the data layout complex. That's why other paradigm have been developed (DOP), on top of OOP. Now you can also think that having those defined together makes dependency management easier.

> Objection 4. Objects have private state.

False. Objects can have a private state. This a problem with mutability, not oriented object programing. You can have non mutable OOP.

> Why was OO popular?

>> Reason 1. It was thought to be easy to learn.

The past 20 years have shown how easy it is. In fact, I actually think it's too easy, people rely too much on abstraction, without even trying to understand what's going on. I my opinion, it promotes a lazy mindset (This is my biggest criticism about OOP).

>> Reason 2. It was thought to make code reuse easier.

I would like an evidence that it's not.

>> Reason 3. It was hyped.

True, but that does not make it bad. People tried to hype every technologies... Some stayed, some went away.

>> Reason 4. It created a new software industry.

How has OOP created a software industry that would not have existed if functional programing had "won the fight"?

Re: Why OO Sucks by Joe Armstrong (2000)

#32

Post by mises »

musingsole wrote: post #10
mises wrote: post #3

I think this may be another one of those swearing-in-church type opinions, but I think C++ is excellent as a compromise here. It's got its faults, but C++ allows use of objects when necessary or helpful without the ridiculously pedantic OO of Java. It is quite nice to be able to use it when convenient while not having to do so when stupid.

I'd extend the same argument to Python

I can't speak to python as much, as I haven't really used it, but I've heard a lot of good things about it (recently read a comment saying it was simply good at nothing but good enough at everything).

Re: Why OO Sucks by Joe Armstrong (2000)

#33

Post by sjwright »

peterashford wrote: post #15

I'm really sick of these 'why blah sucks' posts. Clearly OOP works for a lot of people. If it doesn't work for you, don't use it. My personal feeling is that FP works better when the problem domain is more data oriented, requiring transformation of data streams whereas OOP is good when the problem domain is about simulating or modeling where you want to think about interacting agents of some kind. The whole 'X is one…

The post was "why OO sucks," not "why nobody should ever use OO." The distinction is important because everything sucks a little bit—especially in computer programming.

Understanding the objections to various programming paradigms can help improve how you use them, by having an awareness of what others consider potential minefields. (And who knows, maybe the arguments will change your mind. You shouldn't be so quick to prejudge the material.)

Re: Why OO Sucks by Joe Armstrong (2000)

#34

Post by mikekchar »

chx wrote: post #21
peterashford wrote: post #15

I'm really sick of these 'why blah sucks' posts. Clearly OOP works for a lot of people. If it doesn't work for you, don't use it. My personal feeling is that FP works better when the problem domain is more data oriented, requiring transformation of data streams whereas OOP is good when the problem domain is about simulating or modeling where you want to think about interacting agents of some kind. The whole 'X is one…

> If it doesn't work for you, don't use it. How many of us actually get a choice in this...?

I wonder if it would be constructive to modify the OP's statement a little bit. You can get there from here using any approach (as long as it is Turing complete ;-) ). Some approaches will work better than others, but optimising your approach first and convincing others second is putting the cart before the horse. Having a happy team that works well together is going to provide at least an order of magnitude more ROI than choosing the best approach. Compromising on your approach to make others happy will almost certainly pay off hugely. Get good at as many types of approaches as you can so that you can take advantage of those payoffs. The cult of "I must use the absolute best approach for this problem, everyone else be damned" is one that leads to misery IMHO (especially if it turns out that your "best approach" isn't, which happens most of the time in my experience ;-) ).

Re: Why OO Sucks by Joe Armstrong (2000)

#36

Post by pvg »

mises wrote: post #27
bhaak wrote: post #13

Earlier quoted context omitted.

Why are you so sure the downvotes are not coming from the opinion of the "ridiculously pedantic OO of Java"?

Maybe because no body had commented as such until now? I am rather practical about this: I don't really like Java because it forces things that make more sense as functions to be under an object. What if I just want a simple global utility function, and don't want to make every single class inherit from a class containing only that? It's a lot of unnecessary hassle for something like that. I'm not saying OO is bad, I…

and don't want to make every single class inherit from a class containing only that

That's not how having a global utility function works in any OO language I can think of.

Re: Why OO Sucks by Joe Armstrong (2000)

#37

Post by enraged_camel »

peterashford wrote: post #15

I'm really sick of these 'why blah sucks' posts. Clearly OOP works for a lot of people. If it doesn't work for you, don't use it. My personal feeling is that FP works better when the problem domain is more data oriented, requiring transformation of data streams whereas OOP is good when the problem domain is about simulating or modeling where you want to think about interacting agents of some kind. The whole 'X is one…

Please refrain from such self-centered, flippant dismissals. They tend to get in the way of potentially good discussions.

>>Clearly OOP works for a lot of people.

Something can work for a lot of people, and still suck.

>> If it doesn't work for you, don't use it.

Language and tool choices in our industry are made by a tiny minority. In fact, sometimes the people making those decisions are not even developers themselves! From that perspective alone, articles like this one are valuable.

Aside from that though, the question isn't whether OOP "works" or not. Rather, it is when it works, and for how long, until you run into a myriad of problems, such as leaky abstractions or inheritance hell. These are worth discussing. If you disagree, you can move on. No need to voice your misgivings.

Re: Why OO Sucks by Joe Armstrong (2000)

#38

Post by S_A_P »

I agree with a lot of the arguments made in this post. However I think there is an assumption that programming is programming and there aren’t different problem sets to solve. To me, UI development lends itself naturally to the everything is an object paradigm. I need a button to start event x. Hmm the button needs to know what size it is and other miscellaneous attributes about itself. Oh it also should have a function that handles what to do when the button is pressed. Hey that sounds a lot like an object that has state, data structure and functions all in one. Now as we traverse the environment to basic CRUD type applications, OOP can be overkill. If all you want to do is pull x number of rows out of a database and put them in a dataset, do we really need objects for this? Nope. Most of the time the objects for these types of problems are just wrappers around an array of pointers. Creating DAO type objects is a lot of the time more trouble than it’s worth, but if were already in an OO paradigm, why switch?

Re: Why OO Sucks by Joe Armstrong (2000)

#39

Post by namelosw »

The biggest problem of OO languages for me is - it always depends.

Composition or inheritance or template or concrete? It depends. Extract methods? It depends. Design patterns? It depends.

Although to master good OO design - knowing what and when to do something - is surely an art, it doesn't handle dynamic business model very well.

If I just express the business, I cannot handle requirement change. If I want to deal with some future change, I have to do a lot of non-business oriented design, making the code less expressive.

And most of the OO language don't have algebra data types, which makes expressing business model more awkward.

Re: Why OO Sucks by Joe Armstrong (2000)

#40

Post by shortoncash »

chx wrote: post #21
peterashford wrote: post #15

I'm really sick of these 'why blah sucks' posts. Clearly OOP works for a lot of people. If it doesn't work for you, don't use it. My personal feeling is that FP works better when the problem domain is more data oriented, requiring transformation of data streams whereas OOP is good when the problem domain is about simulating or modeling where you want to think about interacting agents of some kind. The whole 'X is one…

> If it doesn't work for you, don't use it. How many of us actually get a choice in this...?

These days many languages are so expressive you can establish a dominant paradigm in the part of the code you work on. We have a kind of micro-level choice that even the most authoritarian code-reviews can't largely stamp out (provided that the interface you provide is in harmony with the rest of your organization.)
Post reply on HN