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

211–220 of 396 posts

Re: Why OO Sucks by Joe Armstrong (2000)

#211

Post by fiddlerwoaroof »

josephg wrote: post #210
fiddlerwoaroof wrote: post #88

Earlier quoted context omitted.

I think this is mostly a reflection of the thing Java/C#/C++ have popularized as “OOP”: if one uses Common Lisp’s CLOS, much of the boilerplate associated with “design patterns” and OO architecture evaporates.

Yes absolutely. The article was written around 2000 when Java was the new sexy thing. When Joe talks about OOP being overhyped, he wasn’t talking about Rust’s traits or Common Lisp. He’s speaking about the hype around Java and C++, and the then-lauded three pillars of OO: Encapsulation, Inheritance and Polymorphism. Not all OO works that way. In retrospect, inheritance was probably a mistake. And as far as I can tell…

My inclination is to say that inheritance isn't the mistake, the mistake is making methods part of a class: my experience with inheritance in CL is that having generic functions/methods as their own first-class construct makes inheritance less of a minefield.

Re: Why OO Sucks by Joe Armstrong (2000)

#213

Post by _0w8t »

revvx wrote: post #150
tux1968 wrote: post #137

Earlier 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…

C++, Java etc. all lack proper union types with appropriate pattern matching. So a lot of useful message passing patterns cannot be implemented without too much boilerplate.

Re: Why OO Sucks by Joe Armstrong (2000)

#214

Post by gmueckl »

BigJono wrote: post #139
gboudrias wrote: post #48

Earlier 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.

I get that "what don't I get?" feeling all the time. Overengineering is basically an epidemic at this point, at least in the JS/front-end industry. My guess is there's a correlation between overengineering and career success, which drives it. Simple, 'KISS' style code is the easiest to work with, but usually involves ditching less essential libraries and sticking more to standards, which looks crap on your resume. Mo…

Well, it depends on what you are doing. I designed some systems that were too complex and some that were too simple and couldn't grow as a result. So, with experience, one will hopefully see that supposed overengineering is sometimes only overengineering until you actually need that specific flexibility in a growing system. And there is little substitute for experience to know which is which.

Re: Why OO Sucks by Joe Armstrong (2000)

#215

Post by Gibbon1 »

kbp wrote: post #80
gboudrias wrote: post #48

Earlier 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…

> Python doesn't: o.x does not necessarily mean accessing an x slot

C# also 'fixes' that. o.x could be a slot or it could be a getter/setter.

Re: Why OO Sucks by Joe Armstrong (2000)

#216

Post by gmueckl »

wtracy wrote: post #121
gboudrias wrote: post #48

Earlier 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.

In the original JavaBeans spec, getters and setters served two purposes: 1. By declaring a getter without a setter, you could make a field read-only. 2. A setter could trigger other side effects. Specifically, the JavaBeans spec allowed for an arbitrary number of listeners to register callbacks that trigger whenever a value gets changed. Of course, nobody actually understood or correctly implemented all this, and it…

Finally someone mentions using getters to create read only fields. Objects are the owners and guardians of their own state. I don't see how this is possible without having (some) state-related fields that only can be read from the outside.

Re: Why OO Sucks by Joe Armstrong (2000)

#217

Post by xxs »

nurettin wrote: post #182
tux1968 wrote: post #137

Earlier 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?

When I think of message passing, I think of message queues. There should be an arbiter, a medium of message passing so you can control how that message is passed and how it will arrive. Java and C++ way of message passing both stripped that medium down to a simple vtable to look up what methods the object has. Erlang and go have the right idea of passing messages through a medium that can serialize and multiprocess i…

>both stripped that medium down to a simple vtable to look up what methods the object has.

If they use vtable it'd be just slow. Not needing the trampoline and ability to inline harder is what makes it fast. The usual case is class hierarchy analysis,static calls (no more than a single implementer proven by the compiler), guarded calls (check +inline, java deoptimizes, if need be), bi-morphic call site inline, inline caches and if that fails - the vtable thing.

Message passing in a classical way is just awfully slow for a bottom of the stack building block. It doesn't map to the hardware. It does makes sense for concurrency with bounded, lock free queues (actor model). But at some point, someone has to do the heavy lifting.

Re: Why OO Sucks by Joe Armstrong (2000)

#218

Post by xxs »

zmmmmm wrote: post #209
stickfigure wrote: post #118

Earlier quoted context omitted.

If you mark all fields and variables in Java as final , you get pretty much this experience? If I could go back in time and unilaterally make one change to Java, it would be to make `final` default. But if you just get in the habit of using it (the IDE helps), non-final variables look broken. And once objects have all-final fields, immutability just starts spreading upward in your code.

Unfortunately unlike C++ etc constness doesn't propagate inside objects marked final. So final List x = new ArrayList() stops x being reassigned but does nothing to stop the downstream code from mutating the contents of the list.

final List immutable = Collections.immutableList(x)... and pass it around.

Never expose your collections directly (unless you are willing to go copy on write and immutable objects inside the collections, the latter is very welcome, though)

Re: Why OO Sucks by Joe Armstrong (2000)

#219

Post by lsiebert »

lsiebert wrote: post #82

Object oriented programming isn't about an individual programmer. It's about creating discrete APIs so that a bunch of different programmers can work on different aspects or sections of code. It's an organizing principle for discrete elements that encapsulates internal state. You don't need to know your datastore is SQL or Redis, or Redis caching SQL data, or marshalled JSON, you just call Users.getUser(id), and get…

Not sure where people are getting the idea that I'm saying that OO is the only way to do abstraction and encapsulation.

I'm saying it is a way, and a sometimes useful one. Certainly when I'm thinking about a SQL schema, I'm often thinking about it using OO design principles, even though SQL is functional.

Re: Why OO Sucks by Joe Armstrong (2000)

#220

Post by pvg »

mises wrote: post #145
pvg wrote: post #36

Earlier quoted context omitted.

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.

You could also make a class of global functions and use that, but I think the point still stands: it forces square pegs into round holes, so to speak.

Any point can still stand if you completely change what you supposedly meant. It's an unassailable, impenetrable point.

A class with some static methods is just a namespace. In Java it pretty much turns OO off.

Post reply on HN