The faster you unlearn OOP, the better for you and your software • Hacker News Board

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

#51

Post by Novashi » Sun, Nov 25, 2018, 2:17 PM UTC

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…

Hit is an event that occurs, so not sure why it should escape OO even though in this example even though it's only decreasing ints. I routinely code event objects rather than modifying another class directly by the delta that should occur. OO isn't good for continuous time and events but it does add ergonomic convenience for the developer in this case (there could be other information on the hit, a historical list of Hits looks better as List rather than List, it's easier to inspect a hit object during debugging rather than setting watches on player/monster/weapon values).

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

#52

Post by jryan49 » Sun, Nov 25, 2018, 2:18 PM UTC

> Encouraging complexity

Picking a satire piece on how something can be abused is not a great argument of "this thing is bad".

For example, I'd argue anything written in an OOP language is going to be more readable than this (from the obfuscated C contest) https://www.ioccc.org/2018/algmyr/prog.c

Also, complex systems tend to benefit from OOP because complex systems can have multiple combinations of behaviors. Something IMO OOP is useful for.

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

#53

Post by hliyan » Sun, Nov 25, 2018, 2:19 PM UTC

nyc111 wrote: post #21

hliyan wrote: post #10

This has been shared on HN many years ago, but I'm linking again in case there are younger engineers who might be unaware of this classic rant: Execution in the Kingdom of Nouns : https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

That was great. I read it for the first time. Similar scenarios happen in so many other fields. Some bad idea takes hold. Then schools teach it. Then more people invest time learning it so that they cannot admit it is bad and this goes spreading like wildfire and become sacred...

And then someone discovers that the old way was better and gives it a new name. When I was in school, functional programming was called "programming".

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

#54

Post by jcelerier » Sun, Nov 25, 2018, 2:20 PM UTC

jdub wrote: post #3

adnzzzzZ wrote: post #2

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

Entity-Component-System, amusingly explained in this great talk from RustConf. https://www.youtube.com/watch?v=aKLntZcp27M

but... all ECS systems use classes or equivalent at some point

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

#55

Post by stevelosh » Sun, Nov 25, 2018, 2:21 PM UTC

jcelerier wrote: post #49

ced wrote: post #40

I've never liked classical OOP much, but multiple dispatch is a lovely paradigm. One doesn't define _classes_ per se, but rather just plain old boring structs. struct Player xp::Int end struct Monster hp::Int end function hit(p::Player, m::Monster) p.xp += 10 m.hp -= 20 end The nicest thing is how one one doesn't need inheritance to "add a method" to an object. One just defines my_function(s::String) to be whatever,…

> One doesn't define _classes_ per se, but rather just plain old boring structs. in which language are there differences between classes and structs ?

Common Lisp

http://www.lispworks.com/documentation/lw70/CLHS/Body/m_defs...

http://clhs.lisp.se/Body/m_defcla.htm

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

#56

Post by coldtea » Sun, Nov 25, 2018, 2:22 PM UTC

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…

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

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.

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

#57

Post by arriu » Sun, Nov 25, 2018, 2:22 PM UTC

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…

This does read nicely in most cases.

There are minor issues when you venture off and decide that it would be cool if a monsters could damage your weapon. Something like Monster.hits(Weapon).with(Weapon). You'll start wondering if Weapon should inherit from the player base class. If not, you'll spend time wondering how to share the code to keep things dry. Obviously there are many solutions even within OOP, but one might consider looking to ECS to remove code duplication and decouple things.

Lots of good examples in the game programming patterns book: http://gameprogrammingpatterns.com/component.html

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

#58

Post by ygra » Sun, Nov 25, 2018, 2:22 PM UTC

jcelerier wrote: post #49

ced wrote: post #40

I've never liked classical OOP much, but multiple dispatch is a lovely paradigm. One doesn't define _classes_ per se, but rather just plain old boring structs. struct Player xp::Int end struct Monster hp::Int end function hit(p::Player, m::Monster) p.xp += 10 m.hp -= 20 end The nicest thing is how one one doesn't need inheritance to "add a method" to an object. One just defines my_function(s::String) to be whatever,…

> One doesn't define _classes_ per se, but rather just plain old boring structs. in which language are there differences between classes and structs ?

Of the languages i know, C++ and C# come to mind. Granted, in C++ the differences are fairly minor and inconsequential at runtime.

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

#59

Post by wffurr » Sun, Nov 25, 2018, 2:22 PM UTC

jcelerier wrote: post #49

ced wrote: post #40

I've never liked classical OOP much, but multiple dispatch is a lovely paradigm. One doesn't define _classes_ per se, but rather just plain old boring structs. struct Player xp::Int end struct Monster hp::Int end function hit(p::Player, m::Monster) p.xp += 10 m.hp -= 20 end The nicest thing is how one one doesn't need inheritance to "add a method" to an object. One just defines my_function(s::String) to be whatever,…

> One doesn't define _classes_ per se, but rather just plain old boring structs. in which language are there differences between classes and structs ?

"struct" here is meant in the same sense that the author of the post refers to "PoD objects". Just data in public fields.

Whereas a "class" is usually thought of as private data exposed only through methods.

There is no language that enforces this distinction; it's purely by convention. C++ makes it a little simpler by having a different default access level.

In any case, you are being needlessly pedantic and missing the point.

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

#60

Post by [deleted] » Sun, Nov 25, 2018, 2:23 PM UTC

jcelerier wrote: post #49

ced wrote: post #40

I've never liked classical OOP much, but multiple dispatch is a lovely paradigm. One doesn't define _classes_ per se, but rather just plain old boring structs. struct Player xp::Int end struct Monster hp::Int end function hit(p::Player, m::Monster) p.xp += 10 m.hp -= 20 end The nicest thing is how one one doesn't need inheritance to "add a method" to an object. One just defines my_function(s::String) to be whatever,…

> One doesn't define _classes_ per se, but rather just plain old boring structs. in which language are there differences between classes and structs ?

[deleted]