Live data from Hacker News

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

dpc.pw

41–50 of 252 posts

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

#41

A lot of these initial points I don't think are relevant -- you can model your data in objects, data structures are complex because business needs are complex, data models wind up having implicit graph dependencies as well... BUT, "cross-cutting concerns" is where I think the main valid argument is. In my experience, OOP is just way too restrictive of a model, by forcing you to shoehorn data and code into an object h…

>In my experience, OOP is just way too restrictive of a model...

Maybe, but if it's cross cutting concerns that bother you, just combine OOP with an aspect oriented programming library.

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

#43
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,…

Roughly that exact design but with classes was my instant thought.

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

#45
I find that I generally agree. However, I have the intuition that good data-oriented design requires an exceptionally solid understanding of the problem domain.

You might say that any good design requires that. I'm not going to disagree. But if there's a place for OOP, maybe it is as a preliminary abstraction, something to hold the chaos at bay while we build our understanding of the task at hand.

Of course, preliminary abstraction has a nasty habit of becoming permanent.

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

#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 still works well enough even when it's done badly. That's not a bad thing. Working software beats non-working software.

We shouldn't be telling people "stop using OOP! It's only for idiots!". OOP will be here forever. We should be teaching people how to do OOP right, what the pitfalls are that lead to bad design, and how to take badly designed OOP and fix it.

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

#48

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.

Could someone enlighten me as to how Java style OOP differs from Smalltalk's variant? I've read the Alan Kay quote on how he's sorry for focusing on objects instead of message passing but I'm still unsure on how Smalltalk is so much better not having used it.

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

#49
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 ?

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

#50
post #7

Some things never die. comp.object on usenet (15+ years ago) had a regular 'guest' explaining why table-oriented programming is better than OOP: http://www.oocities.org/tablizer/top.htm

Wow, that brings back memories....
Post reply on HN