Hacker News Reader

Comment by eitland | Hacker News Reader

I read this quickly to see if this was the piece that should convince me.

It was not. It is, IMO, a collection of strawmen.

People have abused OOP? Yes.

But

- citing FizzBuzz Enterprise Edition (which is really funny even for us Java/.Net developers because it is so horribly wrong)

or writing this

- Because OOP requires scattering everything across many, many tiny encapsulated objects, the number of references to these objects explodes as well. OOP requires passing long lists of arguments everywhere or holding references to related objects directly to shortcut it.

again IMO, demonstrate that the author never really understood OOP.

What probably is true however is that a lot of people should unlearn the OOP they learned in school.

View on HN

>- Because OOP requires scattering everything across many, many tiny encapsulated objects, the number of references to these objects explodes as well. OOP requires passing long lists of arguments everywhere or holding references to related objects directly to shortcut it.

This drove me nuts too - it's the exact opposite of what OO design suggests to do. See: https://en.wikipedia.org/wiki/Law_of_Demeter

again IMO, demonstrate that the author never really understood OOP.

That's a "No true Scotchman/OOP" fallacy. The OOP that the author "never understood" is what we see ALL the time in enterprise and startup code.

There could be a better OOP (e.g. Alan Kay's definition of it), but that's not what people are taught or practice.

The OOP that the author "never understood" is what we see ALL the time in enterprise and startup code.

Well, is there a paradigm where you tend to see mostly good code? If so I’ve never come across it. Besides plenty of bad OO, I’ve seen bad functional programming, bad reactive programming, very bad state machines. Bad code is bad code.

(And what other categories of code are you thinking of, besides “enterprise and startup”? Those two would seem to cover a pretty wide range.)

>besides “enterprise and startup”

There are several:

FOSS projects like Gnome/KDE can be said are neither enterprise or startup.

Industrial coding (e.g. to control operations in a factory)

Embedded code.

Hobbyist projects.

Games.

Application development (desktop apps and co).

- Research software (e.g. scientific)

Yes, people have abused OOP and every other programming paradigm or tool as well. It's probably a necessary aspect to learning something new... do something contrived, atrocious, and trivial in order to understand the concepts.

The OOP naysayers seem to often knock the textbook examples, but there are a lot of creative things that can be done with OOP that get around the criticisms.

> again IMO, demonstrate that the author never really understood OOP.

I find arguments like this (legitimately fascinating). Obviously an amount of investment into learning common concepts is required. At the same time, if a topic is too complex for most to "truly understand" than it isnt useful.

How do we know the difference? What standards do we hold other coders to, and what expectations do we hold ourselves to?

I'd love to hear if there is much research on the topic. It is easy to find opinion articles, hard to fund data.

> What probably is true however is that a lot of people should unlearn the OOP they learned in school.

Can you provide references for proper OOP?

https://en.wikipedia.org/wiki/SOLID

I wish they would have taught me this in school. Instead, I learned that a cat is an animal, and a car has wheels, and a car is a vehicle. But not what any of these things have to do with one another and how to actually use them.

I saw many SOLID code bases hard to grasp and maintain because implementation hides data flow. The most evil workers are [D]-purists.

SOLID still doesn't accomplish what the author is criticizing in my opinion.

If I have a SOLID codebase, how do I unroll the object graph to get, say, a hydrated JSON representation of that? (this is the data focus the author is talking about).

I think a person who has maintained an ORM like Hibernate or Rails and wants a simple data projection without having to use their specific tools to do so implicitly understands this pain. A data oriented approach where records are passed through to the business logic as necessary doesn't have this problem.

SOLID still has things like "cat.drivesIn(car)", and so even if the concretions are supposedly hidden behind an abstraction of that interface, the coupling is right there: "drivesIn" irrevocably binds a cat and a car together. In a data oriented, more functional approach, there is a function which happens to know something about cats and cars, and it pulls in two separate records to do its work. This is more of an a la carte approach to building relationships, whereas SOLID makes every consumer potentially need to worry about that because the coupling is in the contract.

The I in solid sounds like a major issue WRT a cross-cutting concern like security, in which hermetically sealed should mean airtight, not a piecemeal approach, etc.

The Java Swing API is a good example of OOP done well.

Huh?

If there was a worse example of over-engineering and crappy difficult to use API that would be Swing.

Swing can't be the worst example, it has no JButtonFactory.

I'm not sure about that, how many methods does the JButton class have?

https://docs.oracle.com/javase/7/docs/api/javax/swing/JButto...

only a few more than the classes it inherits from :)

>Can you provide references for proper OOP?

Joshua Bloch's "Effective Java" is well worth a read. He outlines specific principles like "Favor composition over inheritance" (https://medium.com/@rufuszh90/effective-java-item-16-favour-...) in just a couple of pages each.

I also want to strongly recommend Martin Fowler's "Refactoring" since it covers a lot of "good" OOP design and gives practical advice on how to take bad code and make it better.

The original "gang of four" "Design Patterns" book is also pretty good, although definitely less practical than the other two.

Smalltalk does "OOP" properly because it focuses on message passing, the real benefit of "OOP". Any OOPL that isn't based on message passing is degenerate.

Right. Because Objective C and Smalltalk are such resounding successes, uh?

Going by what you write here, we should all praise PHP and Javascript.

Popularity amongst the masses of 9-5 brogrammers who code for money and have no artistic sense when it comes to programming doesn't really imply quality. All the programming languages that are truly technically great - today - have small userbases. They're not easily digestible by mediocre coders, require some upfront effort and an open mind. Since the vast majority of professional programmers today are average at best, languages like Erlang, Haskell, Ocaml, Lisp, Smalltalk will never be popular.

It follows then that when looking for quality one should actually reverse popularity.

You do not sound condescending at all!

While it's true that popularity does not equal quality, one should be careful to go full tilt in the other direction and assert that non popularity means quality.

Objective C and Smalltalk were decent languages twenty years ago, but terrible languages by today's modern standards, starting with the fact that they're both dynamically typed, which we know today, is an evolutionary dead end in PLT.

maybe this will then? http://www.smashcompany.com/technology/object-oriented-progr...

Unfortunately, no. While he hasa lot of good arguments, they're drowned out by his repeated use of logical fallacies to push his point across. This long, rambling piece simply comes off as him bullying the reader into agreeing with him.

Note that I'm not saying he doesn't have valid points hidden in that wall of text, but he's certainly lacking the social skills and reader empathy to land a good argument, and as a result its too exhausting to take him seriously.

> Complains about logical fallacies

> Immediately comments with logical fallacy.

While this is obviously wrong, it does serve to illustratea point: when dealing with controversial subjects, there is a tendency towards tribalism. When you're for one "side", the other side is by definition wrong, and you must defend your "side" at all costs. Any criticism of any aspect of your side is an attack against the tribe and by extension, you. An attack requires a counterattack, and since at this point the person is engaging their amygdala, even their most incorrect statements seem completely factual and rational to them.

It makes things like editors, languages, syntactic style, and development paradigms impossible to discuss rationally and reasonably.

Did you mean to reply to me with this comment? It has nothing to do with what I said.

Maybe you should go back and read it slowly, as it was a good argument.

> again IMO, demonstrate that the author never really understood OOP.

This is what they always say...strange how OOP is the one paradigm no one ever seems to understand, no matter how much is written about it. Seems to me like there isn't actually anything to understand.

Maybe you should go back and read it slowly, as it was a good argument.

Don't be a dick.

It's not. Developers from various backgrounds frequently fail to understand all different kinds of development paradigms, and I've seen _just_ as much awful imperative code as I have awful OO code.

> Don't be a dick.

Don't worry, I won't.

> iterative code

I'm not really sure what that is. But I notice OO is unique in that "you don't understand it" is always the main defense. The trouble is that, when people can't even agree on a definition of OO, it is genuinely not clear that there is anything to understand. There is always some OO best practice that is ill defined and contradicts the advice yesterday. No one from OO land seems to enjoy math very much so you don't get precise definitions, you get "patterns" and "I know it when I see it".

iterative code

That was a typo of "imperative", sorry.

But I notice OO is unique in that "you don't understand it" is always the main defense

It's really, really not. This kind of argument comes up in a number of places, and I think there's a commonality – it tends to appear where systems are flexible, open-ended, and easy to start using, such that people tend to pick them up without thinking about how and why they will be using the tool. You see the same thing with "agile" for example.

OO isn't complicated. At the most basic level, it's just taking a data structure that you might use in any other programming approach, and attaching functions to it as methods. Go is object-oriented in this sense, for example.

Problems arise when bad implementations of OO concepts appear – but pointing at say excessively-enterprise Java and saying "this is evidence that OO is bad" doesn't really hold any water.

Reply on news.ycombinator.com