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…
The Big OOPs: Anatomy of a Thirty-Five Year Mistake
61–70 of 193 posts
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#62A 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
#63Entertaining. 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…
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#64This 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…
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#65> 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
#66As 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…
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#67And 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...
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#68Any way to find out what the 35 year mistake was without being "engaged" for hours on that video?
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#69Can 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.
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#70So 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…