21 Likes
11 Likes
it works for me
2 Likes
Yeah, there was some weirdness where, upon pasting the link directly, it turned into a different, “Captcha Check” link. Some discourse smartness gone haywire? Might make sense to try to copy-paste the link directly in the browser window, to make sure there’s no smart on-click handlers or what not.
1 Like
Oh, it works now. I will delete the comment to avoid confusion.
I’m getting 403: forbidden, even when pasting the link directly.
In university, when I was learning programming, I liked to go find old programming books in the library; I read Grady Booch’s Object-Oriented Analysis and Design with Applications which, if I recall correctly, very much advocated for the “virtual shape class hiding details overwritten by inheritance” style of programming, with some extra stuff about contracts. I got really into it, but very quickly hit the limitations and rode the up-and-coming functional programming wave instead. This talk validated a lot of my feelings about that kind of OOP, really cool to see someone else dive into the history far far deeper than I did or could have.
I think my favorite part of the talk is the clear refutation of this argument we often encounter, a kind of “No True OOP.” Or, “What you think of as OOP and dislike is not what Alan Kay had in mind.” As Muratori shows through quotes from the people involved, that’s absolute BS.
2 Likes
hm… i expected more of it. it did not catch my interest
My favourite part is how Stroustrup discovers and laments that unity builds are much faster in Simula than incremental builds and then ignores the whole problem and replicates it exactly in C++ 
3 Likes
hm… i expected more of it. it did not catch my interest
I guess you didn’t have to live through the unbelievable OOP hype in the 1990’s? Today’s AI hype is only a mere shadow of that.
IMHO the talk does a good job of dispelling the various OOP myths that have survived until today by doing proper software archeology.
2 Likes
O yes I did. I never liked OOP although I worked a lot with it.
I liked some little parts of the video for example the crazy object hierarchy picture.
1 Like
nope, I was ~6 years old and lived on a farm
4 Likes
You were living the software engineer’s dream!
7 Likes
I am living in the solitude of a high mountain in Slovenia right now 
2 Likes
well, not exactly… it was a dairy farm, owned by someone else. My dad worked 6 days per week as a herdsman, standing knee-deep in manure, trying not to get kicked while inseminating cows all day. Plus he was on-call in the middle of the night for delivery. In the summer it would get up to 50 C for many days in a row. He was usually too tired to play with me on his day off. We were very happy to move to the city.
9 Likes
The strength of the presentation is showing how path dependent our programming ideas are.
The weakness of the presentation is ignoring some of the solid technical reasons why OOP became popular–expensive memory and CPU.
Moving anything to compile time is considered a win when CPU is still expensive. Being able to share behaviors and reuse memory is considered a win when memory is expensive. OOP, as implemented in C++, did both.
The problem was that we kept the C++ version of OOP long after CPU and memory got cheap.
(Side note: People who look backwards at technical stuff very often make the mistake of not considering the technical or economic constraints of the time. As this talk points out, technical people of the past were not less smart than we were.)
5 Likes
This is all well and good but in my opinion there’s a better perspective that detracts a bit from the supposed value behind Casey’s arguments.
It’s ultimately irrelevant whether Alan Kay designed OOP for big teams or for something else. Had Casey actually discovered that this was the case, that OOP was designed entirely for big-scale software created by big teams, should our evaluation of it change then?
I would argue that the answer is no: our evaluation of how useful OOP is as a pattern should be based entirely on our experience when trying to create high quality software.
So in the end, from my perspective, both sides of the historical argument are irrelevant and ultimately misguided.
The real question to ask is whether applying OOP patterns helps you deliver better software, and the answer is going to be no a lot of times (to the dismay of uncle bob) and yes a few times (to the dismay of Casey).
Any other perspective on this problem, including Casey’s talk, is in my opinion not going to be as effective at producing better practical outcomes.
3 Likes
From the linked tweet by @mitchellh :
“OOP and managed memory is good, actually… …for specifically, exclusively GUIs.”
Oooooooooh! You hit one of my hot buttons. 
I would argue that OOP-think is the primary problem preventing us from having a GUI system/toolkit/SDK/whatever that doesn’t force an event loop on us and force us to be single threaded and run stuff on the “main thread”.
Once we finally trash OOP for GUIs, we might finally get a GUI that is genuinely multithreaded.
I have no problem with managed memory, however. Concurrent communication is one of those things that gets a lot easier with managed memory.
You can do that with structs, pointers and functions though, no “OOP shenanigans” needed, C++ mostly just sprinkled a bit of syntax sugar on top of C (and badly).