The Big OOPs: Anatomy of a Thirty-Five Year Mistake
1–10 of 193 posts
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#2Entertaining. 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 significance, there is no need to mention it further. I would rather look at a reputable industry organization such as IEEE, which even publishes its own standards and best practices, what OOP is about. E.g. the OOP Milestone (see https://ethw.org/Milestones:Object-Oriented_Programming,_196...) which names Simula 67 the first OO language, specifies OO as "the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation." No mention of the class hierarchy should correspond to the domain model. So maybe we should just not mix up a programming paradigm with how it is used by some folks in practice? The fact that the loudest proponents of a paradigm are not usually those who apply it in practice remains true even today. Takes far less than 2.5 hours to state.
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#3The presentation was recently discussed at:
https://news.ycombinator.com/item?id=44596554 [video] (37 comments)
This current posted link is an article by Casey Muratori with supplementary material on topics to explore further.
- Early History of Smalltalk
- History of C++
- Development of the Simula Languages
- Origins of the APT Language for Automatically Programmed Tools
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#4The presentation was recently discussed at: https://news.ycombinator.com/item?id=44596554 [video] (37 comments) This current posted link is an article by Casey Muratori with supplementary material on topics to explore further. - Early History of Smalltalk - History of C++ - Development of the Simula Languages - Origins of the APT Language for Automatically Programmed Tools
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#5Any 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
#6Is 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
#7Any way to find out what the 35 year mistake was without being "engaged" for hours on that video?
OOPs = "object-oriented programming", BUT it's a more restrained and thoughtful complaint than just "objects suck" or "inheritance sucks". He cabins it pretty clearly at 11:00 minutes in: "compile-time hierarchy of encapsulation that matches the domain model was a mistake"
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#8Any way to find out what the 35 year mistake was without being "engaged" for hours on that video?
I don't know, but given the page, I think it is OOPS.
Object oriented programming.
Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#9Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake
#10Any way to find out what the 35 year mistake was without being "engaged" for hours on that video?
OOPs = "object-oriented programming", BUT it's a more restrained and thoughtful complaint than just "objects suck" or "inheritance sucks". He cabins it pretty clearly at 11:00 minutes in: "compile-time hierarchy of encapsulation that matches the domain model was a mistake"
To unpack that a little, he looks to the writings of the early developers of object oriented programming and identifies the ways this assumption became established. People like Bjarne Stroustrup (developer of C++) took on and promulgated the view that the inheritance hierarchy of classes in an object oriented system can be or should be a literal instantiation of the types of objects from the domain model (e.g. different types of shapes in a drawing program).
This is a mistake is because it puts the broad-scale modularization boundaries of a system in the wrong places and makes the system brittle and inflexible. A better approach is one where large scale system boundaries fall along computational capability lines, as exemplified by modern Entity Component Systems. Class hierarchies that rigidly encode domain categorizations don't make for flexible systems.
Some of the earliest writers on object encapsulation, e.g. Tony Hoare, Doug Ross, understood this, but later language creators and promoters missed some of the subtleties of their writings and left us with a poor version of object-oriented programming as the accepted default.