Hacker News Reader

Comment by ndiddy | Hacker News Reader

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

View on HN

> "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.

> 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?

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-perfor...

> 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.)

> 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.

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

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".

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

Reply on news.ycombinator.com