Why OO Sucks by Joe Armstrong (2000) • Hacker News Board

Re: Why OO Sucks by Joe Armstrong (2000)

#301

Post by revvx » Mon, Apr 22, 2019, 2:36 PM UTC

andybak wrote: post #227

revvx wrote: post #178

Earlier quoted context omitted.

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

I don't think it has anything to do with dynamic or static typing, but more to do with teams, libraries and program design.

I've had terrible experiences with complexity and verbosity in Ruby and Python codebases, which are dynamically typed. On the other hand, I worked with super expressive and simple to work codebases in C# and Haskell. And I had the opposite experience as well in other times.

It is absolutely possible to have the cake and eat it in this regard.

In fact I'd consider Haskell way more expressive than any dynamic language I ever worked with.

Re: Why OO Sucks by Joe Armstrong (2000)

#302

Post by peeters » Mon, Apr 22, 2019, 2:37 PM UTC

endgame wrote: post #152

vhb wrote: post #111

Earlier quoted context omitted.

> Upvoted because it's well-articulated, even though I disagree. Appreciate it :) > There is a key distinction: If I have two subsystems that use the same data in different ways, I can keep those concerns separate by putting the functions for each concern into a different module. Binding all the functions to the type mixes the concerns together and creates objects with way too much surface area. This is where composi…

> This is where composition helps. It does, though in my experience it leads you down a path that ends in some pretty strange names, as you nominalise more and more nebulous concepts, trying to verb in the kingdom of nouns.

Is that any different from foldl, foldr, reduce, map? If you have a generic data type you want your operators to be generic, regardless of whether they exist as methods or as separate functions. The only difference is that the object is free to not leak internal implementation details.

Re: Why OO Sucks by Joe Armstrong (2000)

#303

Post by tombert » Mon, Apr 22, 2019, 2:39 PM UTC

revvx wrote: post #178

tombert wrote: post #72

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

Yeah, I had similar issues with Rails as well; I feel people can be a bit too liberal with creating files, but I personally follow this mantra when I do it: does the benefit of separation worth the obfuscation introduced by adding a partition? Sometimes it is, and then I make a new file.

This is a bit of shameless self-promotion, but I've actually written a framework that's MVC-ish that lets you create really declarative APIs. The first version is written in NodeJS that I actually deployed in production [1], and I have an Erlang port that's semi-complete that I've recently started hacking on again [2], with the whole crux of it that you should be able to simply declare the composition of your actions.

[1] https://gitlab.com/tombert/frameworkeyPromiseEdition [2] https://gitlab.com/tombert/Frameworkey-Erlang

Re: Why OO Sucks by Joe Armstrong (2000)

#304

Post by stonefarfalle » Mon, Apr 22, 2019, 2:44 PM UTC

Objection 1: Given a queue, priority queue, and stack, how do those data structures "just exist", without the behavior associated with them? The interactaction with them is their defining characteristic.

Objection 2: I agree not everything should be an object. However where do you draw the line? To me a timestamp is a perfectly reasonable object. I can see the pros and cons of "3" being an object as well.

Objection 3: I like things to be organized. What benfit do I get by jumbling everything together in one spot?

Objection 4: Yes they do, pretending they don't doesn't help. Even in Haskell, files and sockets are represented as an opaque handle to hidden state. It very much looks like a OO interface in a non OO language. Given the three data structures in objection 1, hiding the state allows for a smaller surface area to prove that the data structures are correctly implemented. Allowing random access to their state does not improve them.

Re: Why OO Sucks by Joe Armstrong (2000)

#305

Post by tcgv » Mon, Apr 22, 2019, 2:45 PM UTC

andybak wrote: post #226

kbp wrote: post #80

Earlier quoted context omitted.

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 "bo…

> At other times the important thing is to provide a flexible, fluent public interface that can be used in ways you didn't intend.

That scares me. How do you maintain and extend software used in ways you didn't intend?

Quality assurance should be challenging.

Re: Why OO Sucks by Joe Armstrong (2000)

#306

Post by tombert » Mon, Apr 22, 2019, 2:46 PM UTC

revvx wrote: post #301

andybak wrote: post #227

Earlier quoted context omitted.

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

I don't think it has anything to do with dynamic or static typing, but more to do with teams, libraries and program design. I've had terrible experiences with complexity and verbosity in Ruby and Python codebases, which are dynamically typed. On the other hand, I worked with super expressive and simple to work codebases in C# and Haskell. And I had the opposite experience as well in other times. It is absolutely poss…

I love Haskell, and I agree that it's expressive, but any language with a nominal type system like Haskell is inherently going to be less expressive than a dynamic language.

Compare these functions, one in JS and one in Haskell:

    function F (x) {
       var first = x.first;
       var second = x.second;
       return first + second; 
    }

vs.

    F :: (HasX a, HasY a) => a -> a
    F foo = (x foo) + (y foo)

(I'm a little outta practice with both langauges, but my point will still stand)

With the JS version, F can take in any expression that has the properties of `x` and `y`, while with the Haskell version, the type has to implement the typeclasses `HasX` and `HasY`. While the Haskell version is still better than something like Java because you can implement a typeclass without modifying the core datatype, it's still inherently less expressive.

I'm not saying that it's not worth it (cuz Haskell is awesome for everything but records), but it's still less immediately reusable.

Re: Why OO Sucks by Joe Armstrong (2000)

#307

Post by jhomedall » Mon, Apr 22, 2019, 2:48 PM UTC

hota_mazi wrote: post #262

pkolaczk wrote: post #207

Earlier quoted context omitted.

Scala. Particularly Scala 3. Because it is principled but also very pragmatic.

Scala failed because it's the opposite of pragmatic. If you're looking for pragmatic, take a look at Kotlin. As for Scala 3, it's still years away, if it ever comes out. And when it does, there's little reason to think its goals will be different from what Scala 2 was (an academic language) since it's the same team as Scala 2 writing it.

In what way is Scala not pragmatic?

Re: Why OO Sucks by Joe Armstrong (2000)

#308

Post by 0x445442 » Mon, Apr 22, 2019, 2:54 PM UTC

Nasrudith wrote: post #280

revvx wrote: post #163

Earlier quoted context omitted.

In my experience, getter/setter abuse is always an attempt to use classes as a structs/records. I wonder if we had different syntax for those cases we'd have less of them. But then, again, it's very convenient to be able to add a method to a class that was previously a dumb struct.

Maybe I am a complete philistine but is that really a bad thing or just something which goes against their categorism? I get that there are some circumstances where setters would break assumptions but classes are meant to be worked with, period.

Objects are meant to have a life cycle in which the state should only be changed by the object itself. Setters violate this idea by allowing the sender of the message direct control over the state of the object.

A simplistic example: account.deposit(100) may directly add 100 to the account's balance and a subsequent call to account.balance() may answer 100 more than when account.deposit(100) was called. But those details are up to that instance of the account not the sender of those messages. The sender should not be able to mutate account.balance directly, whether it be via direct access to the field or through the proxy of a setter.

Re: Why OO Sucks by Joe Armstrong (2000)

#309

Post by revvx » Mon, Apr 22, 2019, 2:56 PM UTC

Nasrudith wrote: post #280

revvx wrote: post #163

Earlier quoted context omitted.

In my experience, getter/setter abuse is always an attempt to use classes as a structs/records. I wonder if we had different syntax for those cases we'd have less of them. But then, again, it's very convenient to be able to add a method to a class that was previously a dumb struct.

Maybe I am a complete philistine but is that really a bad thing or just something which goes against their categorism? I get that there are some circumstances where setters would break assumptions but classes are meant to be worked with, period.

It's not exactly a bad thing, it's just that you're using a hammer (class) when what you actually need is a screwdriver (struct/record).

Abusing getters/setters is breaking encapsulation (I said abusing, light use is ok). If you're just going to expose all the innards of the class, why start with a Class?

The whole point of object orientation to put data and behavior together. That's probably the only thing that both the C++/Java and the Smalltalk camp agrees on.

Separating data and the behavior into two different classes breaks that. You're effectively making two classes, each with "half of a responsibility". I can argue that this breaks SRP and the Demeter principle in one go.

Another thing: Abuse of getters/setters is often a symptom of procedural code disguised as OOP code. If you're not going to use what is probably the single biggest advantages of OOP, why use it at all?

-

Here's an answer that elaborates on this that I like:

https://softwareengineering.stackexchange.com/questions/2180...

Re: Why OO Sucks by Joe Armstrong (2000)

#310

Post by tempguy9999 » Mon, Apr 22, 2019, 3:23 PM UTC

revvx wrote: post #309

Nasrudith wrote: post #280

Earlier quoted context omitted.

Maybe I am a complete philistine but is that really a bad thing or just something which goes against their categorism? I get that there are some circumstances where setters would break assumptions but classes are meant to be worked with, period.

It's not exactly a bad thing, it's just that you're using a hammer (class) when what you actually need is a screwdriver (struct/record). Abusing getters/setters is breaking encapsulation (I said abusing, light use is ok). If you're just going to expose all the innards of the class, why start with a Class? The whole point of object orientation to put data and behavior together. That's probably the only thing that both…

> The whole point of object orientation to put data and behavior together

May I politely disagree based on my long-ago experience with dylan, which has multi-methods (" rel="nofollow">https://en.wikipedia.org/wiki/Multimethods>). This allowed the action on the data (the methods) to be defined separate from the data. I strongly feel that it was OO done right, and it felt right. You can read about it on the wiki link but it likely won't click until you play with it.

I'd like to give an example but it's too long ago and I don't have any to hand, sorry.