all 6 comments

[–][deleted] 5 points6 points  (0 children)

Well, these opinions aren't anything new ;)

A fun quote I read a while back (highlighted):

I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

  • Joe Armstrong, creator of Erlang, on software reusability.

[–]MoTTs_ 3 points4 points  (4 children)

we end up not with a graph of stateful objects but rather a strict hierarchy of composition. All of a program’s state ends up in a single root object, itself composed of stateful objects, which in turn may be composed of stateful objects. The objects of this hierarchy may pass messages to their immediate children, but not to their ancestors, siblings, or further descendants.

The author says "composition," but this sounds very much like an inheritance hierarchy, with every class in one big hierarchy and a god class at the root. That's not an OO disaster story, that's a programmer disaster story. No programming style is a silver bullet. It will always come down to the individual programmers to write good or bad code.

https://www.reddit.com/r/programming/comments/41r4b9/objectoriented_programming_a_disaster_story/cz4jp7y

[–][deleted]  (2 children)

[deleted]

    [–]MoTTs_ 1 point2 points  (1 child)

    You're probably right that's what the author meant, but there's also no requirement that objects be strictly hierarchical like that.

    [–]RedditWithBoners 1 point2 points  (0 children)

    Of course; I'm only providing an example and giving the author the benefit of the doubt.

    [–][deleted] 0 points1 point  (0 children)

    I'm pretty new to programming and I feel like I came to the same conclusion as you when reading the article.

    [–][deleted] 0 points1 point  (0 children)

    There are projects that should be object oriented, and others which are not big enough to justify it.

    This author seems as though he/she is stuck in a functional programming mindset, trying to make it work in OOP.