Live data from Hacker News

The Big OOPs: Anatomy of a Thirty-Five Year Mistake

computerenhance.com

21–30 of 193 posts

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#21
post #19
post #2

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…

He literally gives extensive primary source citations to show that the originators of OOP presented this class-domain correspondence as the correct way to think about and do OOP. Bjarne Stroustrup is not just some random guy.

Is it fair to blame all of OOP for C++?

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#22
post #13
post #11

Earlier quoted context omitted.

About every video on YouTube has a transcript, usually a button at the bottom of the description.

No help. It's video speed. I can read at several thousand words a minute. So I need the whole transcript in one shot. Then I can read it in 10 or 15 minutes or so, and decide if it's worth watching a 2 hour plus video. The answer is almost always "no".

[deleted]

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#24
post #10

Earlier quoted context omitted.

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

Is Objective-C discussed at all?

Only as a brief aside (don't have the timestamp right now) to talking about Smalltalk, which he mostly discusses to argue that Smalltalk was not different from C++ in seeking (most of the time) to model programs in terms of static hierarchies (according to the primary source documentation from the time of Smalltalk's design):

> And another thing is if you look at the other branch,

> the branch that I'm not really covering very much

> in this talk, because again,

> we don't program in small talk these days, right?

> The closest thing you would get

> is maybe something like Objective-C.

> If there's some people out there using Objective-C,

> you know, like Apple was using that for a little while,

> so Objective-C kind of came

> from a small talk background as well.

Objective-C is basically Smalltalk retrofitted onto C, even more than C++ was Simula retrofitted onto C (before C++ gained template metaprogramming and more modern paradigms), so it makes sense that Muratori doesn't go much into it, given that he doesn't discuss Smalltalk much.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#25
post #10

Earlier quoted context omitted.

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

Is Objective-C discussed at all?

[deleted]

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#26
post #13
post #11

Earlier quoted context omitted.

About every video on YouTube has a transcript, usually a button at the bottom of the description.

No help. It's video speed. I can read at several thousand words a minute. So I need the whole transcript in one shot. Then I can read it in 10 or 15 minutes or so, and decide if it's worth watching a 2 hour plus video. The answer is almost always "no".

https://www.youtube-transcript.io/videos?id=wo84LFzx5nI

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#27

Earlier quoted context omitted.

Is Objective-C discussed at all?

Only as a brief aside (don't have the timestamp right now) to talking about Smalltalk, which he mostly discusses to argue that Smalltalk was not different from C++ in seeking (most of the time) to model programs in terms of static hierarchies (according to the primary source documentation from the time of Smalltalk's design): > And another thing is if you look at the other branch, > the branch that I'm not really cov…

>> you know, like Apple was using that for a little while,

If we discount NeXT's time using it, Apple's only been using Objective-C for 28 years, just a little while. It also (barely) preceded C++.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#28
And 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

#29
post #11
post #6

Is there a script or transcript anywhere, for those of us who can read 10x faster than it is possible to understand speech?

About every video on YouTube has a transcript, usually a button at the bottom of the description.

I imagine the whisper transcript has less errors.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#30
post #5

Any way to find out what the 35 year mistake was without being "engaged" for hours on that video?

In short, in my opinion:

- Encapsulation / interfaces is a good idea, a continuation of the earlier ideas of structured programming.

- Mutable state strewn uncontrollably everywhere is bad idea, even in a single-threaded case.

- Inheritance-based polymorphism is painful, both in the multiple (C++) and single (Java) inheritance cases. Composable interfaces / traits / typeclasses without overriding methods are logically and much more useful.

Post reply on HN