Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OOP Is Dead, Long Live OOP

gamedev.net

Post reply on HN
Print view View original

251–260 of 357 posts

Re: OOP Is Dead, Long Live OOP

#251

Post by ilovecaching »

loup-vaillant wrote: post #231
derefr wrote: post #210

Earlier quoted context omitted.

> Again, I take OOP to mean what one learns in school Don't do that, then. "OOP" is a term-of-art in an academic discipline. It means exactly what it was used to mean by the people who coined the term in the papers they coined it in. The thing that schools teach under the name "OOP" is a https://en.wikipedia.org/wiki/Lie-to-children intended to introduce something vaguely like OOP, not to introduce OOP itself. --- An…

Most people take "OOP" to mean what schools told them. And that's why "OOP" does mean that. Because most people vaguely agreed on some blurry definition, and use it. The fact that "OOP" is no longer used to point to what Alan Kay originally meant is immaterial. It's a shame, but that train has passed.

Yep

Re: OOP Is Dead, Long Live OOP

#252

Post by Hodgman »

SolarNet wrote: post #184

Everything here is bad and wrong on so many levels. It's hard to even wrap my head around the amount of wrong going on everywhere here. The initial Object Oriented (OO) code - as partially demonstrated by the author, and more succinctly by the grand-author - is badly designed. In the grand-author's slides they remove a number of these stupidities, which the author appears to ignore (both for final performance compari…

The fact the the original code is a straw-man is discussed. The fact the flexibility is being removed is discussed too, along with why it was there and hits on better ways to re-achieve it later. It's mentioned that these were going to be covered in a follow-up. You need to work on your speed reading skills before throwing shade...

Re: OOP Is Dead, Long Live OOP

#253

Post by derefr »

loup-vaillant wrote: post #231
derefr wrote: post #210

Earlier quoted context omitted.

> Again, I take OOP to mean what one learns in school Don't do that, then. "OOP" is a term-of-art in an academic discipline. It means exactly what it was used to mean by the people who coined the term in the papers they coined it in. The thing that schools teach under the name "OOP" is a https://en.wikipedia.org/wiki/Lie-to-children intended to introduce something vaguely like OOP, not to introduce OOP itself. --- An…

Most people take "OOP" to mean what schools told them. And that's why "OOP" does mean that. Because most people vaguely agreed on some blurry definition, and use it. The fact that "OOP" is no longer used to point to what Alan Kay originally meant is immaterial. It's a shame, but that train has passed.

I know you're arguing for "words are communication", and I'm a writer, so I certainly I agree with that. In general.

OOP is not a word, though. It's a jargon term. You can't redefine those. They mean what they originally meant, because if they don't, then you lose the ability to understand what the people doing real work using the word by its proper definition are doing. Jargon terms don't drift.

To be clear, I'm mostly talking about the same thing that is true of the term "Begging the question." Laymen can use it to mean whatever they want—and I don't begrudge them that, it's a phrase in a language and people will do what they like with it. But that lay-usage will never change what the phrase means in the context of formal deductive reasoning.

Likewise, programmers can use "objects" and "OOP" to mean whatever they want it to mean—but when having a formal academic discussion about programming language theory, an "object" refers to a specific thing (that came about in LISP at MIT before even Kay; Kay just was the first to write down his observations of the properties of "objects") and "OOP" refers to programming that focuses on such "objects" (as implemented in Smalltalk, CLOS, POSIX processes, Erlang processes, bacteria sharing plasmids, or computers on a network; but not by C++ or Java class-instances.)

I don't think we disagree, here; you're arguing that the lay-usage is X, and the lay-usage is X. I'm just pointing out that the lay-usage is irrelevant in the context of a discussion that requires formal academic analysis of the concept.

Re: OOP Is Dead, Long Live OOP

#254

Post by zumu »

ilovecaching wrote: post #99

Becoming a professional Haskell and Erlang developer really shifted my view on OOP (let OOP denote class based OOP as found in Java or C++). In my view, OOP is prove a poor model for computation, and the result has been that OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functional, or structured paradigm. Recent trends in language design (s…

Are you hiring? Where are these mythical FP jobs?

Re: OOP Is Dead, Long Live OOP

#255

Post by antidesitter »

tcbawo wrote: post #233
westoncb wrote: post #193

Earlier quoted context omitted.

For some reason 'arguments' against OOP seem to follow a common pattern. You have said many things against OOP, but you haven't actually presented an argument for why it's bad. I'll present each of your assertions here individually to clarify. > OOP is prove a poor model for computation > OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functi…

Bad code is bad code, no matter which language. Languages won't save you from poor design choices. OOP is popular in large enterprise systems because it (purports to) promote encapsulation and abstraction, which allows many teams/people to interact. Organizations may like OOP because it helps reinforce their drive for independence and fiefdom (see Conway's law https://en.m.wikipedia.org/wiki/Conway%27s_law ). Whether…

> Bad code is bad code, no matter which language.

It’s easier to write bad code in some languages than others.

> Languages won't save you from poor design choices.

They do. They save you from entire classes of bugs, and make it less easy to shoot yourself in the foot.

Do we need to have this conversation every time we talk about language design? Do you think the tool you use to achieve a task doesn’t matter?

Re: OOP Is Dead, Long Live OOP

#256

Post by Hodgman »

LiterallyDoge wrote: post #16

I don't understand why this article is so angry? ECS is a great subset of OOP. Both are helpful tools where they make sense.

It's because every single article that's promoting ECS does so by comparing it against incorrect inheritance-based code. The amount of time you see newbies jumping on the ECS bandwagon because inheritance is bad, while they don't yet understand OOP, ECS, procedural, relational, or functional... is infuriating.

Do both. Teach how to use composition. Teach how to use the relational model. Don't avoid teaching either by using misleading sales tactics.

Re: OOP Is Dead, Long Live OOP

#257

Post by n0n »

ilovecaching wrote: post #99

Becoming a professional Haskell and Erlang developer really shifted my view on OOP (let OOP denote class based OOP as found in Java or C++). In my view, OOP is prove a poor model for computation, and the result has been that OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functional, or structured paradigm. Recent trends in language design (s…

Interesting view. How should i, as a sysadmin who just writes bash and powershell scripts, start to learn _serious_ programming? Is it still worth to force myself into OOP?

Re: OOP Is Dead, Long Live OOP

#258

Post by Hodgman »

beders wrote: post #63

I think OOP is fine as long as it's the only thing you are doing and as long as it is single-threaded. Problems will occur if you need to convert the innards of your objects to data (i.e. JSON etc.), if you need to materialize objects from data (i.e. ORM) or if you need to write multi-threading safe code. If you expose things as data, just be honest about it and treat it as such. It's already out in the open, why hid…

Follow up articles in that series are going to show how to make it multi-threading and OO-compliant. "Typical" bad OOP code is a threading nightmare because the flow of control and flow of data becomes impossible to follow - it's all just random objects calling random objects calling random objects. Not spaghetti code, but spaghetti flow. To write threadable OOP, you need to avoid fine grained polymorphism and deep call graphs. Instead of doing work immediately by calling out to the next object, return some results to your caller and allow them to make the call. This also allows your caller to collect large batches of work a'la DOD... which often actually increases performance (much better I$ and D$ usage) AND it's also much closer to old school OO message passing theory, and assist in writing simple, decoupled components.

I'd go as far to say that even if you're not targeting multiple threads, accounting for them in this way (NOT the stupid "just put a lock on each object" way) results in much better/simpler code.

Re: OOP Is Dead, Long Live OOP

#260

Post by dragonwriter »

derefr wrote: post #253
loup-vaillant wrote: post #231

Earlier quoted context omitted.

Most people take "OOP" to mean what schools told them. And that's why "OOP" does mean that. Because most people vaguely agreed on some blurry definition, and use it. The fact that "OOP" is no longer used to point to what Alan Kay originally meant is immaterial. It's a shame, but that train has passed.

I know you're arguing for "words are communication", and I'm a writer, so I certainly I agree with that. In general. OOP is not a word, though. It's a jargon term . You can't redefine those. They mean what they originally meant, because if they don't, then you lose the ability to understand what the people doing real work using the word by its proper definition are doing. Jargon terms don't drift . To be clear, I'm m…

> OOP is not a word, though. It's a jargon term.

Jargon terms are a subset of words.

> You can't redefine those.

You can. Anyone that's been around computing knows that “functional programming” (and even “imperative programming”, which at one point contrasted with structured programming) have drifted

> Jargon terms don't drift.

Jargon terms absolutely drift (and get overloaded) for the same reason as other terms do,the difference is the community of use in which those factors which drive drift/overloading operate.

> To be clear, I'm mostly talking about the same thing that is true of the term "Begging the question." Laymen can use it to mean whatever they want—and I don't begrudge them that, it's a phrase in a language and people will do what they like with it. But that lay-usage will never change what the phrase means in the context of formal deductive reasoning.

Mostly aside, but the popular alternative usage of that phrase is transitive verb phrase, and the older usage is an intransitive verb phrase (which, while this is clearly reversing the etymology, can be viewed as a special case of the transitive form with a particular direct object assumed) so the two neither conflict nor are incompatible. So, it's kind of a bad example of anything other than reflexive pedantry; accepting the alternative usage in formal circles wouldn't be drift or overloading because it is structurally distinct.

Post reply on HN