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

181–190 of 252 posts

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

#181

Post by naasking »

ActingMike wrote: post #113
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 massiv…

> OOP is here to stay because it is the default model of how we see the world

A common but false statement. Firstly, there is no standard definition of OOP, only loose sets of features that define various overlapping but disjoint paradigms that some subset of people call OO. So your statement is meaningless as there is no single OOP that we identify as how "people see the world".

Secondly, even given any specific definition of OOP, it's also false. There are many programs that simply aren't suited to OO modelling, because you want to express things as the problem being solved actually requires, and this is often not OO. Sometimes pattern matching is best (compilers), sometimes reactive/event paradigm is best (servers, UIs), and neither of these are OO, as but two examples.

And don't take my word for it, there are a few studies on novice programmers showing quite clearly that event-based temporal reactive primitives are what people find most intuitively natural, ie. when account balance <= O then do some action, which is a declarative reactive action that will execute when that condition becomes true. This is not an OO program in any sense.

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

#182

Post by ced »

jbverschoor wrote: post #133
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,…

Ok nice, then you get a huge if tree for all different monsters and weapons.

What do you mean? It wouldn't be "if". You'd just have

   function hit(p::Player, m::Goblin)
       ...
   end
   function hit(p::Player, o::Ogre)
       ...
   end
In Julia, there's limited inheritance, so you could group monsters in a hierarchy to limit the redundancy (eg. Goblin <: Monster <: Creature). Or you can use multiple dispatch like a trait system, to get even greater flexibility.

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

#183

Post by szastupov »

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…

> Player.hits(Monster).with(Weapon)

The problem is that it's an artificial example, in reality you'll ave a lot of different monsters, weapons, and most importantly separate subsystems. I.e. physics processed in one pass, animation in another, same goes for custom logic and rendering.

Modern game engines use component systems that put data first for the same reasons author described in the post.

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

#184

Post by naasking »

scarface74 wrote: post #180
naasking wrote: post #171

Earlier quoted context omitted.

> pattern recognition become more difficult for all but the most experienced programmers. In fact the opposite is the case. The boilerplate obscures underlying patterns because it forces you to read twice as much to infer the same amount of information. Roughly the same design patterns are used in more expressive languages, just without all the boilerplate. This makes the pattern being employed completely obvious sin…

Once you use a language for awhile you develop boilerplate blindness just like people have developed ad banner blindness.

I'm sure, and yet it remains true that you spend a lot more time scanning and scrolling your wheel mouse than is necessary. You can also fit far less context on screen, making debugging and "learnability" harder.

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

#185

Post by brians »

fmap wrote: post #130
chx wrote: post #72

Earlier quoted context omitted.

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

> it is common because academia loves OOP. Absolutely not! I doubt that anybody was ever taught OOP in an academic PL course, unless it was really an "introduction to programming" course, or their professor was working on this topic at the moment. The meaning of a program in an object oriented language with imperative features and inheritance is not pretty. There are aspects of object oriented programming that are us…

It’s in SICP, leading up to the adventure game project. That dominated intro-PL conversations for a long time. Also, it’s OO with delegation-based inheritance, prototypes—and some discussion of why.

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

#186

Post by coldtea »

iainmerrick wrote: post #176
coldtea wrote: post #56

Earlier quoted context omitted.

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

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

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

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

#187

Post by scarface74 »

iokevins wrote: post #170
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…

Eric Lippert discusses this here (2015): https://ericlippert.com/2015/04/27/wizards-and-warriors-part...

First I had to have restraint to not downvote you for making me go down that very interesting 5 post rabbit hole....

Second, in one of the articles I found one of the best quotes I’ve ever heard about when not to use exceptions....

When you’re writing code in the IDE, it is correct code that is the exception!

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

#188

Post by oliwarner »

It's crazy how passionately people get behind their preferred paradigm. I think they all have a place, and can all be abused severely.

I'm all for people —at least those who don't answer to me— picking one and running with it, but if you're going to try and tear another one down, at least make sure you understand what it does for the people that like it. TFA's author does not appear to.

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

#189

Post by jstimpfle »

matthewmacleod wrote: post #178
jstimpfle wrote: post #168

Earlier quoted context omitted.

// player.hits(monster).with(weapon) add to class Player { // XXX: Bad coupling Player -> Monster // XXX: Bad coupling Player -> PlayerMonsterHit method hits(Monster monster) { return PlayerMonsterHit(player, monster) } } class PlayerMonsterHit { member Player player; member Monster monster; construct PlayerMonsterHit(Player player, Monster monster) { this.player = player; this.monster = monster; } method with(Weapon…

They don't "do nothing" - they define structure that can then be used to handle more implementation later. It's a ridiculous, contrived example, and you know that. Yes – this code is stupid if all you need to implement is a single line with the ability for a player to hit a monster. But that's never what you are implementing, is it?

If you want to delay the hit, i.e. transactioning / buffering / delaying: This is sound engineering! But that part is not even included in above boilerplate. It would be:

    struct PlayerMonsterWeaponHit {
        Player player;
        Monster monster;
        Weapon weapon;
    }

    Array playerMonsterWeaponHits;

    doTheActualFrigginHit(Player player, Monster monster, Weapon weapon) {
        playerMonsterWeaponHits.emplace(player, monster, weapon);
    }
In case it isn't obvious you can do that with either implementation, the above OOP boilerplate or the above imperative 1 line of code.

> Yes – this code is stupid if all you need to implement is a single line

No, it's stupid because it doesn't do anything. The data structures are only for temporaries that will never have any other use. In the end it's going to be PlayerMonsterWeaponHit. So the other classes are just stupid, and no amount of context will change that.

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

#190

Post by kstenerud »

bearjaws wrote: post #109
kstenerud wrote: post #79

Earlier quoted context omitted.

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

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

Post reply on HN