71–80 of 97 posts
Earlier quoted context omitted.
I think you mean the machine-generated one on Youtube? It took me a few minutes of searching from your slightly scant description. Is there any way to extract just that text into a document I can read?
None that I can find. Maybe we need to beg the presenter.
Video talks are like LLM bot content, for me:
If it wasn't worth writing down, it's not worth my time to watch it.
Earlier quoted context omitted.
None that I can find. Maybe we need to beg the presenter.
I asked him on Twitter. The answer was a simple "sorry, no." Video talks are like LLM bot content, for me: If it wasn't worth writing down, it's not worth my time to watch it.
Earlier quoted context omitted.
It's not the same claim. Muratori's statement (that he debunks in his talk): OO was created for teams. Graham's statement: OO is useful for teams. Those are distinct concepts, there's lots of evidence of statements like Graham's out there, and you've helpfully provided one. What igouy is asking for is evidence of the former claim.
A primary source: https://www.youtube.com/watch?v=_ahvzDzKdB0
A lot of people have said a lot of things about OOP for decades. So looking at the context in which something was said is an ordinary sanity check.
Earlier quoted context omitted.
> "OOP is made for large teams" "you're not using it as intended" "its not made to model your domain hierarchy" Are there actual references for those quotes? Were they said by some kind-of expert or by a sales person or by cousin John? Are they strawmen set-up to knock-down.
Oh if only you watched the presentation, where he quotes Bjarne Stroustrup and Alan Kay xD
I thought it was very interesting about how Alan Kay and Bjarne Stroustrup may have been applying wisdom from their old fields of expertise and how that affected their philosophy. There is an appeal to building complexity through Emergence, where you design several small self-contained pieces that have rich interactions with each other and through those rich interactions you can accomplish more complex things. Its ho…
So if you look at it through that lens, the need for a little omniscience seems natural. The mistake was in thinking that the program was identified with the objects that the laws govern, when really you have to cover those AND the laws themselves.
I found this talk to be great. It goes through the history of OOP and how some of the ideas for the more modern ECS were embedded in the culture at the formation of OOP in the 1960s to 1980s but somehow weren't adopted. It was pretty clear, even 20 years ago, that OOP had major problems in terms of what Casey Muratori now calls "hierarchical encapsulation" of problems. One thing that really jumped out at me was his q…
> It goes through the history of OOP Unfortunately, the "history" omits prototype-based OO (Self, Io, Lua, etc.) which doesn't suffer from many of the "issues" cited by the speaker.
Having said that: why would he though? In this particular talk he's trying to argue to people who program in C++ why the historical C++ architectures are limiting it, he's not trying to convince anyone to switch languages. So those languages aren't his audience.
I found this talk to be great. It goes through the history of OOP and how some of the ideas for the more modern ECS were embedded in the culture at the formation of OOP in the 1960s to 1980s but somehow weren't adopted. It was pretty clear, even 20 years ago, that OOP had major problems in terms of what Casey Muratori now calls "hierarchical encapsulation" of problems. One thing that really jumped out at me was his q…
The context, for the record, is inventing good general software architectures (and by extension generalized programming paradigms) for everyone to use. I agree with you that this is bad advice for generally fixing things, but for this context it absolutely makes sense to me. The hard problems are more likely to cover all the walls you'd bump into if you start from the oversimplified ones, so they are much better use-cases to battle-test ideas of what good architectures or programming paradigms are.
Earlier quoted context omitted.
The dates are the dates of the sources, he says in the talk he wasn't going to try to infer the dates these ideas were invented. Also he barely talked about Alan Kay.
From the video: "It's like, yeah, he said that in 2003, right? He said that after a very long time. So why did he say it? It's because 10 years earlier, he was already saying he kind of soured on it." https://youtu.be/wo84LFzx5nI?t=823 He mentions Alan Kay about dozen times and uses quotes and dates to create a specific narrative about Smalltalk. That narrative is demonstrably false.
As far as the narrative, probably the clearest expression of Casey's thesis is at https://youtu.be/wo84LFzx5nI?t=6187 "Alan Kay had a degree in molecular biology. ... [he was] thinking of little tiny cells that communicate back and forth but which do not reach across into each other's domain to do different things. And so [he was certain that] that was the future of how we will engineer things. They're going to be like microorganisms where they're little things that we instance, and they'll just talk to each other. So everything will be built that way from the ground up." AFAICT the gist of this is true, Kay was indeed inspired by biological cells and that is why he emphasized message-passing so heavily. His undergraduate degree was in math + bio, not just bio, but close enough.
As far as specific discussion, Casey says, regarding a quote on inheritance: https://youtu.be/wo84LFzx5nI?t=843 "that's a little bit weird. I don't know. Maybe Alan Kay... will come to tell us what he actually was trying to say there exactly." So yeah, Casey has already admitted he has no understanding of Alan Kay's writings. I don't know what else you want.
Earlier quoted context omitted.
It's a remarkable stretch to go from those words to "OO was created for working with teams." It is neither implicit nor explicit in the talk and I don't know why anyone would make the claim you are making. EDIT: You seem to be conflating the two ideas still. OO being created for teams is a different claim than it being good for teams. At most, you could stretch Steele's talk to the second, but not to the first.
True, he doesn't come right out and say the words. But don’t lose sight of the context. This is the big Keynote speech at a conference called OOPSLA, or “Object-Oriented Programming, Systems, Languages & Applications”, in 1998. It is safe to say that the audience has heard of Java by now. They already know that the core language design choice made during the creation of Java was to make it object—oriented. Objets are…
24:50 -- "A lot of people talk about these things. They talk about those compile time hierarchies and all that sort-of stuff; and they say - like you know, here's the thing that you just don't understand, it's all about large teams …"
Is there some example that you can point me towards, where a lot of people are saying compile time hierarchies are all about large teams?
(I suppose Ada is an example of design for programming-in-the-large.)
Earlier quoted context omitted.
I asked him on Twitter. The answer was a simple "sorry, no." Video talks are like LLM bot content, for me: If it wasn't worth writing down, it's not worth my time to watch it.
Maybe it's all about ad-revenue.
And that for me makes me not want to watch.
If someone has a message they want to communicate, then it's worth writing down.
If they don't, and primarily just want the views, then it's not worth my time.