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

171–180 of 252 posts

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

#171

Post by naasking »

zippy5 wrote: post #135
gameswithgo wrote: post #86

Earlier quoted context omitted.

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 would suggest that boilerplate is small price to pay for having a compiler enforce design discipline and conventions. Remember that code should be written for both the run time environment and next coder who will have to understand it. Constraints enforced in java often make it easier for the next dev. I suspect part of this is that in unconstrained languages, there are so many ways of doing the same thing that pat…

> 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 since it's only a few lines of code.

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

#172

Post by Novashi »

jstimpfle wrote: post #150
Novashi wrote: post #129

Earlier quoted context omitted.

>(monster, weapon, damage) is "the object". Now an environment flag causes fire damage to deal +10% more. You're either going to have to extend the hit method again (further complicating it), or just pull that flag from the environment class in the procedure body itself (undeclared dependency). When something else outside monster/weapon/damage/environment has to change the hit calculations, you'll have to extend it a…

> When something else outside monster/weapon/damage/environment has to change the hit calculations When something should change, you edit the freakin' code. There is no way around it. If you have different kinds of hits then you make different procedures. e.g. magicPixieDustHit(monster, pixieDust, weapon, damage). > Side effects are terrible for maintenance and debugging FP apologetists want to make you believe that,…

>When something should change, you edit the freakin' code. If you have different kinds of hits then you make different procedures. e.g. magicPixieDustHit(monster, pixieDust, weapon, damage).

I dunno, maybe aim for something a little better than writing an exponential amount of functions for all of your interactions.

>FP apologetists want to make you believe that, but side effects are the actual point of the program.

If you want to make all of your co-workers hate you because randomProcedure changes shared state when it shouldn't, go right ahead. If you want to stop that, you're like two steps away from OOP's dependency injection when you write validator functions on the shared state object.

>I mean at least acknowledge that that's a highly subjective statement...

Games are about the worst choice for criticizing OOP because OOP is so useful for describing games. Procedural style is fine for Pong or Sudoku or really simple games, I guess. It's highly subjective in-so-far as the entire industry has mostly adopted it and released great games with it.

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

#173

Post by naasking »

hliyan wrote: post #93
fermienrico wrote: post #73

Earlier quoted context omitted.

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

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

Except these aren't objects, they're just records. I don't think it's a good idea to pollute the word "object" or OOP. You use objects specifically when you need procedural abstraction, otherwise you use other types of values, like products/records, sums/variants, etc.

At high system levels, where you have client/server or other types of protocols, objects fit. At lower levels other paradigms tend to be better.

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

#174

Post by jstimpfle »

Novashi wrote: post #172
jstimpfle wrote: post #150

Earlier quoted context omitted.

> When something else outside monster/weapon/damage/environment has to change the hit calculations When something should change, you edit the freakin' code. There is no way around it. If you have different kinds of hits then you make different procedures. e.g. magicPixieDustHit(monster, pixieDust, weapon, damage). > Side effects are terrible for maintenance and debugging FP apologetists want to make you believe that,…

>When something should change, you edit the freakin' code. If you have different kinds of hits then you make different procedures. e.g. magicPixieDustHit(monster, pixieDust, weapon, damage). I dunno, maybe aim for something a little better than writing an exponential amount of functions for all of your interactions. >FP apologetists want to make you believe that, but side effects are the actual point of the program.…

> I dunno, maybe aim for something a little better than writing an exponential amount of functions for all of your interactions.

You mean "polynomial". And you are still not acknowledging that OOP doesn't help there either. There is only one way out: You as the programmer must do the sensible thing. If you really need runtime polymorphism (which you rarely need, if you structure things correctly and keep separate things separate), then for god's sake go ahead and do it. But in my opinion it's much cleaner to do it with explicit function pointers.

> Games... > the entire industry has mostly adopted it and released great games with it.

I think you are at least 10 to 20 years late. The games industry, especially in the AAA sector where performance is critical, seems to long have acknowledged that OOP doesn't work out.

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

#175

Post by VLM »

Sometimes the best way to decide what to do, is a OOP-like 100,000 line long legal code. Sometimes the best way to decide what to do, is something short and sweet yet possibly not entirely clear, like the Ten Commandments. When what the original designers chose was correct, everything will work quickly and reliably. When they don't, you'll suffer for a long time. Given that, you'll spend almost all of your wall clock time suffering and complaining about the designers selection being wrong. With a side effect of most of your suffering will be due to poorly implemented examples of the dominant paradigm. "AKA OOP SUX"

In summary, given all of the above, there are two true statements that OOP works AND simultaneously you'll spend almost all of your mental effort on OOP not working. Generally, OOP being inappropriately hyper dominant at this time, means that non-OOP solutions will utterly master some very low hanging fruit for first movers who abandon OOP.

I've seen some truly horrific object relational mappers trying to connect OOP to inherently functional software APIs, hardware device interfaces, "chronological engineering" in general, and persistent data stores. Not surprising if you're working in those areas, abandoning OOP will lead to massive success.

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

#176

Post by iainmerrick »

coldtea wrote: post #56
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 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 startup”? Those two would seem to cover a pretty wide range.)

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

#177

Post by scarface74 »

letstrynvm wrote: post #91
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…

Even when I was writing C, I had different modules in different files, only exposed certain functions via the header files and had structs with function pointers that did different things based on how the struct was initialized.

This was before I knew anything about OOP. How is this any different than object oriented programming?

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

#178

Post by matthewmacleod »

jstimpfle wrote: post #168
matthewmacleod wrote: post #97

Earlier quoted context omitted.

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.

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

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

#179

Post by scarface74 »

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…

The information hiding and namespacing aspects of objects are really useful, both in theory and in practice. It's just that I think that implementation inheritance is an imperfect way of facilitating code reuse and not something you should teach to new students...

And most professionals agree with you. “Prefer aggregation over inheritance.”

Which by the way Resharper makes really easy. You add a private variable to your class of the type you want to aggregate and it creates wrapper methods in your aggregating class that just calls your other class.

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

#180

Post by scarface74 »

naasking wrote: post #171
zippy5 wrote: post #135

Earlier quoted context omitted.

I would suggest that boilerplate is small price to pay for having a compiler enforce design discipline and conventions. Remember that code should be written for both the run time environment and next coder who will have to understand it. Constraints enforced in java often make it easier for the next dev. I suspect part of this is that in unconstrained languages, there are so many ways of doing the same thing that pat…

> 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.
Post reply on HN