Live data from Hacker News

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

computerenhance.com

61–70 of 193 posts

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

#61
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…

[deleted]

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

#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 "engineers" act like religious zealots. Even challenging the ideas of OOP is blasphemy to them, even though there are many legitimate reasons to do so.

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

#63
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…

It's funny because I read this comment and then watched the video, and it's like the first 15 minutes of the talk are dedicated to debunking this exact comment. Freaky.

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

#64

This is an excellent talk. It digs really deep into the history of OOP, from 1963 to 1998. The point is that in 1998 the commercial game "Thief" was developed using an entity component system (ECS) architecture and not regular OOP. This is the earliest example he knows of in modern commercial programming. During his research into the history of OOP he discovered that ECS existed as early as 1963, but was largely forg…

Thank you for this summary. I'm a hobbyist programmer and want to watch this, but having a few concepts to hang my hat helps contextualize this for me.

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

#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 clicked for me why some people/languages prefer doThing(X, Y) vs. X.doThing(Y)

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

#66

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…

I was around when OOP became popular in the 90s. I think it was a huge step forward. Problem is that with almost every useful paradigm at some point consultants and zealots take over and push things to an extreme that doesn't work. And when problems show up, it's because you didn't do it right. Happened with OOP, NoSQL, Agile and probably many others. I don't see how functional style won't go differently.

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

#67

And on the other end of the spectrum, you have the proponents of Domain-driven design (DDD)[0], where they use an ML descended language such as F# and the aim is to make invalid states unrepresentable by the program [1] [0] https://fsharpforfunandprofit.com/ddd/ [1] Make invalid states unrepresentable: https://geeklaunch.io/blog/make-invalid-states-unrepresentab...

How is this "the other end of the spectrum"? The Typestate pattern described at https://geeklaunch.io/blog/make-invalid-states-unrepresentab... (especially wrt. its genericized variety that's quite commonly used in Rust) is precisely a "compile-time hierarchy of encapsulation that matches the domain model", to use Casey Muratori's term for what he's talking about. It's literally inheritance-based OOP in a trenchcoat.

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

#68
post #5

Any way to find out what the 35 year mistake was without being "engaged" for hours on that video?

Basically his “35-year mistake” thesis is that we almost had ECS, the entity/component/system pattern, in 01963 with Sketchpad, but it took until 01998. He explains this near the end of the talk proper, and explains how Looking Glass in 01998 introduced the pattern in Ultima II Underworld, but really introduced it with Tom Leonard’s Thief: The Dark Project. Later though he seems to be saying that he's not sure ECS is actually a good idea, but he thinks encapsulation is, if not a bad idea, at least an idea that should be applied carefully to keep it from getting in your way, and definitely not in a way that reflects a division among problem-domain objects such as cars, trucks, bridges, circular arcs, lanterns, etc.

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

#69

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.

Look for data-oriented design [0] (not to be confused with domain-driven design) in addition to ECS.

[0] https://www.dataorienteddesign.com/dodbook/

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

#70

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…

More info on "The Expression Problem" https://en.wikipedia.org/wiki/Expression_problem
Post reply on HN