109 ms·

There's a really good talk about the history of OOP going back to the early 60s that goes over this point. The whole "90s style OOP isn't OOP as it was original

by ndiddy 1y ago

There's a really good talk about the history of OOP going back to the early 60s that goes over this point. The whole "90s style OOP isn't OOP as it was originally intended" thing is largely a myth. When Kay and other OOP pioneers were describing Smalltalk and OOP to professional developers, they all used 90s Java style "compile-time hierarchy of encapsulation that matches the domain model" OOP to explain it. Smalltalk-80: The Language, a book by some of the original designers of Smalltalk, even uses the same shape class inheritance example you'll see in every introductory Java textbook. Here's a link to the talk, timestamped to when he goes over this. https://youtu.be/wo84LFzx5nI?t=785 https://youtu.be/wo84LFzx5nI?t=785

igouy 1y ago
> used 90s Java style "compile-time hierarchy of encapsulation that matches the domain model" OOP to explain it. Beware anachronism. They used the actual 80s Smalltalk implementation to explain the actual Smalltalk-80 implementation.
zozbot234 1y ago
> "compile-time hierarchy of encapsulation that matches the domain model" The talk doesn't mention it of course, but this still exists, even in "modern" languages that purport to be free of OOP! What do you think Typestate is - particularly in its genericized variety - other than a kind of "compile-time hierarchy of encapsulation that matches the domain model"? Change my mind: Typestate - and Generic Typestate only more so - is just good old OOP wearing a trenchcoat.
nailer 1y ago
Thanks! That’s an excellent talk. I agree with the premise at 11:10.
- igouy 1y ago
  11:05 -- I'm not saying that OOP was a mistake, I'm saying that this was a mistake: "compile-time hierarchy of encapsulation that matches the domain model was a mistake".
- igouy 1y ago
  11:10 -- The second thing that I want to get clear, is I don't want to hear any complaints that no one ever pushed this model. … It is so obvious that everyone actually 100% meant you should look at the domain model and you should code that directly into the compiled hierarchy." . Not everyone actually — "The simplistic approach is to say that object-oriented development is a process requiring no transformations, beginning with the construction of an object model and progressing seamlessly into object-oriented code. … While superficially appealing, this approach is seriously flawed. It should be clear to anyone that models of the world are completely different from models of software. The world does not consist of objects sending each other messages, and we would have to be seriously mesmerised by object jargon to believe that it does. …" "Designing Object Systems", Steve Cook & John Daniels, 1994, page 6 https://archive.org/details/designingobjects0000cook https://archive.org/details/designingobjects0000cook
igouy 1y ago
> the same shape class inheritance example you'll see in every introductory Java textbook Here's what's shown: DisplayObject DisplayMedium Form Cursor DisplayScreen InfiniteForm OpaqueForm Path Arc Circle Curve Line LinearFit Spline Do you have an example of that being shown in an introductory Java textbook?
- ndiddy 1y ago
  Sure, why not. Obviously if you mean "do you have an example of that exact class hierarchy being shown in an introductory Java textbook" no I don't, you win. However, the example of a program that uses a class inheritance hierarchy defined at compile time to represent all the different types of shapes it can operate with is used all over the place, and that's what I was referring to. Some examples: Introduction to Programming in Java by J. N. Patterson Hume and Christine Stephenson, page 392 Object-oriented Programming with Java by Barry J. Holmes and ‎Daniel T. Joyce, page 544 Understanding object-oriented programming with Java by Timothy Budd, page 304 Teach yourself Java by Joseph O'Neil, page 184 Java in a Nutshell by Benjamin J. Evans, page 128 Java for Students by Douglas Bell and Mike Parr, page 490 Data structures and problem solving using Java by Mark Allen Weis, page 84 See here for a good article that goes over the downsides of this approach, and how it hurts both readability and performance: https://www.computerenhance.com/p/clean-code-horrible-performance https://www.computerenhance.com/p/clean-code-horrible-perfor...
  - igouy 1y ago
    > no I don't, you win Because what they are actually like is java.awt — they are the classes used to implement graphics in Smalltalk-80, not some made-up example. (The "Java in a Nutshell 8th ed, I found has no page numbers. There's a "Subclasses and Inheritance" section which shows how to code PlaneCircle as a subclass of Circle class. afaict That's a couple of made-up classes that exist solely to show things that can be done with Java classes. Not an example of "compile-time hierarchy of encapsulation that matches the domain model". Later the authors use class A and class B for their examples.)

by ndiddy 1y ago

igouy 1y ago

> used 90s Java style "compile-time hierarchy of encapsulation that matches the domain model" OOP to explain it. Beware anachronism. They used the actual 80s Smalltalk implementation to explain the actual Smalltalk-80 implementation.

zozbot234 1y ago

> "compile-time hierarchy of encapsulation that matches the domain model" The talk doesn't mention it of course, but this still exists, even in "modern" languages that purport to be free of OOP! What do you think Typestate is - particularly in its genericized variety - other than a kind of "compile-time hierarchy of encapsulation that matches the domain model"? Change my mind: Typestate - and Generic Typestate only more so - is just good old OOP wearing a trenchcoat.

nailer 1y ago

Thanks! That’s an excellent talk. I agree with the premise at 11:10.

igouy 1y ago
11:05 -- I'm not saying that OOP was a mistake, I'm saying that this was a mistake: "compile-time hierarchy of encapsulation that matches the domain model was a mistake".
igouy 1y ago
11:10 -- The second thing that I want to get clear, is I don't want to hear any complaints that no one ever pushed this model. … It is so obvious that everyone actually 100% meant you should look at the domain model and you should code that directly into the compiled hierarchy." . Not everyone actually — "The simplistic approach is to say that object-oriented development is a process requiring no transformations, beginning with the construction of an object model and progressing seamlessly into object-oriented code. … While superficially appealing, this approach is seriously flawed. It should be clear to anyone that models of the world are completely different from models of software. The world does not consist of objects sending each other messages, and we would have to be seriously mesmerised by object jargon to believe that it does. …" "Designing Object Systems", Steve Cook & John Daniels, 1994, page 6 https://archive.org/details/designingobjects0000cook https://archive.org/details/designingobjects0000cook

igouy 1y ago

> the same shape class inheritance example you'll see in every introductory Java textbook Here's what's shown: DisplayObject DisplayMedium Form Cursor DisplayScreen InfiniteForm OpaqueForm Path Arc Circle Curve Line LinearFit Spline Do you have an example of that being shown in an introductory Java textbook?

ndiddy 1y ago
Sure, why not. Obviously if you mean "do you have an example of that exact class hierarchy being shown in an introductory Java textbook" no I don't, you win. However, the example of a program that uses a class inheritance hierarchy defined at compile time to represent all the different types of shapes it can operate with is used all over the place, and that's what I was referring to. Some examples: Introduction to Programming in Java by J. N. Patterson Hume and Christine Stephenson, page 392 Object-oriented Programming with Java by Barry J. Holmes and ‎Daniel T. Joyce, page 544 Understanding object-oriented programming with Java by Timothy Budd, page 304 Teach yourself Java by Joseph O'Neil, page 184 Java in a Nutshell by Benjamin J. Evans, page 128 Java for Students by Douglas Bell and Mike Parr, page 490 Data structures and problem solving using Java by Mark Allen Weis, page 84 See here for a good article that goes over the downsides of this approach, and how it hurts both readability and performance: https://www.computerenhance.com/p/clean-code-horrible-performance https://www.computerenhance.com/p/clean-code-horrible-perfor...
- igouy 1y ago
  > no I don't, you win Because what they are actually like is java.awt — they are the classes used to implement graphics in Smalltalk-80, not some made-up example. (The "Java in a Nutshell 8th ed, I found has no page numbers. There's a "Subclasses and Inheritance" section which shows how to code PlaneCircle as a subclass of Circle class. afaict That's a couple of made-up classes that exist solely to show things that can be done with Java classes. Not an example of "compile-time hierarchy of encapsulation that matches the domain model". Later the authors use class A and class B for their examples.)