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

131–140 of 252 posts

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

#131

Post by harimau777 »

When I'm coding, I often find myself in a situation where, in order to reach my goal, I need to use a "bad" language tool (e.g. eval), violate some principle of good coding (e.g. avoiding side effects), or just have to write ugly code. I've come to the conclusion that a lot of writing good code comes down to recognizing those situations and stepping back to find a way you can change your design or strategy to avoid needing the ugly code.

I've never quite liked OOP, but I struggle to say exactly why. I wonder if some of it is that the class structure and hierarchies makes it difficult to step back and change the design in order to avoid having to write ugly code.

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

#132

Post by scarface74 »

fenomas wrote: post #121
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…

> You end up with: > Player.hits(Monster).with(Weapon) I think games are a particularly pathological case for OOP, and as such probably not a good example for the article's case. But FWIW, the problem with what you describe (and with OOP for games generally) is that game logic tends to be way too polymorphic for code like that. That is, players don't just Hit() monsters, they also hit items, traps, breakable terrain,…

I find the fluent style programming to be much more readable. But in OOP you would define an IHittable interface or use AOP like you suggested.

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

#133

Post by jbverschoor »

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.

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

#134

Post by anothergoogler »

> Instead of a well-designed data store, OOP projects tend to look like a huge spaghetti graph of objects pointing at each other and methods taking long argument lists.

Uh, what? FP projects are the ones with crazy argument lists, has OP even heard of the Law of Demeter? Does FP magically prohibit a huge spaghetti graph of functions and ad-hoc types pointing at each other?

> The main point is: just because my software operates in a domain with concepts of eg. Customers and Orders, doesn't mean there is any Customer class, with methods associated with it.

What an observation, it's all a bucket of bits so why name anything? Rub your hands together, mutter an incantation and voila, software without all that obnoxious structure!

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

#135

Post by zippy5 »

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 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 pattern recognition become more difficult for all but the most experienced programmers.

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

#136

Post by _old_dude_ »

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…

Thank you for posting this snippet of code, to me, it acts like the episode of the madeleine in the Swann's way.

as you said, nowadays people are using String.split ``` List.of(str.split(",")) `` which is less poetic.

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

#137

Post by ergothus »

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…

> again IMO, demonstrate that the author never really understood OOP.

I find arguments like this (legitimately fascinating). Obviously an amount of investment into learning common concepts is required. At the same time, if a topic is too complex for most to "truly understand" than it isnt useful.

How do we know the difference? What standards do we hold other coders to, and what expectations do we hold ourselves to?

I'd love to hear if there is much research on the topic. It is easy to find opinion articles, hard to fund data.

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

#138

Post by ubercow13 »

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.

How's that any different to a 'classical OOP' approach?

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

#139

Post by e40 »

PopeDotNinja wrote: post #127
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. Try rewriting that without adjectives. Engineers are very convincible, but they need evidence. Personally, I don't find OOP to be particularly useful or easy. Check this out... "I became a much better programmer when I started writing functional code. Now I tend to write OOP code in a functional way, but learning how to do that was and not easy, and…

My problem with OOP is debugging it when things go wrong.
Post reply on HN