Is there a script or transcript anywhere, for those of us who can read 10x faster than it is possible to understand speech?
[deleted]
The Big OOPs: Anatomy of a Thirty-Five Year Mistake
51–60 of 193 posts
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#52This 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 forgotten and not brought over as a software design concept or methodology when OOP was making its way into new languages and being taught to future programmers.
There's lots of reasons for why this happened, and his long talk is going over the history and the key people and coming up with an explanatory narrative.
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#53Is there a script or transcript anywhere, for those of us who can read 10x faster than it is possible to understand speech?
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#54Any way to find out what the 35 year mistake was without being "engaged" for hours on that video?
Really short: ECS existed in the earliest implementations of OOP in 1963 and was being used in the software he showed.
When OOP went mainstream it pretty much was entirely about "compile time hierarchy of encapsulation that matches the domain model" and nothing else. His opinion is the standard way of doing OOP is a bad match for lots of software problems but became the one-size-fits-all solution as a result of ignorance.
Also he claims that history is being rewritten to some extent to say this wasn't the case and there was never a heavy emphasis on doing things that way.
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#55Earlier quoted context omitted.
There is a good book on DDD in F#, Domain Modelling Made Functional
Is there a similar recommended book using ML/OCaml or some other language of the family? i am hesitant to learn F#, knowing Microsoft's tendencies.
There are very few F# specific features used in the book. I imagine you could follow along pretty easily with any other functional language. You can easily use F# for the book and then apply the lessons learned to another language when you're done too. It mainly shows how to use sum types, product types and function composition to implement DDD.
I'm not sure what tendencies you're referring to though. F# has been around for 20 years and has only gotten better over time.
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#56Can 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.
Here's something that I think is in the direction Casey advocates for without being full-blown ECS:
https://gamedev.net/blogs/entry/2265481-oop-is-dead-long-liv...
As I posted on the video itself: https://news.ycombinator.com/item?id=44611240
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#57Can 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.
It's a bit of a long read, but I think the best introduction is still this [0] and the comments were here [1]. Yes, it's presented in the context of rust and gamedev, but ECS isn't actually specific to a particular programming language or problem domain.
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#58i love casey and I love this talk. Always good to see people outside of academia doing deep research and this corroborates allot of how I have understood the subject.
I find it funny that even after he goes into explicit detail about describing oop back to the original sources people either didn't watch it or are just blowing past his research to move the goal post and claim thats not actually what OOP is because they don't want to admit the industry is obsessed with a mistake just like waterfall and are too stockholm syndromed to realize
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#59Earlier quoted context omitted.
yes, because java and c# (and others, python to a certain extent) basically copied it. even ruby, which at its core is about "message passing" sure does a hell of a lot to hide that and make it feel c++ ish. i would bet at least 25% of ruby practitioners arent aware that message passing is happening.
at least python gives the flexibility to opt out of OOP, whereas in java, literally everything is an Object
What do you mean by this? Because everything in Python is object, even classes and functions are objects.
Do you just mean that Python lets you write functions not as part of a class? Because yeah there's the public static void main meme but static functions attached to a class is basically equivalent to Python free functions being attached to a module object.
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#60Earlier quoted context omitted.
yes, because java and c# (and others, python to a certain extent) basically copied it. even ruby, which at its core is about "message passing" sure does a hell of a lot to hide that and make it feel c++ ish. i would bet at least 25% of ruby practitioners arent aware that message passing is happening.
at least python gives the flexibility to opt out of OOP, whereas in java, literally everything is an Object
Everything is an object in Python as well