Really appreciate this explanation of the essence of smalltalk. I like how message passing implies Abstraction, Encapsulation, Polymorphism and Inheritance. This kind of big picture view of a programming language is under utilized. It is so helpful. Thanks.
In C you can at least create function pointers which can be called by the same name but doing different things depending on which function the function pointer points to at the moment. Kind of gets you halfway there to have a function of the same name (a function pointer) that indirectly can allow you to accomplish different things (just as with Polymorphism). Although the different functions that the function pointer "Binds" to (if that is the right name) have to have different names, of course...
I want to plant an idea in your head. Hopefully its like a seed and it grows. "Multi-tier abstraction." The idea originally steamed from TurboPascal 6.0 it had BASM built in (In case you wanted lower level control). Well that feature made TurboPascal a two-tier programming language. Lets say Pascal was the top tier and BASM was the bottom tier. Soo the idea is that a language should have like 5 or more tiers and lets call this feature multi-tier abstraction. A good analogy: The landscape (tier 0) -> the forest (tier -1) -> the trees (tier -2) -> the soil, the leaves, the bark, the grass (tier -3) -> microscopic life (tier -4) For a while I have entertained the idea of making a completely new or advanced computer language. I want to call it "Savage Gardens" cause it would follow the above analogy. Tier 0: Smart documentation (solely for human consumption). At this tier we have smart diagrams and documentation that you can click thru and navigate real code. Tier -1: GUI based programming language. A very high level abstraction. If a picture can represent a thousand words then let a GUI construct represent a thousand lines of code. Tier -2: Flowchart based programming language. Same principle as the tier above. By manipulating this flowchart you would be manipulating hundreds of lines code here and there. Tier -3: Object Oriented language. Similar to JAVA. Tier- 4: Procedural based language that ties well with the wire. Good one is C. The C language ties well with the hardware yet its it retains a high level of abstraction. Tier -5: Assembler language, you can compile C to assembly or bytecode, etc. Note: I am using negative numbers because -5 represents a lower level then -4 Note: that the tiers should be defined in terms of their lower level tiers. For example tier -3 the object oriented language should be defined by tier -4 and so on. The value of such language is that understanding what you write is just as important as what its able to do. Language has two values to humanity. One is commonly known the other one most people are clueless about. The common value of language is the ability to communicate with fellow human beings. The value that most people are unaware about is that language allows you to think. Its what allows people to articulate or organize thoughts in their head. Hence having a firm and deep understanding of the code your write is just as important as what the code is able to do.
Just want to add that, Iets call this multi-tier approach the "Savage Gardens" approach. Cause it want that term to be associated with this idea. Ya know, taming the savage gardens.
I started with Turbo Pascal 3 and I think I still have a copy of TP 6 lying around somewhere (as well as a few others).I may have to go back and take a look!
"message passing" in this context is the same as java/c# "exposing functionality via an interface and only allowing interaction thru said interface" The issue with the "message passing" is that it's confused with "method calling" and "asynchronous operations (send and forget)" This whole area of terminology overloading leads to a TON OF CONFUSION AND PAIN
I agree that jargon often obfuscates more than clarifies. That said, the idea of message-passing makes good sense for Smalltalk (though less so for many of the OOP languages that followed it).
@@LearnWithHuw yes but are the messages put into a queue for processing later or are they direct calls to functions? This is an area that causes a lot of confusion bc both are kinda true, but one is what is actually happening at the iron level and one is conceptual. It's important for students to have concrete metaphors that directly adhere to the function, otherwise understanding is muddled. I agree that AK message passing is the main idea, but it's lost on java devs who are used to simply calling methods The nuance is lost on them and looks like most purveyors of OOP knowledge
Message queuing is not the same thing as Smalltalk message passing. Unfortunately, terms are re-used and re-defined throughout programming, which can lead to confusion. But the idea of a well-defined "interface" is indeed implicit in the idea of message-passing. The methods are, in a sense, an object's interfaces. You might want to read Alan Kay's description here: lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html
Programming is an Schizophrenia area. We use the same word to refer to different things. And different words to refer to the same thing. Learning anything requires a student to check if the new terminology matches with anything they already know. 😢
@@ellerium the problem comes when the teacher doesn’t know this and is just parroting what they have heard or taught without true understanding It’s so bad right now
Interesting . Like Physics it useful to go back to first principles to understand the fundamentals. But like Physics things evolve. The Classical Mechanics taught today in college is not quite the same way Newton and Leibniz formulated. I guess the same can be said about Alan Kay's original ideas, and how these ideas have progressed and morphed in later languages. But I like seeing the original sources as so much stuff one finds on the internet is just plain wrong, written by people with a poor understanding.
Object Orientation means many things in different languages now. But, you are right. It can be illuminating to see where those ideas came from. Best wishes Huw
I really like these videos, and will continue to watch, but I feel like this arguments is fairly semantic. I had never heard of Small Talk, and it seems really interesting, especially as someone who learned how to program sending messages between classes in C#, however I find it hard to understand your over-arching idea of objects being a black box the more you elaborate about it. It made sense to me at first but in this video you compare working with integers with changing channels on a TV; "You don't know how the TV does what it does, you just click a button and the channel changes." In this example, you don't need to know what the TV is doing, but you do need to know what the buttons on the remote mean. The remote acts like an API in a way between you and the TV. Working with an integer, though, I don't see the comparison. How do you work with an integer without understanding you cant provide it with text?
Thanks. The idea idea of black box encapsulation is related to strict modularity. Essentially it means that the "world" (code and data) inside an object is hidden from the world outside an object which can only communicate via messages/methods. I discuss this in more detail in the video on modularity. But the idea also crops up in other lessons in this series: ua-cam.com/play/PLZHx5heVfgEvuveKG1T7BBSuDOTHl1eLl.html
In C#, if I remember correctly, the number operations are implemented as operators. Only the language maintainer has access to it. In languages like Smalltalk those are plain methods of a the Number class. Allowing you to create a Currency class, descendant from Decimal, that re-implements all the existing methods to make sure it’s properly rounded.
*SmallTalk failed to instantiate Alan Kay's vision.* Calling a method is calling a function. It is not a message. So bollocks. A message: Tell me your size. A function (method call) : array size or array (size) or array.size Class-based "object-oriented" languages are hierarchical taxonomy languages. Those really are not object-oriented. Rather those are classification oriented. Such languages are quite rigid and rapidly lead to brittle code. Complexity is exponential.
I'm getting really tired of object-oriented programming being crucified because C++ did it so poorly and a bunch of languages copied their idea. Another interesting point is that if you have closures in a language you can often build your own object system out of those where you close over some anonymous functions which act like methods and the closure receives a message and parameters which call the appropriate internal method. And you can even have inheritance and multiple inheritance if you can create new function objects from those which inherit the closures and resolve edge cases.
I've seen some really horrible code written in various non-Smalltalk languages. Horrible not because the language itself requires it to be horrible but because the people who wrote the code didn't seem to have a clear idea of what objects are really for.
One of the best resources for disambiguating mainstream OOP with Alan Kay's version. Thanks Huw 👍
Thank you!
Really appreciate this explanation of the essence of smalltalk.
I like how message passing implies Abstraction, Encapsulation, Polymorphism and Inheritance.
This kind of big picture view of a programming language is under utilized.
It is so helpful. Thanks.
Thank you. Yes, I think the jargon sometimes makes a simple idea seem complicated. I'm glad you found my explanation helpful.
So helpul! My gosh, i was bored with same contents all over the place...this 'boom' of programming and I.T... at last I have fallen here. Pure gold.
Wow, I'm flattered. Many thanks!
In C you can at least create function pointers which can be called by the same name but doing different things depending on which function the function pointer points to at the moment.
Kind of gets you halfway there to have a function of the same name (a function pointer) that indirectly can allow you to accomplish different things (just as with Polymorphism).
Although the different functions that the function pointer "Binds" to (if that is the right name) have to have different names, of course...
Oh, you can do just about everything in C that you can in Smalltalk. BUT it would be VERY hard work to do so! 🙂
This really is a wonderfully clear explanation, thanks Huw!
Many thanks.
This is an awesome video, that’s for sharing your knowledge😊
Glad you found it interesting! 🙂
I want to plant an idea in your head. Hopefully its like a seed and it grows.
"Multi-tier abstraction."
The idea originally steamed from TurboPascal 6.0 it had BASM built in (In case you wanted lower level control). Well that feature made TurboPascal a two-tier programming language. Lets say Pascal was the top tier and BASM was the bottom tier. Soo the idea is that a language should have like 5 or more tiers and lets call this feature multi-tier abstraction.
A good analogy: The landscape (tier 0) -> the forest (tier -1) -> the trees (tier -2) -> the soil, the leaves, the bark, the grass (tier -3) -> microscopic life (tier -4)
For a while I have entertained the idea of making a completely new or advanced computer language. I want to call it "Savage Gardens" cause it would follow the above analogy.
Tier 0: Smart documentation (solely for human consumption). At this tier we have smart diagrams and documentation that you can click thru and navigate real code.
Tier -1: GUI based programming language. A very high level abstraction. If a picture can represent a thousand words then let a GUI construct represent a thousand lines of code.
Tier -2: Flowchart based programming language. Same principle as the tier above. By manipulating this flowchart you would be manipulating hundreds of lines code here and there.
Tier -3: Object Oriented language. Similar to JAVA.
Tier- 4: Procedural based language that ties well with the wire. Good one is C. The C language ties well with the hardware yet its it retains a high level of abstraction.
Tier -5: Assembler language, you can compile C to assembly or bytecode, etc.
Note: I am using negative numbers because -5 represents a lower level then -4
Note: that the tiers should be defined in terms of their lower level tiers. For example tier -3 the object oriented language should be defined by tier -4 and so on.
The value of such language is that understanding what you write is just as important as what its able to do. Language has two values to humanity. One is commonly known the other one most people are clueless about. The common value of language is the ability to communicate with fellow human beings. The value that most people are unaware about is that language allows you to think. Its what allows people to articulate or organize thoughts in their head. Hence having a firm and deep understanding of the code your write is just as important as what the code is able to do.
Just want to add that, Iets call this multi-tier approach the "Savage Gardens" approach. Cause it want that term to be associated with this idea. Ya know, taming the savage gardens.
I started with Turbo Pascal 3 and I think I still have a copy of TP 6 lying around somewhere (as well as a few others).I may have to go back and take a look!
However, all the essential software was developed using C, including Unix, Linux, iOS, Windows, Chrome, Networking and more...
Awesome series!
Thanks.
Great series!
Many thanks!
OOP looks like Platonism applyed to computer science.
"message passing" in this context is the same as java/c# "exposing functionality via an interface and only allowing interaction thru said interface"
The issue with the "message passing" is that it's confused with "method calling" and "asynchronous operations (send and forget)"
This whole area of terminology overloading leads to a TON OF CONFUSION AND PAIN
I agree that jargon often obfuscates more than clarifies. That said, the idea of message-passing makes good sense for Smalltalk (though less so for many of the OOP languages that followed it).
@@LearnWithHuw yes but are the messages put into a queue for processing later or are they direct calls to functions? This is an area that causes a lot of confusion bc both are kinda true, but one is what is actually happening at the iron level and one is conceptual. It's important for students to have concrete metaphors that directly adhere to the function, otherwise understanding is muddled.
I agree that AK message passing is the main idea, but it's lost on java devs who are used to simply calling methods
The nuance is lost on them and looks like most purveyors of OOP knowledge
Message queuing is not the same thing as Smalltalk message passing. Unfortunately, terms are re-used and re-defined throughout programming, which can lead to confusion. But the idea of a well-defined "interface" is indeed implicit in the idea of message-passing. The methods are, in a sense, an object's interfaces. You might want to read Alan Kay's description here: lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html
Programming is an Schizophrenia area. We use the same word to refer to different things. And different words to refer to the same thing.
Learning anything requires a student to check if the new terminology matches with anything they already know. 😢
@@ellerium the problem comes when the teacher doesn’t know this and is just parroting what they have heard or taught without true understanding
It’s so bad right now
Interesting . Like Physics it useful to go back to first principles to understand the fundamentals. But like Physics things evolve. The Classical Mechanics taught today in college is not quite the same way Newton and Leibniz formulated. I guess the same can be said about Alan Kay's original ideas, and how these ideas have progressed and morphed in later languages. But I like seeing the original sources as so much stuff one finds on the internet is just plain wrong, written by people with a poor understanding.
Object Orientation means many things in different languages now. But, you are right. It can be illuminating to see where those ideas came from.
Best wishes
Huw
Smashing!
I really like these videos, and will continue to watch, but I feel like this arguments is fairly semantic. I had never heard of Small Talk, and it seems really interesting, especially as someone who learned how to program sending messages between classes in C#, however I find it hard to understand your over-arching idea of objects being a black box the more you elaborate about it. It made sense to me at first but in this video you compare working with integers with changing channels on a TV; "You don't know how the TV does what it does, you just click a button and the channel changes." In this example, you don't need to know what the TV is doing, but you do need to know what the buttons on the remote mean. The remote acts like an API in a way between you and the TV. Working with an integer, though, I don't see the comparison. How do you work with an integer without understanding you cant provide it with text?
Thanks. The idea idea of black box encapsulation is related to strict modularity. Essentially it means that the "world" (code and data) inside an object is hidden from the world outside an object which can only communicate via messages/methods. I discuss this in more detail in the video on modularity. But the idea also crops up in other lessons in this series: ua-cam.com/play/PLZHx5heVfgEvuveKG1T7BBSuDOTHl1eLl.html
In C#, if I remember correctly, the number operations are implemented as operators. Only the language maintainer has access to it.
In languages like Smalltalk those are plain methods of a the Number class. Allowing you to create a Currency class, descendant from Decimal, that re-implements all the existing methods to make sure it’s properly rounded.
*SmallTalk failed to instantiate Alan Kay's vision.* Calling a method is calling a function. It is not a message. So bollocks.
A message: Tell me your size.
A function (method call) :
array size
or
array (size)
or
array.size
Class-based "object-oriented" languages are hierarchical taxonomy languages. Those really are not object-oriented. Rather those are classification oriented.
Such languages are quite rigid and rapidly lead to brittle code. Complexity is exponential.
I'm getting really tired of object-oriented programming being crucified because C++ did it so poorly and a bunch of languages copied their idea. Another interesting point is that if you have closures in a language you can often build your own object system out of those where you close over some anonymous functions which act like methods and the closure receives a message and parameters which call the appropriate internal method. And you can even have inheritance and multiple inheritance if you can create new function objects from those which inherit the closures and resolve edge cases.
I've seen some really horrible code written in various non-Smalltalk languages. Horrible not because the language itself requires it to be horrible but because the people who wrote the code didn't seem to have a clear idea of what objects are really for.