Live data from Hacker News

Joe Armstrong: Why OO Sucks

harmful.cat-v.org

21–30 of 267 posts

Re: Joe Armstrong: Why OO Sucks

#21

There's a certain allure to saying code should be a certain way because of natural properties of computing, or our own feelings on what things are different and similar from what other things. The reason OO shines is because it allows you to make that distinction at the domain level rather than the code level. You organize your software into business objects, or components, and have these interact with each other. Th…

Isn't that a bit of a false dilemma though? Can you not have clean interfaces and separation of concerns without OO -- even with something as 'simple' as python namespaces and dicts?

Dicts are objects.

Re: Joe Armstrong: Why OO Sucks

#22
post #9

I don't get it. If people don't like OO, why don't they just not use it. Just use your favorite methodology to get the job done. Why do they have to bad mouth it?

Because they want to promote discussion and exchange opinions, and maybe advice others against something that they think is a bad idea. To just silently avoid stuff is a very stifling and unproductive way to handle things.

They do not badmouth OOP. It is not a human being with reputation and feelings. They criticize its usage.

Re: Joe Armstrong: Why OO Sucks

#23
post #3

A series of assertions and "I just don't see it"-s presented as self-evident when they are anything but. No examples of real cases where OO does in fact "suck", ending with the claim that in order to understand the popularity of OO one should "follow the money". What? I mean, I don't even...

harmful.cat-v.org has a lot of odd opinions: http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/political-correctness/girls-in-CS

Dynamic linking seems to be a rather straightforward technical argument. I'm not sure what to tell you if you can't or won't parse it.

Re: Joe Armstrong: Why OO Sucks

#24

OO vs. FP is just a matter of whether you focus the nouns or the verbs. The counterargument to the OP is that surely a function that manipulates "data" is less powerful and abstract than one that manipulates objects. For example, take an "interface" or abstract data type like Array, consisting of a length() and a get(i) method. (This is really called List in Java and Seq in Scala.) There may even be an associated typ…

In Haskell I guess it would look like this: I'm still new to Haskell hopefully someone can improve it?

    data M = M1 | M2 | M3 deriving(Show, Eq, Ord)

    fromM M1 = 1
    fromM M2 = 2
    fromM M3 = 3

    instance Num M where
      abs = abs
      a + b = fromInteger (mod ((fromM a) + (fromM b)) 3)
      a * b = fromInteger (mod ((fromM a) * (fromM b)) 3)
      a - b = fromInteger (mod (abs $ (fromM a) - (fromM b)) 3)
      fromInteger 0 = M3
      fromInteger 1 = M1
      fromInteger 2 = M2
      fromInteger 3 = M3
Is this what you're looking for? :)

Re: Joe Armstrong: Why OO Sucks

#25
99% of the time I read these articles that say $commonly_used_thing [1] sucks, the arguments are always "it is fundamentally incorrect" or some variant thereof [2], and strawmen [3] abound.

Where these arguments fall short are in addressing the simple fact that highly-skilled people produce very neat, well-designed systems that they are pretty happy with from a technical standpoint, and that make money every single day using $commonly_used_thing. If you can't acknowledge that $commonly_used_thing has some good attributes, and that it actually works well for many cases, I don't understand why I should take you seriously.

[1]: Examples of commonly_used_thing: ORMs, OOP, SQL databases, NoSQL databases, operating systems, platforms.

[2]: There are a handful of variants. I think my favorite is the magical phrase "impedance mismatch", which I think in non-buzzword-speak translates to "fuck you, I'm right"

[3]: Most-frequent strawman: the most essentialist, rigidly-formal version of $commonly_used_thing, when in reality, nearly every version of $commonly_used_thing compromises to cope with reality.

Re: Joe Armstrong: Why OO Sucks

#26
post #16

What about the benefits of abstraction? I'm not going to introduce hyperbole on how I think this article is overstated, and instead I'm going to ask HN members who have more experience with functional programming how they leverage concepts similar to abstraction with Haskell, clojure, or erlang, etc?

> What about the benefits of abstraction?

You seem to have a strangely narrow definition of "abstraction". Start here: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#...

Re: Joe Armstrong: Why OO Sucks

#27

Languages that are "OO" and languages that are not (in this case functions and data structures) are semantically equivalent. Q.E.D.

It is possible in principle to implement one in terms of the other, but in practice this is not what typically happens.

Re: Joe Armstrong: Why OO Sucks

#28
post #12

From a purely scientific view, OO is a terrible idea because it moves the program further away from the mathematical form and makes it harder (if not impossible) to say, logically prove the correctness of the program. But from a practical perspective OO is a great idea because it makes many things so much easier.

"But from a practical perspective OO is a great idea because it makes many things so much easier."

This seems true at first, but after having worked with C# a while I'm not so sure about that. OO introduces some weird issues that aren't immediately apparent: 1. Verbosity When the shortest method call looks like "abcObject.functionXYZ()", code gets huge really fast character-wise. This actually does make it harder to read and debug existing code.

2. Multithreading Multithreading in any programming paradigm is a pain, I'd give you that. But OO exacerbates the problem because of the way each property of an object is essentially a global state within its local scope. It makes it quite tricky to enforce thread safety.

Having said that, I'm not sure that rewriting it in, say, a functional style would make things simpler. Sure it is easier to prove correctness, but as soon as you introduce IOs, everything goes to hell. I guess OO seems to be the worst pattern, except for all others that have been tried.

Re: Joe Armstrong: Why OO Sucks

#29
OO is just one design pattern of many; it should be used when the mental model is a good fit for the problem domain. It does annoy me, though, when languages or frameworks force the use OO when it's unneeded.

Use a function when you need a function, and a class when you need a class.

Re: Joe Armstrong: Why OO Sucks

#30
I find grouping functional code along with the data the code is supposed to work on reasonably intuitive. The OO religionists definitely sold the world a bill of goods on the reuse arguments, and the religious fervor was silly (just like it is with todays functional zealots) but still.

Having an 'x' and hitting '.' and seeing what 'x' knows to do with itself doesn't suck.

Post reply on HN