Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The faster you unlearn OOP, the better for you and your software

dpc.pw

Post reply on HN
Print view View original

71–80 of 252 posts

Re: The faster you unlearn OOP, the better for you and your software

#71

Post by matthewmacleod »

tree_of_item wrote: post #32
eitland wrote: post #6

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

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.

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.

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.

Re: The faster you unlearn OOP, the better for you and your software

#72

Post by chx »

mabbo wrote: post #47

I'm always confused when people criticize OOP, because most of the time the criticisms they use are just plain bad programming. Or they're using hyperbole that isn't really useful. You want to know why OOP is useful and common? Because it's easy. Easy things allow for faster development, faster onboarding of devs. Humans need a mental models of things and OOP very explicitly gives it. But like most easy things, OOP s…

> You want to know why OOP is useful and common? Because it's easy.

With as much proof as you have given, let me offer you a counterargument: it is common because academia loves OOP. It's easy to teach, it's easy to test. It is most decidedly not easy and very often not useful.

My favorite example of how everything falls apart in due time is the color of a car. That's it, right? A car has a color. A Porsche Panamera might be a "carbon grey metallic" and it's stunning, but that's just one color still. Aye, up until the Mini Cooper tells you they need two colors. This world doesn't fit the OOP straightjacket. Your programming course does but the real world doesn't and when it doesn't then pain follows.

Re: The faster you unlearn OOP, the better for you and your software

#73

Post by fermienrico »

mabbo wrote: post #47

I'm always confused when people criticize OOP, because most of the time the criticisms they use are just plain bad programming. Or they're using hyperbole that isn't really useful. You want to know why OOP is useful and common? Because it's easy. Easy things allow for faster development, faster onboarding of devs. Humans need a mental models of things and OOP very explicitly gives it. But like most easy things, OOP s…

New to OOP programming. Could you explain what sort of arguments are presented against using OOP? I am genuinely curious.

Re: The faster you unlearn OOP, the better for you and your software

#74

Post by corebit »

> Data is more important than code

Nope. Right there at the beginning is where the author goes off track.

Computation itself is the most important aspect of computing. Code and data are just complexity to manage.

> Do I have a Customer? It goes into class Customer. Do I have a rendering context? It goes into class RenderingContext.

I whole heartedly agree with this. The naive approach to domain modelling is to classify the primitives of a domain into classes and stop there. In actuality, the processor of those primitives is likely what your class should be, and those primitives ought to be methodless data structures.

I.e., OrderFulfiller instead of Customer and Part classes.

Re: The faster you unlearn OOP, the better for you and your software

#75

Post by jstimpfle »

mabbo wrote: post #47

I'm always confused when people criticize OOP, because most of the time the criticisms they use are just plain bad programming. Or they're using hyperbole that isn't really useful. You want to know why OOP is useful and common? Because it's easy. Easy things allow for faster development, faster onboarding of devs. Humans need a mental models of things and OOP very explicitly gives it. But like most easy things, OOP s…

Yes, OOP is easy. At least the layers of sedimentary cruft were comparatively easy to write. The parts that actually do something, not easier in the slightest. It's still procedural code that must move data. (Usually that code is much less straightforward in OOP because it has to deal with so much boilerplate that is in the way of accessing the actual data).

Re: The faster you unlearn OOP, the better for you and your software

#76

Post by tree_of_item »

matthewmacleod wrote: post #71
tree_of_item wrote: post #32

Earlier quoted context omitted.

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. 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. It's not. Developers from various backgrounds frequently fail to understand all different kinds of development paradigms, and I'v…

> 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".

Re: The faster you unlearn OOP, the better for you and your software

#77

Post by Novashi »

jstimpfle wrote: post #68
Novashi wrote: post #65

Earlier quoted context omitted.

>And this one line is why you're willing to setup all these crap boilerplate supporter classes and take a huge hit in runtime performance? Hits don't usually happen that often in games relative to everything else the engine is doing unless you're writing something like MMO server code that processes hits from thousands players. Yours is a classic case of over-optimizing, I think.

Over-optimizing as in, write the one obvious line instead of 15 lines of crap that are also slower?

Until you get a decent combat system in and now your hit has to go through 30+ calculations. It's almost never as simple as "monster.HP - damage".

Besides, if we really want to be snarky, why haven't you wrote it in assembly for performance?

Re: The faster you unlearn OOP, the better for you and your software

#78

Post by jryan49 »

jstimpfle wrote: post #68
Novashi wrote: post #65

Earlier quoted context omitted.

>And this one line is why you're willing to setup all these crap boilerplate supporter classes and take a huge hit in runtime performance? Hits don't usually happen that often in games relative to everything else the engine is doing unless you're writing something like MMO server code that processes hits from thousands players. Yours is a classic case of over-optimizing, I think.

Over-optimizing as in, write the one obvious line instead of 15 lines of crap that are also slower?

These examples are supposed to be examples, not what we would actually do in this specific case. In a huge enterprise system that has 500 different ways something could be done, in which your function would have 30 million if statements, all which is dependent on runtime behavior, polymorphism can help solve that problem.

Imagine there are hundreds of ways Hit can be implemented and used in different situations. That's the reason for breaking out this type of abstraction. I agree this example the author used isn't probably a clear one in which one should use OOP.

Re: The faster you unlearn OOP, the better for you and your software

#79

Post by kstenerud »

totemizer wrote: post #25
eitland wrote: post #6

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

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.

Re: The faster you unlearn OOP, the better for you and your software

#80

Post by alasdair_ »

> OOP programs tend to only grow and never shrink because OOP encourages it.

Most long-lived programs tend to grow, because people add new features to them. This isn't something unique to OOP.

As for growth of OOP programs in particular - does no one ever refactor anything? Shrinking OOP code through refactoring is a daily occurrence at almost every job I've ever had.

Post reply on HN