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

The Big OOPs: Anatomy of a Thirty-Five Year Mistake

computerenhance.com

Post reply on HN
Print view View original

161–170 of 193 posts

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#161

Post by sirwhinesalot »

pjmlp wrote: post #100
cloogshicer wrote: post #38

Can someone point to a real life example or tutorial/guide of the ECS architecture he proposes? I'd like to learn more about how to implement this.

Basically is programming against composable interfaces like COM, Objective-C protocols, and anything else like that, but sold in a way that anti-OOP folks kind of find acceptable, while feeling they aren't using that all mumbo jumbo bad OOP stuff some bad Java teachers gave them on high school. Most of them tend to even ignore books on the matter, like "Component Software: Beyond Object-Oriented Programming." [0], ra…

None of that is what people mean by ECS. ECS is a poor man's relational database. Do you think SQL is OOP too?

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#162

Post by igouy »

asa400 wrote: post #19
Rochus wrote: post #2

Entertaining. The presenter obviously doesn't like the class hierarchy to correspond to the domain model. He seems to think that this was an essential feature of OOP, supported by some quotations by Smalltalk exponents. But not even the Smalltalk world could agree on what OOP actually is (just compare the statements by Kay with the actual architecture of Smalltalk-76ff) and as quickly as Smalltalk lost its significan…

He literally gives extensive primary source citations to show that the originators of OOP presented this class-domain correspondence as the correct way to think about and do OOP. Bjarne Stroustrup is not just some random guy.

The source citations are facts. We can check that Alan Kay "The Early History of Smalltalk" shows this on page 82:

"Unfortunately, inheritance — though an incredibly powerful technique — has turned out to be very difficult for novices (and even professionals) to deal with."

When the presenter tells us — 13:45 "he was already saying he kind of soured on it" — that is not a fact, it's speculation. That speculation does not seem to be supported by what follows in "The Early History of Smalltalk".

One page later — "There were a variety of strong desires for a real inheritance mechanism from Adele and me, from Larry Tesler, who was working on desktop publishing, and from the grad students." page 83

And "A word about inheritance. … By the time Smalltalk-76 came along, Dan Ingalls had come up with a scheme that was Simula-like in it's semantics but could be incrementally changed on the fly to be in accord with our goals of close interaction. I was not completely thrilled with it because it seemed that we needed a better theory about inheritance entirely (and still do). … But no comprehensive and clean multiple inheritance scheme appeared that was compelling enough to surmount Dan's original Simula-like design." page 84

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#163

Post by JohnMakin »

imtringued wrote: post #135
lisbbb wrote: post #75

Earlier quoted context omitted.

The main issue I have with Java is that the JVM was built to be portable and then we got a superior kind of portability using containers, which makes the JVM totally redundant and yet whenever I point that out, I get funny looks from people! I guess I have a lot of other problems with Java--jar hell, of course, but also the total inability for corporations to update their junk to newer versions of Java because so man…

You do realize that it's time to sunset a codebase if you can't find anyone to maintain it, right? "LITERALLY IMPOSSIBLE" means the code is dead. It's worthless garbage dragging the company down. There is no nothing else to do except shut it down. Software written in the last century isn't something like an irreplaceable artifact from an ancient technologically superior civilization that can never be replicated. If h…

you realize the person you’re responding to didnt make this decision on what to use in their stack at all and this is likely what eventually happened anyway?

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#164

Post by ivanjermakov »

shuaiboi wrote: post #105
DavidPiper wrote: post #65

So much gold to mine in this talk. Even just this kind of throwaway line buried deep in the Q&A: > I prefer to write code in a verb-oriented way not an object-oriented way. ... It also has to do with what type of system you're making: whether people are going to be adding types to the system more frequently or whether they're going to be adding actions. I tend to find that people add actions more frequently. Suddenly…

bjarne (creator of c++) has a quote about this: Unified function call: The notational distinction between x.f(y) and f(x,y) comes from the flawed OO notion that there always is a single most important object for an operation. I made a mistake adopting that. It was a shallow understanding at the time (but extremely fashionable). Even then, I pointed to sqrt(2) and x+y as examples of problems caused by that view. https…

There is the most important argument regardless, whether it is a method or regular function - first one (or last one in languages supporting currying). While it's true that there are functions with parameters of equal importance, most of them are commutative anyway.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#165

Post by tw061023 »

It seems the community is severely overexposed to bad practices and implementations of OOP and conversely severely underexposed to the success stories.

153 comments as of time of writing, let's see.

C-F: Java: 21 C++: 31 Python: 23 C#: 2

And yet: Pascal: 1 (!) Delphi: 0 VCL: 0 Winforms: 0 Ruby: 2 (in one comment)

This is not a serious conversation about merits of OOP or lack thereof, just like Casey's presentation is not a serious analysis - just a man venting his personal grudges.

I get that, it's completely justified - Java has a culture of horrible overengineering and C++ is, well, C++, the object model is not even the worst part of that mess. But still, it feels like there is a lack of voices of people for whom the concept works well.

People can and will write horrible atrocities in any language with any methodologies; there is at least one widely used "modern C++" ECS implementation built with STL for example (which itself speaks volumes), and there is a vast universe of completely unreadable FP-style TypeScript code out there written by people far too consumed by what they can do to stop for a second and think if they should.

I don't know why Casey chose this particular hill to die on, and I honestly don't care, but we as a community should at least be curious if there are better ways to do our jobs. Sadly, common sense seems to have given way to dogma these days.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#166

Post by voidhorse »

troad wrote: post #79
voidhorse wrote: post #62

As someone who has always found popular OOP stupid (programming is closer to math , not linguistics —write functional programs!) I'm glad Casey is going out there and giving talks like this. If extensive academic research and extensively documented benefits couldn't convince the industry to abandon OOP in favor of functional style maybe an everyman like Casey finally can. A lot of so-called programmers and systems "e…

> programming is closer to math, not linguistics It's worth pointing out that actual linguistics is not unlike maths, e.g.: https://en.wikipedia.org/wiki/Formal_grammar , https://en.wikipedia.org/wiki/X-bar_theory , etc. There's an awful lot of vibes-and-feels nonsense about language in the popular press, which one ought not confuse with linguistics proper. In fact, as Casey mentions in this talk, a lot of the earlie…

Yes, of course there is a connection through the Chomskian mathematization of syntax.

But when we think about solving problems over domains and relations (e.g think about realizing that the problem of parsing requires traversing a tree like structure) we are dealing with mathematical-logical structures, not linguistic concepts. This is what I meant. I've seen a lot of OOP code that tried desperately to make code reflect the fuzzier relationships between linguistic concepts, rather than the precise ones of logical structure (a lot of this is a consequence of over-encapsulation and excessive information hiding)

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#167

Post by voidhorse »

fc417fc802 wrote: post #80
voidhorse wrote: post #62

As someone who has always found popular OOP stupid (programming is closer to math , not linguistics —write functional programs!) I'm glad Casey is going out there and giving talks like this. If extensive academic research and extensively documented benefits couldn't convince the industry to abandon OOP in favor of functional style maybe an everyman like Casey finally can. A lot of so-called programmers and systems "e…

> A lot of so-called programmers and systems "engineers" act like religious zealots. Rather ironic given that in this very comment section I'm largely seeing that behavior associated with people appealing to Casey as an authority as an excuse not to engage with intelligently written counterpoints. I certainly won't defend the historic OOP hype but a tool is not limited by how the majority happen to use it at any give…

This is completely true, of course—the only reason I'm being a bit hyperbolic is because some rebalancing is still in order.

I agree that once the field matures what we will really (hopefully) finally see are people adopting different modes of organization based on the second order systems properties they support, rather than ideology or personal experience—but we aren't there yet.

I think there are certain cases in which using an object oriented approach makes sense, but man, it has led to so many bloated, needlessly complicated systems in which the majority of the work is dealing with inanities imposed by OOP discipline and structure rather than dealing with the actual problem the system is supposed to solve.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#168

Post by pjmlp »

sirwhinesalot wrote: post #161
pjmlp wrote: post #100

Earlier quoted context omitted.

Basically is programming against composable interfaces like COM, Objective-C protocols, and anything else like that, but sold in a way that anti-OOP folks kind of find acceptable, while feeling they aren't using that all mumbo jumbo bad OOP stuff some bad Java teachers gave them on high school. Most of them tend to even ignore books on the matter, like "Component Software: Beyond Object-Oriented Programming." [0], ra…

None of that is what people mean by ECS. ECS is a poor man's relational database. Do you think SQL is OOP too?

People without CS background say a lot, like confusing ECS with data oriented design.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#169

Post by pjmlp »

nickitolas wrote: post #159
pjmlp wrote: post #157

Earlier quoted context omitted.

A pattern that relies on OOP constructs like protocols, interfaces, traits, depending on which language is being used. Arrays and structures mappings isn't ECS, that is Data Oriented Design, https://en.m.wikipedia.org/wiki/Data-oriented_design

Since you already quoted wikipedia, here's what it says about ECS: https://en.wikipedia.org/wiki/Entity_component_system > Entity–component–system (ECS) is a software architectural pattern mostly used in video game development for the representation of game world objects. An ECS comprises entities composed from components of data, with systems which operate on the components. > Entity: An entity represents a general-…

I was rather expecting code examples, so that we could deconstruct the language primitives being used for the implementation from a CS language semantics point of view.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#170

Post by sirwhinesalot »

pjmlp wrote: post #168
sirwhinesalot wrote: post #161

Earlier quoted context omitted.

None of that is what people mean by ECS. ECS is a poor man's relational database. Do you think SQL is OOP too?

People without CS background say a lot, like confusing ECS with data oriented design.

I have a PhD in computer science and I'm also able to stop for two seconds and understand what ECS as used by game devs means. It is pointed out in the talk that the design pattern was used in sketchpad of all things and reinvented in 1998. They call that pattern ECS. It is unfortunate the name is overloaded but that doesn't mean that when they say ECS they're referring to the ECS you are and it is somehow a gotcha since that other ECS is still very much OOP.

They are not talking about that ECS.

Post reply on HN