"Smalltalk is a purely object-oriented programming language that was originally created in the 1970s for educational use, specifically for constructionist learning, but later found use in business."
"Smalltalk is a purely object-oriented programming language that was originally created in the 1970s for educational use, specifically for constructionist learning, but later found use in business."
Alan Kay at OOPSLA 1997 - The computer revolution hasn’t happened yet https://www.youtube.com/watch?v=oKg1hTOQXoY&t=3530s
“To me the most distressing thing that happened to Smalltalk when it came out of Xerox PARC was for many respects and purposes it quit changing. Now I can tell you at Xerox PARC there were four major versions, completely different versions, of the language over about a ten year period. And many dozens and dozens of significant releases within those different versions. And I think one of the things we liked most about Smalltalk was not what it could do but the fact that it was such a good vehicle for bootstrapping the next set of ideas we had about how to do systems building. And that for all intents and purposes when Smalltalk went commercial ceased. Even though there was a book, the famous blue book, that Adele and Dave wrote that had the actual code in it for making Smalltalk interpreters and starting this process oneself, almost nobody took advantage of this. Almost no university took advantage of it, almost no commercial institution took advantage of it. And what they missed was, to me, the deepest thing I would like to communicate to you today, and that is we don’t know how to design systems yet. So let’s not make what we don’t know into a religion for God’s sake. What we need to do is to constantly think and think and think about what’s important. And we have to have our systems let us get to the next levels of abstraction as we come to them. And the thing that I’m most proud of about Smalltalk, pretty much the only thing from my standpoint that I’m proud of, is that it has been so good at getting rid of previous versions of itself until it came out into this world. Now one of the reasons we got involved in doing Smalltalk talk again, for me it was after 16 years of not working on programming languages, a couple of years ago we started this project we called Squeak, which is simply, not an attempt to give the world a free Smalltalk, but an attempt to give the world a bootstrapping mechanism for something much better than Smalltalk. And when you fool around with Squeak please please think of it from that stand...think of how you can obsolete the damn thing by using its own mechanisms for getting the next version of itself.”
This confusion frustrated me when I first read about Smalltalk in the August 1981 issue of Byte magazine. I couldn't figure it out and at that point I had learned several programming languages and none of them took me more than two hours to become reasonably fluent in. So I was having problems with a language that kids were using?!? Later on I found out about the differences between Smalltalk-72 and -80 and that the Byte articles explained things that made sense if you already knew them but didn't help you learn in the first place. All variations of Smalltalk have become my favorite way to program ever since.
Nowadays object oriented programming is almost entirely associated with inheritance hierarchies.
Perhaps inheritance isn't as central to object oriented programming as initially envisioned.
The original VB and Self are two other well known examples where there is no inheritance support.
Also most Lisp systems inspired in The Art of Metaobject Protocol tend to focus on multi-methods, instead of inheritance, to change current behaviours attached to structs.
Original VB was definitely OOP, especially since VB 4, when VBX was replaced by COM.
That dogmatic Java-flavor-OOP and their ideas of translating design patterns 1-to-1 to other languages like Python, disregarding the language specifics and language design choices ... ugh, such a PITA.
That's where my guards are going up, and I start observing very closely, what that person's understanding of OOP is, and whether they merely throw out buzzwords, or actually know something about what they are talking about.