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

111–120 of 252 posts

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

#111

Post by jstimpfle »

Novashi wrote: post #100
jstimpfle wrote: post #83

Earlier quoted context omitted.

No, I'm not talking about one arithmetic CPU operation. I'm talking about simple, procedural hit(monster, weapon, damage). Why not in assembly? Because it's not worth the effort. You won't notice any difference in speed. Be pragmatic.

>I'm talking about simple, procedural hit(monster, weapon, damage). The moment your game needs to know anything else about that hit event, you're going to start creating side effects from that procedure and that QUICKLY snowballs into spaghetti code. Not to mention, just from the signature, that's going to be an absolutely huge procedure. >Because it's not worth the effort. You won't notice any difference in speed. B…

(monster, weapon, damage) is "the object". And yes, the procedure probably has "side effects". Because that's the point.

> Not to mention, just from the signature, that's going to be an absolutely huge procedure.

How do you intend to write less code with OOP?

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

#112

Post by alasdair_ »

bvrmn wrote: post #9
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…

> 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?

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

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

#113

Post by ActingMike »

jryan49 wrote: post #26

> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a c…

OOP is here to stay because it is the default model of how we see the world. You actually do not have to teach people to use this, just how to map it to the OOP Software Systems like Java/ C#.

It was great while Moors law still lasted, and to write efficient software was becoming some strange quest for some formula one fields of software like games or other massive workload fields like OS-Wizzardry.

Today, the massive workload is still growing, due to sloppy architectural habits and user demands, but the saviors of parallelization and new chip technologies have not come to rescue the sloppy-devs from the laws of leaky abstraction.

Your code runs on a hardware system.

And currently your code is running out of hardware.

And with that OOP is running out of excuses.

So you would write this. Then it would three months before the shipping be handed to some adult- and this adult will delete it. All of it.

Its full of references, full of class-bloat which will push one another out of the cache. Even though the compiler will try to yank the worst out this mental crutch out of the code. Some references can not be dismissed deterministically, so they will be kept. Which makes it incredible slow.

What replaces it will be a efficient structure, keeping all the chunks necessary for collision detection, in one very array like field.

Over this a Algo traverses, acting with a function, which does not reference non-local stuff, detecting collisions and damage. Allowing not only for a few players- but a workload of players.

It will look very ugly, like C, with inline assembler- ugly, and it will be ready to ship.

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

#114

Post by mabbo »

chx wrote: post #72
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…

Okay, so how would you model that in a different paradigm? And why could OOP not model that the same way?

Your example also doesn't specify a business context. What kind of software am I building such that I need to model a car and it's color? That simple question will entirely change how the OOP model is designed.

OOP is easy to teach because it's easy to use, to understand. But again, if you use simple poorly thought out OOP, it may work- just badly. And of course there's the problem of "those who can't do, teach" and often those teaching programming are poor programmers.

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

#115

Post by antialias »

crazygringo wrote: post #33
jryan49 wrote: post #26

> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a c…

Great point... but doesn't it continue to prove the author's point that this is needlessly complex? It strikes me as bad design if something as simple as an action (hit) now needs to become it's own class that is instantiated merely to execute a single function and then have to delete itself. That just feels like insane overhead/boilerplate, no? The argument here is that it's far better to have player and monster be…

It isn’t uncommon, nor is it bad design to define value classes that represent simple actions. This enables the action/command/event value to be reified, serialized, transmitted over the wire, deserialized, and potentially processed remotely, asynchronously, or by multiple arbitrary consumers.

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

#116

Post by scarface74 »

chx wrote: post #72
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…

In the real world?

If I’m programming in a monolith, I change the Color property to a List and I get a big red dot with the number of errors the change caused in the bottom of my IDE and it tells me all of the places I need to change the code.

If my car class is part of a Nuget package. I change the version number to represent a breaking a change following the standard semver semantics. When the consumer upgrades to the latest package, they either get warnings about Color being obsolete and use Colors instead or I just completely remove the Color property and they get a red dot and change their code or decide they don’t have time and keep the old package around for awhile.

If I’m writing an API, and since I did properly separate my domain model from my view model, I both map the first item in the Colors list to the Color property in my view model and I create another Colors property.

These are solved problems.

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

#117

Post by mpweiher »

gameswithgo wrote: post #86
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…

No true Scotsman. >Because it's easy There are lots of cases when forcing yourself to stick to OOP styles or programming is much less easy. You could look at various comparisons of code line counts of equivalent programs between C# and F# code as some basic examples. I don't mind having classes that can inherit available in a language, but languages like Java and C# that force you to use only those things leads to a…

> You could look at various comparisons of code line counts of equivalent programs between C# and F# code as some basic examples.

People have done this methodically, and the results may surprise you:

http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm

That's the one from 1996, there was a newer one that pretty much confirmed the results.

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

#118

Post by matthewmacleod »

tree_of_item wrote: post #76
matthewmacleod wrote: post #71

Earlier quoted context omitted.

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…

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.

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

#120

Post by scarface74 »

gameswithgo wrote: post #86
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…

No true Scotsman. >Because it's easy There are lots of cases when forcing yourself to stick to OOP styles or programming is much less easy. You could look at various comparisons of code line counts of equivalent programs between C# and F# code as some basic examples. I don't mind having classes that can inherit available in a language, but languages like Java and C# that force you to use only those things leads to a…

I agree. Even in Domain Driven Design, sometimes you just have transaction scripts. Call a spade a spade and write your code accordingly.
Post reply on HN