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?
Joe Armstrong: Why OO Sucks
21–30 of 267 posts
Re: Joe Armstrong: Why OO Sucks
#22I 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?
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
#23A 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
Re: Joe Armstrong: Why OO Sucks
#24OO 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…
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
#25Where 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
#26What 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?
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
#27Languages that are "OO" and languages that are not (in this case functions and data structures) are semantically equivalent. Q.E.D.
Re: Joe Armstrong: Why OO Sucks
#28From 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.
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
#29Use a function when you need a function, and a class when you need a class.
Re: Joe Armstrong: Why OO Sucks
#30Having an 'x' and hitting '.' and seeing what 'x' knows to do with itself doesn't suck.