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

91–100 of 252 posts

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

#91

Post by letstrynvm »

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…

It's maybe confusing because you are presupposing OOP as the default. Humans tend to observe some situation and sythesize stories to explain it, even when it comes to observing their own actions.

I don't mean to unfairly paraphrase but to transpose what you wrote so it shows these stories you are telling yourself

- usually people criticising OOP are "bad programmers"

- OOP is easy, alternatives are hard

- Even if OOP model is a bad fit, it's still a model and the extra devs needed to solve its bad fit can easily be chained to the oars

- If OOP makes trouble, it was because it was "done badly"

- Most easy things work well enough even if "done badly" (that is just not true)

- If OOP can be cobbled together to work at all, it is justified since that justifies anything

If you consider a simpler proposition like, "this can be done in a few hundred or thousand lines of C99 instead of latest C++ and boost", I think there is just no valid reason to bring OOP into it.

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

#92

Post by matwood »

corebit wrote: post #74

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

I disagree. SICP says "“In programming, we deal with two kinds of elements: procedures and data.” If we reduce that further it is really just data.

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

#93

Post by hliyan »

fermienrico wrote: post #73
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.

I've been programming for 15 years (so I was around for the rise of OOP). There's nothing fundamentally wrong with OOP. I still write a lot of classes. But what I haven't written in a almost a decade: code with inheritance, encapsulation or polymorphism. Nothing has exploded.

Also, objects are best when used to represent actual objects (i.e. collections of data rather than collections of functions).

This is OK

    User user = new User("John");
But this:

    StringTokenizer st = new StringTokenizer(str, ",");
    while (st.hasMoreElements()) {
      System.out.println(st.nextElement());
    }
Might not be as clean as:

   stdout(tokenize(str, ",")); // functions are hypothetical

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

#94

Post by kangoo1707 »

devocracy wrote: post #89
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…

Refactor, with the right IDE this should take minutes. OOP witbout something like intellij or VS.NET is not fun.

What does OOP has anything to do with your IDE. I think you are referring to typings

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

#95

Post by dnautics »

totemizer wrote: post #27
dnautics wrote: post #22

Should be pointed out that this refers to C++/Java/Ruby/python style objects, and not smalltalk/erlang style objects, which is a message passing model for data storage.

And you do the first thing this author describes: http://www.smashcompany.com/technology/object-oriented-progr...

Not really. Almost no one would call erlang or elixir an Oop language, but one basically does everything using Kay's style.

No true Scotsman doesn't apply when the original definition legitimately shifts

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

#96

Post by coldtea »

corebit wrote: post #74

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

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

Of course you're gonna write some computation, else there would be no program. That's not the point here.

First, author doesn't mean "data" as in what comes in, it means the data structures of a program.

Second, for the purposes of designing a program (and its computation part) data structures are a better guiding principle than objects. That's the argument being made.

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

#97

Post by matthewmacleod »

jstimpfle wrote: post #31
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…

> It does read kind of nicely IMO... 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?

I'm pretty confused by how you perceive this. I don't see "crap boilerplate supporter classes" – I see objects that encapsulate events and actors for all the usual OOP reasons.

I wonder if some of this disagreement is down to the way that different people abstract this problem in their heads.

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

#98

Post by alasdair_ »

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.

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

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

#99

Post by wedowhatwedo »

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…

Why is color of a car an issue with OOP? Without knowing your the use cases, neither of us will model it correctly for the job at hand.

A car obviously has multiple colors. It has at least two: exterior and interior. Quite often there are two-tone colors. But as a manufacturer, I'm going to guess that each interior and exterior color scheme has an ID. If you are a car manufacturer, the interior and exterior color scheme ID would be all you need.

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

#100

Post by Novashi »

jstimpfle wrote: post #83
Novashi wrote: post #77

Earlier quoted context omitted.

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?

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

That's the exact same case I'm making. A hit object every so often will have no impact on performance (certainly not a huge impact) like you originally said and you gain developer productivity.

Post reply on HN