It's a very simple and elegant idea. Imagine a world of people. Imagine each person has a 'role' like lawyer, plumber (etc.). Methods are not floating free in the code structure. Methods belong to objects, which are instantiations of classes. If it's needed to fix a random leakage in the plumbing system it would not be possible to call a function directly (supposing a function/method called fixPlumbing). It is necessary to send the message for bject Plumber, because the methds fixPlumbing is encapsulated in there. There are no 'free hoovering functions'. Everything is inside an object. In this example, the object lawyer would not have the method for dealing with fixing the plumbing system. So it's not calling directly the function. Its asking for the ject to handle the message.
function calling is as giving orders or force object to do something message passing is as asking to do something message passing is very very late binding... practicaly dynamic binding at runtime. it is also possible with calling but requires special features in run enviroment and/or langugage
What's the value in being able to send any message to any object? Your sample of catching the error of 123 not handling asLowercase suggests to me that Smalltalk is doing function lookups at runtime, which reminds me of how Python handles method calls, and indeed, you COULD write a very similar chunk of code to handle the Python exception if you tried to call 123.asLowercase() in Python, but I'm not sure what this gains us.
In most cases, the only benefit would be either error-handling (many modern OO languages use a similar broad approach to exception-handling) or code generalisation. That is, your code would produce a response rather than just crashing. You really have to try to think back to a time (the 70s/80s) when "any" idea of communicating with an object (rather than just calling a free-standing function) was totally alien to programmers. The key idea is that communication is done *with the object* rather than by a direct function-call. The ability to deal with unexpected messages was one feature of this idea of communicating with objects. You "ask" an object to do something and, if an appropriate method is defined, it does what you expect. If the method is not defined, it can at least inform you of that fact.
I think the value is that of making the code much more robust, after you have made it much more flexible by using dynamic typing. In another scenario you could have a container that holds a bunch of objects and you throw in objects of whatever type without regard (E.g. strings, single chars, fixed-size strings, integers, floats, long floats, short integers, user defined classes, pairs holding any combination of these) and then you traverse this container and you want to make uppercase all strings, and similar types, and leave alone the others. Do you get my point? In general the idea was that of "extreme decoupling" (my wording), decouple everything as much as you can. Ora at least give to the programmer the means to do so.
@@dellusionald1794 I can totally see the value of having some methods be available to many classes - a "ToString" method can be broadly useful, but what seems wrong to me is holding up the ability to send ALL messages to ALL classes as a super important language feature. @LearnWithHuw says that one benefit of allowing all messages to go to all classes is error handling, but that seems to prove the point; for at least some classes, it's an error to pass the message to that class, but it's necessarily a runtime error. This feels much LESS robust; making it harder to deal with code with errors. Early in the series, the claim was that message passing was a super important thing that's been forgotten by modern languages, but this video seems to say that method calls are the new way of accomplishing the same thing - did I misunderstand this?
I'm not sure. I think the dilution of the idea of message passing to just "invoke method" is sad. There are a whole lot of practises which have grown up around programming (DDD, eventmapping, story mapping) which essentially restore this abstraction (message passing) at the design stage. We took a wrong turn with C++, Java, C# et al. I think message oriented OO will have a come back soon.
In many ways I agree. Many of the ideas of Smalltalk have been "adapted" to work with languages in which those ideas seem, well, a bit out of place. While I do make use of OO in C# and Java, there are many projects when I think a fully procedural language such as Pascal (or, better still, Modula-2) would be better. But in the modern world, we have a range of somewhat hybridized languages. As I am discovering in this series, explaining the Smalltalk version of OO to people who are already familiar with OO in later languages provides a peculiar set of problems. 🙂
@@LearnWithHuw bear in mind I largely learned OOP via C# and then had to work out why I found it so unsatisfying. Alan Kay represented a breath of fresh air for me.
You can implement message passing in any language. Will it do you any good? No, not really. It's just another level of insanity that is being propagated by the CS illiterate. Unless you are building distributed systems, message passing is almost always overhead for overhead's sake.
I've enjoyed this series a lot. The content is great. I do hope in future videos there is an effort to put together some non-trivial code though. Superficially, objects and messaging sounds great, but I have rarely if ever seen any application of size and substance that adheres to these principles and doesn't in many places devolve into procedural patterns. Classes end up being like structs in Go or Rust but unnecesarily have to carry around their arbitrary type with them. References are passed into method calls in Java/C# and getters and setters are everywhere, just adding indirection to the private fields.
Thanks. In this series I try to focus on very small code fragments for clarity (based on the Smalltalk/V tutorial). If you browse my playlists however, you will find some very complex projects with much more challenging code! You may enjoy one or two of those.
Well, if you take into consideration Alan Kay's definition of OO then Smalltalk would not be OO, that would be something like the Actor Model, which Smalltalk isn't. In compiled OO languages in which everything is an object, you do not have the `doesNotUnderstand:` or Ruby's `method_missing` because this is more of dynamic OO languages than a feature of OO. But if you forget to define `doesNotUnderstand:` or `method_missing` then you will get an error. However you are thinking this wrong, because you are thinking objects are not function, only methods are functions, however if you consider that a function is an object and the message is the list of arguments and that it will dispatch based on whatever data gets from the arguments including the values of them, then you can have a similar behavior.
I don't see any practical difference between the pattern of "private data + public functions" and the "objects that sends messages to other objects, that requires the receiver to have a method with same name". I don't see any "practical difference" or how this specific abstraction solves any problem that current OO-approaches has issues solving. For example, dependency injection. For me to create an object A that depends on another object B (because some of its methods requires colaboration by B), I have to make sure B exists before A since I need to pass B as dependency to A in its creation, which create a dependency between objects lifetime which is sometimes very hard to manage. Some people calls this problem the "problem of object wiring". How does Smalltak solve this? If an object A needs help, do A needs to know that B is the object that solves my problem, and so A needs to store/contain a reference to B? Because if it does, then it has the same problem that modern-day OO. Another example: when A have the information to do something, but A doesn't know how to do it, because it's not its responsability. Usually you rely on a getter: B knows how to do it, but doesn't have the information: A, give it to me and then I do the thing. That completely breaks encapsulation since A is exposing private information and structure through the getters, but no other solution is good since you don't know how to do the "thing". How does smalltalk solve this problem? Is there any problem that smalltalk solves in a very elegant way that is completely unreachable for traditional OO-languages? How is that abstraction of message passing "superior" to the way OO is understood nowadays?
It's not necessarily superior, it's just different. Smalltalk's designers had a very different future in mind. They were working on this highly interactive machine in which Smalltalk was to be the primary means of communication with it and the operating system all wrapped in one, so they implemented Smalltalk as a collection of live objects, always running in memory with just in time compilation and very late binding/dispatch of method calls because what they anticipated was that if you call a method on an object (send it a message), you never know in advance if the object has an implementation for that method (knows how to respond to the message) but they gave you tools to implement the method on the fly and it's something Hew doesn't show in this video, but the thing is that when that debug window pops up, you can actually go into the definition for your Integer object and implement an asLowercase method on it, 'accept' it and the resume execution and everything will be honky dory. It was a very different paradigm. The difference is that in when the system checks whether or not a specific object has the implementation for a method being called on it. Most modern languages try to check this as early as possible, essentially during compilation, in Smalltalk that's left until when the code is run and the method is called. It was a neat idea for the purposes Smalltalk was designed for but it came at a huge cost: very slow execution because of the runtime method dispatch. It's kind of similar to how in javascript when you try to read the value of a property that doesn't exist you just get undefined, but the execution doesn't stop, it's essentially a tradeoff between compile-time errors(function calling) and runtime errors(message passing).
The difference is probably that you get general polymorphism just naturally "for free" in Smalltalk. But you have to resort to inheritance and virtual functions in something like C++ just to get a limited form of polymorphism, since it is bound to only subclasses. "when A have the information to do something, but A doesn't know how to do it, because it's not its responsability." The Smalltalk examples are a bit extreme as they violate the "single responsibility" principle. But OOP doesn't have to be that way. In your case A is just a pure data abstraction, like an Integer, so the respective level of encapsulation is only the one that is needed to manipulate the data within safe bounds. B is then a system that manipulates A. So just think about A as a primitive data type like an integer and ask the question. Do you really break encapsulation by manipulating an integer the way you want? ;)
The problem is: It's never meaningful to send a message to an object that it cannot understand. This will never produce any meaningful outcome. So why would a programming language (or more precisely a compiler) allow you to do something that is known to not produce a meaningful output? And if you argue "maybe at runtime the message will be understood", then this is still not satisfactory unless the compiler forces you to always handle the case it isn't. And if the compiler has no knowledge what messages are understood, you would have to treat any message ever sent to any object as "will possibly fail" and then your code would be an unreadable mess.
A properly implemented message passing language does not allow you to do that. It will throw a compile time error if you try, just like a statically typed language will throw a compile time error if you call a function with the wrong data types. What these people are talking about here is simply not message passing. If you want to do this properly, then you are basically replacing the struct/typedef syntax with a message definition syntax. Up to that point it's all equivalent. Where it stops being equivalent is at runtime. Direct function calls are perfectly deterministic, i.e. in which order functions are being called in a single threated application is obvious from the program code alone, while this is not the case in message passing implementations.
@@lepidoptera9337 "A properly implemented message passing language" - like? Please provide a sample for such a language. I don't know of any such language. Languages which do type checking and grantee that only allowed calls are made at compile time are not message passing language, they are function calling languages. As these languages require objects to have an interface and you are just calling functions/methods defined by that interface. But that's not how message passing works.
@@xcoder1122 I am not regular user or even a proponent of message passing, so I don't care about languages that may or may not implement this properly. If I need it, I usually implement it in my own library (which I have done once in my entire life... which tells you just how "important" it is as a regular programming technique). We do agree, by the way. Strong type systems have utility and there are many type-safe languages. It is also correct that message passing has absolutely nothing to do with objects. The only people who believe otherwise are praying to St. Kay. It's a religious belief and a personality cult. It's not proper CS. ;-)
#doesNotUnderstand: reifies the message into an object itself, which may then be passed as an arguement, for example with the #perform: message to implement proxies to forward messages to objects instantiated from a database byte-string retrieval.
When I first encountered Simula 67 back in the mid 1970's I immediately grasped the concept but could not grasp the implementation. Later I read the Byte magazine Smalltalk article with great interest, it really didn't click with me. Later I came to understand the terminology as only making sense in a distributed program environment. Much later I encountered the Scandinavian language Beta, it too immediately clicked in my head. Beta (and some other languages) had the concept of pattern and object, the pattern being the factory that instantiates objects (though that can also be done at compile time), and the object may contain code which is executed exactly once, when the object is instantiated. I loved this concept because it unifies the concept of blocks, structures, procedures, classes, objects, and threads. It conceptually obsoleted every other compiled OO language that exists. Or maybe it's just my low IQ that keeps me from taking in the entire train wreck that is C++.
You will notice that I make videos about lots of languages but not C++. 🙂 The Byte article made no sense at all to me when I first read it. I didn't even understand what a mouse and windows were! I think I've caught up now!
If I am not mistaken, you can simulate message passing in mainstream languages as well: public interface IMessage { bool HasResult {get; set;} object Result {get; set;} } public interface ISmallTalkObject { void Handle(IMessage message); } This doesnt tell you what kind of message the implementer of the interface accepts, and it can definitely choose not to implement the message at all, to throw exception etc.
Yes.. but part of Smalltalk's philosophy is to make it seamless. Non statically typed languages like Python and Ruby (or Javascript) are more suited for Smalltalk's concept of Polymorphism. The static type version is cumbersome.
@@kostasgkoutis8534 This isn't message passing. It's just programmer's OCD. You are replacing the function call mechanism that your CPU has already implemented in hardware with a soft implementation. Proper message passing deposits a datagram with a central message handler which then dispatches it to the appropriately registered receiver objects. This is a form of concurrency that makes programs indeterministic (the message handler knows nothing about the call tree structure of the program, whereas direct function calls do). There are so many theoretical CS mistakes here that I can't even count them. Have any of you guys taken an actual computer science class?
@@lepidoptera9337 You talk about message passing as a model for computation in the general sense (you also bring the point of emergent concurrency), I talk about simulating the behavior of a smalltalk object.
@@kostasgkoutis8534 And you are trying to be an apologist for Kay who made a name for himself by redefining terms. Who gives a shit about Smalltalk? When was the last time anybody used it to write serious software? It's an irrelevant piece of CS history. Let it rest in its cold grave, together with Kay's idiotic ideas.
Yes, Ruby certainly took a few ideas from Smalltalk! In some ways, Ruby is a bit like the Little Smalltalk language (from the late 80s/early 90s, I think) which was a version of Smalltalk without an IDE.
If there is say an object or actor or whatever with encapsulated state and two calls get called to it at the same time if they both read and change state then state could be wrong like if both increase a counter then i guess anything that changes state should be put in sortve a message queue and only start the second call after the first one ends
In an earlier video, you suggested that message passing implies three of the four key features of object-oriented programming: encapsulation, polymorphism, add a third one which I am not recalling at the moment. In this video, you have effectively added exception handling to that list implied concepts. And you seem to be implying that it's even broader than that. If I'm following your explanation correctly, it seems that small talk in particular and pure object-oriented programming in general (or perhaps we should call it message passing programming?) Also implies parallel programming at distributed programming. Conceptually, every object is acting in parallel to every other object; and encapsulation doesn't just mean that the internals of the object are hidden; it also means that the location of the object is irrelevant. It could be hosted, in theory, on a different computer halfway around the world, running a different operating system. An Application could be thought of as an object, with its API as the messages that it listens for. Am I understanding you correctly?
Exception-handling wouldn't be considered a fundamental feature of OOP. You are right, though, to think of an object as being its own "little world". You communicate via messages and in principle the object might indeed be at a remote location. I'm not sure that parallel programming was an idea that was current when Smalltalk was developed (though they were so far ahead of the world at Xerox PARC that maybe it was?) but OOP encapsulation certainly provides one type of modularity that can be used for this.
You are making the same CS mistakes as every other believe in St. Kay. OOP and parallelism have nothing to do with each other. Kay was just full of himself and redefined terms in irrational ways.
i still don't understand how is this different than modern oop languages. the only difference i see is that smalltalk doesn't have a smart compiler that will tell you that a given class/object method/property doesn't exist before runtime, so that you don't get the error at runtime as with smalltalk.
As I said, a method-call in a modern OOP language is essentially derived from message-passing in Smalltalk. So if you are used to Java, C# or similar you won't see any huge difference (apart from the ability to send any message to any object in Smalltalk) because C#, Java, C++ etc. have adapted ideas that most programmers had never encountered before Smalltalk. But if you compare Smalltalk (and the OOP languages that followed from it) with a procedural language like C or Pascal, there is a big difference since you have to get "into" the object by message-passing (or "method-calling" if that's how you like to think of it). So the BIG difference is between procedural and OOP methodology. Don't worry too much about the terminology.
To be able to call a method (or send a message) to an object that doesn´t support it, is a property of the dynamique typing of the language, not because the compiler is dumb. Python does it to, it send an exception "AttributeError", that can be catched to do something custom.
@@LearnWithHuw I think you need to think about routers and hos they look up ips because they can pass ips to other routers and while you can achieve that in any oo language I think the perception is the difference, so invoking a method is about ordering the object to do one thing while massage passing you can change the method many times let alone passing to other objects in ruby they do that , in python you can do the same expanding that I think gives you in some sense interfaces like ruby ones more than objects in the common sense
great video! a very clear explanation. could you do one on uml class diagrams to explain how these oop concepts translate to that notation? also, if you did a comparison of smalltalk and python that would be interesting to many people i think, people that want to see the traditional/ fundamental oop concepts as they relate to python.
This distinction doesn't make a lot of sense to me. What it sounds like to me is that you're saying message passing always MUST go hand in hand with dynamic typing. But the compiler CAN statically check if an object will be able to understand a particular message, it's just that Smalltalk's in particular doesn't. But something like the Akka library in the Scala world IS doing exactly that nowadays. (Akka is not an implementation of Smalltalk-like OOB but of an Erlang-like actor system, so this is only an observation of its message passing aspect, but the argument still stands.) And conversely, I CAN try to invoke any method of a JavaScript object with any arguments and the "compiler" will happily accept that - it will only possibly fail at runtime, just as in Smalltalk. But I do suspect another difference: What I've seen in actor systems is that there, message passing has a lot to do with loosening synchronisation restrictions between "caller" and "callee" - because the default in imperative and pseudo-OOB-languages is to wait for an answer to a method call on each invocation while in actor systems the default is to fire-and-forget messages, then continuing with my own business, which might(!) include awaiting message, including, but not(!) limited to replies to my own past messages. But again, that's in the actor world, so I don't know what Smalltalk does in this respect and if that's part of the original mission statement of OOB? I can imagine that control over multiple concurrent threads was quite a bit different back then...
OOP is not dynamic typing. It's actually quite the opposite. The main reason why an architect will chose the OOP paradigm is to have the strongest possible type system. Implementing OOP in a dynamically typed language like Python removes even the slightest advantage of OOP in terms of interface safety... because classes can redefine themselves on the fly. Worse, actually... individual objects can create new classes on the fly. It's just total insanity. ;-) A correctly implemented OOP language has to be statically typed. One can always load a messaging system on top of that. What one can never do is to remove the hazards of a dynamic language by adding message passing on top. That ship has sailed as soon as a function is allowed to allocate memory on the fly (which most statically typed languages do, by the way).
@@lepidoptera9337 That first part is a funny thing to say because all the strongest and most advanced type systems nowadays happen to not be in "OOP" languages. And that's even the "normal" definition of OOP. I personally can think of only one statically typed language that is OOP according to the definition presented in this series, and it's not often chosen by architects. I do agree though that static typing is the most sensible thing to choose in almost all cases, irregardless if your language is otherwise OOP, functional, logical, actor-based, constraint-solving, mixed, or what have you. A good type system can even help solve that memory problem - just look at Rust. However: what Huw seems to imply in the video is that message types are to be checked at runtime only. That's just a different way to say that a "good" message passing system is necessarily dynamically typed. Exactly because I agree with you I must either disagree with that part of the otherwise very informative video, or I must be misunderstanding it.
@@insanemole "That first part is a funny thing to say because all the strongest and most advanced type systems nowadays happen to not be in "OOP" languages." That is what I am saying. OOP works fine (within the limits of what it actually does, which is not what is advertised) in statically typed languages. It does not even do that if implemented as syntactic sugar in a dynamic language like Python. I do use Python classes quite extensively, by the way, I am just not expecting them to save me from dynamic type hell. I treat them as a mini-library mechanism without libraries... which is explicitly NOT what OOP is supposed to be about. I never use inheritance because it is futile. Everything that applies to types also applies to message types. If we want to avoid runtime message type checking (which produces copious runtime errors that a statically typed program just can't have), then message type has to be declared and strictly enforced by the compiler. Even with that we are still saddled with the non-determinism of message passing, but that's a price we have to pay for parallelism one way or another. My main point is that in Kay's mind (and the minds of his followers) a lot of different (and orthogonal) concerns are all messed up. There seems to be almost no rational thought going into the questions of what kind of problem OOP is trying to solve and what it definitely can not do.
So really that's all there is to it? "Message passing" is really just a fancy word for invoking a "method", "member function", or whatever the language of your choices chooses to call that construct? Honestly that's a bit disappointing. I kept thinking of it as something grander, something like a loosely coupled event-based pub/sub control flow mechanism built into the language. Wasn't something like that kind of Alan Kay's vision? Then I think it's fair to say that no OOP language ever truly delivered on that vision, and that includes Smalltalk. Or am missing some point here?
Correct me if I'm wrong, but the huge benefit is dynamic binding. For example, if you want to add methods dynamically to an object, then ask that object if it has that method to use. I could think of instances where this is useful as a language feature, whereby it would be difficult in C++. For instance, I want to use the Command Pattern dynamically. If I want to dynamically create objects, then try to call methods that I am unsure exists yet. I imagine that this form of "true object orientation" is only possible with dynamic languages, or you would have to do a lot of dynamic checking with a C++ language, for example. Again, I could be wrong, but I could see dynamic Commands as beneficial as a language feature.
It is actually far more revolutionary than it may now seem (since so many other OOP languages have taken/adapted ideas from it and programmers no longer see quite how big an idea this is). It is all about the internal integrity of objects. I discuss how message-passing is used and how it implements modularity in many of the lessons in this series so don't dismiss it too soon! 🙂
@@AnthonySouls What does dynamic binding get you, exactly? Runtime errors. So lets say you send the wrong message to a message receiver and it responds "No can do, Sir! Please visit us again.". So now what? You catch the error... and print to the user: "This program has encountered an unexpected error and needs to shut down. Please do not call customer service. There is nobody to take your complaint.". In a statically typed environment this would have been a compiler error and your developer team would have corrected it before it ever went to the user...
Hello, and thanks a lot for the effort and the videos, I really enjoyed them! I would also like to recommend the Berkeley lectures from 2010 with Brian Harvey about OOP and message passing - th-cam.com/video/Y9ZYTTetURs/w-d-xo.html
Finally!!!! I been waiting for more smalltalk vids :^)
Thanks! Be patient. There will be more.... 🙂
It's a very simple and elegant idea. Imagine a world of people. Imagine each person has a 'role' like lawyer, plumber (etc.). Methods are not floating free in the code structure. Methods belong to objects, which are instantiations of classes. If it's needed to fix a random leakage in the plumbing system it would not be possible to call a function directly (supposing a function/method called fixPlumbing). It is necessary to send the message for bject Plumber, because the methds fixPlumbing is encapsulated in there. There are no 'free hoovering functions'. Everything is inside an object. In this example, the object lawyer would not have the method for dealing with fixing the plumbing system. So it's not calling directly the function. Its asking for the ject to handle the message.
Hope you plan to continue this series! It's very important for people that don't have any contact with Smalltalk and "Message passing OOP".
There will more some more a bit later on in the year.
function calling is as giving orders or force object to do something
message passing is as asking to do something
message passing is very very late binding... practicaly dynamic binding at runtime.
it is also possible with calling but requires special features in run enviroment and/or langugage
What's the value in being able to send any message to any object?
Your sample of catching the error of 123 not handling asLowercase suggests to me that Smalltalk is doing function lookups at runtime, which reminds me of how Python handles method calls, and indeed, you COULD write a very similar chunk of code to handle the Python exception if you tried to call 123.asLowercase() in Python, but I'm not sure what this gains us.
In most cases, the only benefit would be either error-handling (many modern OO languages use a similar broad approach to exception-handling) or code generalisation. That is, your code would produce a response rather than just crashing.
You really have to try to think back to a time (the 70s/80s) when "any" idea of communicating with an object (rather than just calling a free-standing function) was totally alien to programmers. The key idea is that communication is done *with the object* rather than by a direct function-call. The ability to deal with unexpected messages was one feature of this idea of communicating with objects. You "ask" an object to do something and, if an appropriate method is defined, it does what you expect. If the method is not defined, it can at least inform you of that fact.
I think the value is that of making the code much more robust, after you have made it much more flexible by using dynamic typing. In another scenario you could have a container that holds a bunch of objects and you throw in objects of whatever type without regard (E.g. strings, single chars, fixed-size strings, integers, floats, long floats, short integers, user defined classes, pairs holding any combination of these) and then you traverse this container and you want to make uppercase all strings, and similar types, and leave alone the others. Do you get my point?
In general the idea was that of "extreme decoupling" (my wording), decouple everything as much as you can. Ora at least give to the programmer the means to do so.
@@dellusionald1794 I can totally see the value of having some methods be available to many classes - a "ToString" method can be broadly useful, but what seems wrong to me is holding up the ability to send ALL messages to ALL classes as a super important language feature.
@LearnWithHuw says that one benefit of allowing all messages to go to all classes is error handling, but that seems to prove the point; for at least some classes, it's an error to pass the message to that class, but it's necessarily a runtime error. This feels much LESS robust; making it harder to deal with code with errors.
Early in the series, the claim was that message passing was a super important thing that's been forgotten by modern languages, but this video seems to say that method calls are the new way of accomplishing the same thing - did I misunderstand this?
I'm not sure. I think the dilution of the idea of message passing to just "invoke method" is sad. There are a whole lot of practises which have grown up around programming (DDD, eventmapping, story mapping) which essentially restore this abstraction (message passing) at the design stage. We took a wrong turn with C++, Java, C# et al. I think message oriented OO will have a come back soon.
In many ways I agree. Many of the ideas of Smalltalk have been "adapted" to work with languages in which those ideas seem, well, a bit out of place.
While I do make use of OO in C# and Java, there are many projects when I think a fully procedural language such as Pascal (or, better still, Modula-2) would be better. But in the modern world, we have a range of somewhat hybridized languages.
As I am discovering in this series, explaining the Smalltalk version of OO to people who are already familiar with OO in later languages provides a peculiar set of problems. 🙂
@@LearnWithHuw bear in mind I largely learned OOP via C# and then had to work out why I found it so unsatisfying. Alan Kay represented a breath of fresh air for me.
You can implement message passing in any language. Will it do you any good? No, not really. It's just another level of insanity that is being propagated by the CS illiterate. Unless you are building distributed systems, message passing is almost always overhead for overhead's sake.
I've enjoyed this series a lot. The content is great. I do hope in future videos there is an effort to put together some non-trivial code though.
Superficially, objects and messaging sounds great, but I have rarely if ever seen any application of size and substance that adheres to these principles and doesn't in many places devolve into procedural patterns. Classes end up being like structs in Go or Rust but unnecesarily have to carry around their arbitrary type with them. References are passed into method calls in Java/C# and getters and setters are everywhere, just adding indirection to the private fields.
Thanks. In this series I try to focus on very small code fragments for clarity (based on the Smalltalk/V tutorial). If you browse my playlists however, you will find some very complex projects with much more challenging code! You may enjoy one or two of those.
@@LearnWithHuw Thanks. I'll take a look!
Well, if you take into consideration Alan Kay's definition of OO then Smalltalk would not be OO, that would be something like the Actor Model, which Smalltalk isn't.
In compiled OO languages in which everything is an object, you do not have the `doesNotUnderstand:` or Ruby's `method_missing` because this is more of dynamic OO languages than a feature of OO. But if you forget to define `doesNotUnderstand:` or `method_missing` then you will get an error.
However you are thinking this wrong, because you are thinking objects are not function, only methods are functions, however if you consider that a function is an object and the message is the list of arguments and that it will dispatch based on whatever data gets from the arguments including the values of them, then you can have a similar behavior.
I don't see any practical difference between the pattern of "private data + public functions" and the "objects that sends messages to other objects, that requires the receiver to have a method with same name". I don't see any "practical difference" or how this specific abstraction solves any problem that current OO-approaches has issues solving.
For example, dependency injection. For me to create an object A that depends on another object B (because some of its methods requires colaboration by B), I have to make sure B exists before A since I need to pass B as dependency to A in its creation, which create a dependency between objects lifetime which is sometimes very hard to manage. Some people calls this problem the "problem of object wiring". How does Smalltak solve this? If an object A needs help, do A needs to know that B is the object that solves my problem, and so A needs to store/contain a reference to B? Because if it does, then it has the same problem that modern-day OO.
Another example: when A have the information to do something, but A doesn't know how to do it, because it's not its responsability. Usually you rely on a getter: B knows how to do it, but doesn't have the information: A, give it to me and then I do the thing. That completely breaks encapsulation since A is exposing private information and structure through the getters, but no other solution is good since you don't know how to do the "thing". How does smalltalk solve this problem?
Is there any problem that smalltalk solves in a very elegant way that is completely unreachable for traditional OO-languages? How is that abstraction of message passing "superior" to the way OO is understood nowadays?
It's not necessarily superior, it's just different.
Smalltalk's designers had a very different future in mind. They were working on this highly interactive machine in which Smalltalk was to be the primary means of communication with it and the operating system all wrapped in one, so they implemented Smalltalk as a collection of live objects, always running in memory with just in time compilation and very late binding/dispatch of method calls because what they anticipated was that if you call a method on an object (send it a message), you never know in advance if the object has an implementation for that method (knows how to respond to the message) but they gave you tools to implement the method on the fly and it's something Hew doesn't show in this video, but the thing is that when that debug window pops up, you can actually go into the definition for your Integer object and implement an asLowercase method on it, 'accept' it and the resume execution and everything will be honky dory.
It was a very different paradigm.
The difference is that in when the system checks whether or not a specific object has the implementation for a method being called on it. Most modern languages try to check this as early as possible, essentially during compilation, in Smalltalk that's left until when the code is run and the method is called.
It was a neat idea for the purposes Smalltalk was designed for but it came at a huge cost: very slow execution because of the runtime method dispatch.
It's kind of similar to how in javascript when you try to read the value of a property that doesn't exist you just get undefined, but the execution doesn't stop, it's essentially a tradeoff between compile-time errors(function calling) and runtime errors(message passing).
The difference is probably that you get general polymorphism just naturally "for free" in Smalltalk. But you have to resort to inheritance and virtual functions in something like C++ just to get a limited form of polymorphism, since it is bound to only subclasses.
"when A have the information to do something, but A doesn't know how to do it, because it's not its responsability." The Smalltalk examples are a bit extreme as they violate the "single responsibility" principle. But OOP doesn't have to be that way. In your case A is just a pure data abstraction, like an Integer, so the respective level of encapsulation is only the one that is needed to manipulate the data within safe bounds. B is then a system that manipulates A. So just think about A as a primitive data type like an integer and ask the question. Do you really break encapsulation by manipulating an integer the way you want? ;)
The problem is: It's never meaningful to send a message to an object that it cannot understand. This will never produce any meaningful outcome. So why would a programming language (or more precisely a compiler) allow you to do something that is known to not produce a meaningful output? And if you argue "maybe at runtime the message will be understood", then this is still not satisfactory unless the compiler forces you to always handle the case it isn't. And if the compiler has no knowledge what messages are understood, you would have to treat any message ever sent to any object as "will possibly fail" and then your code would be an unreadable mess.
A properly implemented message passing language does not allow you to do that. It will throw a compile time error if you try, just like a statically typed language will throw a compile time error if you call a function with the wrong data types. What these people are talking about here is simply not message passing. If you want to do this properly, then you are basically replacing the struct/typedef syntax with a message definition syntax. Up to that point it's all equivalent. Where it stops being equivalent is at runtime. Direct function calls are perfectly deterministic, i.e. in which order functions are being called in a single threated application is obvious from the program code alone, while this is not the case in message passing implementations.
@@lepidoptera9337 "A properly implemented message passing language" - like? Please provide a sample for such a language. I don't know of any such language. Languages which do type checking and grantee that only allowed calls are made at compile time are not message passing language, they are function calling languages. As these languages require objects to have an interface and you are just calling functions/methods defined by that interface. But that's not how message passing works.
@@xcoder1122 I am not regular user or even a proponent of message passing, so I don't care about languages that may or may not implement this properly. If I need it, I usually implement it in my own library (which I have done once in my entire life... which tells you just how "important" it is as a regular programming technique). We do agree, by the way. Strong type systems have utility and there are many type-safe languages. It is also correct that message passing has absolutely nothing to do with objects. The only people who believe otherwise are praying to St. Kay. It's a religious belief and a personality cult. It's not proper CS. ;-)
#doesNotUnderstand: reifies the message into an object itself, which may then be passed as an arguement, for example with the #perform: message to implement proxies to forward messages to objects instantiated from a database byte-string retrieval.
When I first encountered Simula 67 back in the mid 1970's I immediately grasped the concept but could not grasp the implementation. Later I read the Byte magazine Smalltalk article with great interest, it really didn't click with me. Later I came to understand the terminology as only making sense in a distributed program environment. Much later I encountered the Scandinavian language Beta, it too immediately clicked in my head. Beta (and some other languages) had the concept of pattern and object, the pattern being the factory that instantiates objects (though that can also be done at compile time), and the object may contain code which is executed exactly once, when the object is instantiated. I loved this concept because it unifies the concept of blocks, structures, procedures, classes, objects, and threads. It conceptually obsoleted every other compiled OO language that exists. Or maybe it's just my low IQ that keeps me from taking in the entire train wreck that is C++.
You will notice that I make videos about lots of languages but not C++. 🙂 The Byte article made no sense at all to me when I first read it. I didn't even understand what a mouse and windows were! I think I've caught up now!
If I am not mistaken, you can simulate message passing in mainstream languages as well:
public interface IMessage
{
bool HasResult {get; set;}
object Result {get; set;}
}
public interface ISmallTalkObject
{
void Handle(IMessage message);
}
This doesnt tell you what kind of message the implementer of the interface accepts, and it can definitely choose not to implement the message at all, to throw exception etc.
Yes.. but part of Smalltalk's philosophy is to make it seamless.
Non statically typed languages like Python and Ruby (or Javascript) are more suited for Smalltalk's concept of Polymorphism. The static type version is cumbersome.
@acasualviewer5861 What is cumbersome exactly?
@@kostasgkoutis8534 This isn't message passing. It's just programmer's OCD. You are replacing the function call mechanism that your CPU has already implemented in hardware with a soft implementation. Proper message passing deposits a datagram with a central message handler which then dispatches it to the appropriately registered receiver objects. This is a form of concurrency that makes programs indeterministic (the message handler knows nothing about the call tree structure of the program, whereas direct function calls do). There are so many theoretical CS mistakes here that I can't even count them. Have any of you guys taken an actual computer science class?
@@lepidoptera9337 You talk about message passing as a model for computation in the general sense (you also bring the point of emergent concurrency), I talk about simulating the behavior of a smalltalk object.
@@kostasgkoutis8534 And you are trying to be an apologist for Kay who made a name for himself by redefining terms. Who gives a shit about Smalltalk? When was the last time anybody used it to write serious software? It's an irrelevant piece of CS history. Let it rest in its cold grave, together with Kay's idiotic ideas.
Love this series. The doesNotUnderstand reminds me of Ruby's method_missing.
Yes, Ruby certainly took a few ideas from Smalltalk! In some ways, Ruby is a bit like the Little Smalltalk language (from the late 80s/early 90s, I think) which was a version of Smalltalk without an IDE.
If there is say an object or actor or whatever with encapsulated state and two calls get called to it at the same time if they both read and change state then state could be wrong like if both increase a counter then i guess anything that changes state should be put in sortve a message queue and only start the second call after the first one ends
In an earlier video, you suggested that message passing implies three of the four key features of object-oriented programming: encapsulation, polymorphism, add a third one which I am not recalling at the moment. In this video, you have effectively added exception handling to that list implied concepts. And you seem to be implying that it's even broader than that. If I'm following your explanation correctly, it seems that small talk in particular and pure object-oriented programming in general (or perhaps we should call it message passing programming?) Also implies parallel programming at distributed programming. Conceptually, every object is acting in parallel to every other object; and encapsulation doesn't just mean that the internals of the object are hidden; it also means that the location of the object is irrelevant. It could be hosted, in theory, on a different computer halfway around the world, running a different operating system. An Application could be thought of as an object, with its API as the messages that it listens for.
Am I understanding you correctly?
Exception-handling wouldn't be considered a fundamental feature of OOP. You are right, though, to think of an object as being its own "little world". You communicate via messages and in principle the object might indeed be at a remote location. I'm not sure that parallel programming was an idea that was current when Smalltalk was developed (though they were so far ahead of the world at Xerox PARC that maybe it was?) but OOP encapsulation certainly provides one type of modularity that can be used for this.
@@LearnWithHuw I was actually thinking more along the lines of event driven programming, with messages as the events; I just got the wrong term.
You are making the same CS mistakes as every other believe in St. Kay. OOP and parallelism have nothing to do with each other. Kay was just full of himself and redefined terms in irrational ways.
@@lepidoptera9337 I'm sorry; who is Kay?
@@dataweaver The fool who is credited with inventing this insane idea that OOP is message passing. :-)
i still don't understand how is this different than modern oop languages. the only difference i see is that smalltalk doesn't have a smart compiler that will tell you that a given class/object method/property doesn't exist before runtime, so that you don't get the error at runtime as with smalltalk.
As I said, a method-call in a modern OOP language is essentially derived from message-passing in Smalltalk. So if you are used to Java, C# or similar you won't see any huge difference (apart from the ability to send any message to any object in Smalltalk) because C#, Java, C++ etc. have adapted ideas that most programmers had never encountered before Smalltalk.
But if you compare Smalltalk (and the OOP languages that followed from it) with a procedural language like C or Pascal, there is a big difference since you have to get "into" the object by message-passing (or "method-calling" if that's how you like to think of it). So the BIG difference is between procedural and OOP methodology. Don't worry too much about the terminology.
@@LearnWithHuw got it, thanks for clarifying.
@@gahshunker Thanks for letting me know. The terminology can sometimes be a barrier.
To be able to call a method (or send a message) to an object that doesn´t support it, is a property of the dynamique typing of the language, not because the compiler is dumb. Python does it to, it send an exception "AttributeError", that can be catched to do something custom.
@@LearnWithHuw I think you need to think about routers and hos they look up ips because they can pass ips to other routers and while you can achieve that in any oo language I think the perception is the difference, so invoking a method is about ordering the object to do one thing while massage passing you can change the method many times let alone passing to other objects in ruby they do that , in python you can do the same expanding that I think gives you in some sense interfaces like ruby ones more than objects in the common sense
great video! a very clear explanation. could you do one on uml class diagrams to explain how these oop concepts translate to that notation? also, if you did a comparison of smalltalk and python that would be interesting to many people i think, people that want to see the traditional/ fundamental oop concepts as they relate to python.
Many thanks. I'll add your ideas to my (long!) list of possible future videos! 🙂
Yeah, about time such clarity exists - thanks. I'll try this in C# and see if it acts the same or is its own flavour of OO.
This distinction doesn't make a lot of sense to me. What it sounds like to me is that you're saying message passing always MUST go hand in hand with dynamic typing. But the compiler CAN statically check if an object will be able to understand a particular message, it's just that Smalltalk's in particular doesn't. But something like the Akka library in the Scala world IS doing exactly that nowadays. (Akka is not an implementation of Smalltalk-like OOB but of an Erlang-like actor system, so this is only an observation of its message passing aspect, but the argument still stands.) And conversely, I CAN try to invoke any method of a JavaScript object with any arguments and the "compiler" will happily accept that - it will only possibly fail at runtime, just as in Smalltalk.
But I do suspect another difference: What I've seen in actor systems is that there, message passing has a lot to do with loosening synchronisation restrictions between "caller" and "callee" - because the default in imperative and pseudo-OOB-languages is to wait for an answer to a method call on each invocation while in actor systems the default is to fire-and-forget messages, then continuing with my own business, which might(!) include awaiting message, including, but not(!) limited to replies to my own past messages. But again, that's in the actor world, so I don't know what Smalltalk does in this respect and if that's part of the original mission statement of OOB? I can imagine that control over multiple concurrent threads was quite a bit different back then...
OOP is not dynamic typing. It's actually quite the opposite. The main reason why an architect will chose the OOP paradigm is to have the strongest possible type system. Implementing OOP in a dynamically typed language like Python removes even the slightest advantage of OOP in terms of interface safety... because classes can redefine themselves on the fly. Worse, actually... individual objects can create new classes on the fly. It's just total insanity. ;-)
A correctly implemented OOP language has to be statically typed. One can always load a messaging system on top of that. What one can never do is to remove the hazards of a dynamic language by adding message passing on top. That ship has sailed as soon as a function is allowed to allocate memory on the fly (which most statically typed languages do, by the way).
@@lepidoptera9337 That first part is a funny thing to say because all the strongest and most advanced type systems nowadays happen to not be in "OOP" languages. And that's even the "normal" definition of OOP. I personally can think of only one statically typed language that is OOP according to the definition presented in this series, and it's not often chosen by architects.
I do agree though that static typing is the most sensible thing to choose in almost all cases, irregardless if your language is otherwise OOP, functional, logical, actor-based, constraint-solving, mixed, or what have you. A good type system can even help solve that memory problem - just look at Rust.
However: what Huw seems to imply in the video is that message types are to be checked at runtime only. That's just a different way to say that a "good" message passing system is necessarily dynamically typed. Exactly because I agree with you I must either disagree with that part of the otherwise very informative video, or I must be misunderstanding it.
@@insanemole "That first part is a funny thing to say because all the strongest and most advanced type systems nowadays happen to not be in "OOP" languages."
That is what I am saying. OOP works fine (within the limits of what it actually does, which is not what is advertised) in statically typed languages. It does not even do that if implemented as syntactic sugar in a dynamic language like Python. I do use Python classes quite extensively, by the way, I am just not expecting them to save me from dynamic type hell. I treat them as a mini-library mechanism without libraries... which is explicitly NOT what OOP is supposed to be about. I never use inheritance because it is futile.
Everything that applies to types also applies to message types. If we want to avoid runtime message type checking (which produces copious runtime errors that a statically typed program just can't have), then message type has to be declared and strictly enforced by the compiler. Even with that we are still saddled with the non-determinism of message passing, but that's a price we have to pay for parallelism one way or another.
My main point is that in Kay's mind (and the minds of his followers) a lot of different (and orthogonal) concerns are all messed up. There seems to be almost no rational thought going into the questions of what kind of problem OOP is trying to solve and what it definitely can not do.
So really that's all there is to it? "Message passing" is really just a fancy word for invoking a "method", "member function", or whatever the language of your choices chooses to call that construct? Honestly that's a bit disappointing. I kept thinking of it as something grander, something like a loosely coupled event-based pub/sub control flow mechanism built into the language. Wasn't something like that kind of Alan Kay's vision? Then I think it's fair to say that no OOP language ever truly delivered on that vision, and that includes Smalltalk. Or am missing some point here?
Correct me if I'm wrong, but the huge benefit is dynamic binding. For example, if you want to add methods dynamically to an object, then ask that object if it has that method to use. I could think of instances where this is useful as a language feature, whereby it would be difficult in C++.
For instance, I want to use the Command Pattern dynamically. If I want to dynamically create objects, then try to call methods that I am unsure exists yet. I imagine that this form of "true object orientation" is only possible with dynamic languages, or you would have to do a lot of dynamic checking with a C++ language, for example.
Again, I could be wrong, but I could see dynamic Commands as beneficial as a language feature.
It is actually far more revolutionary than it may now seem (since so many other OOP languages have taken/adapted ideas from it and programmers no longer see quite how big an idea this is). It is all about the internal integrity of objects. I discuss how message-passing is used and how it implements modularity in many of the lessons in this series so don't dismiss it too soon! 🙂
@@AnthonySouls What does dynamic binding get you, exactly? Runtime errors. So lets say you send the wrong message to a message receiver and it responds "No can do, Sir! Please visit us again.". So now what? You catch the error... and print to the user: "This program has encountered an unexpected error and needs to shut down. Please do not call customer service. There is nobody to take your complaint.". In a statically typed environment this would have been a compiler error and your developer team would have corrected it before it ever went to the user...
Hmmmmm... can of worms?
Smalltalk has been on my "should, at least, have a look" list for ages... so thanks.
It's an academic curiosity, for sure. Also completely useless in software design, which is an engineering discipline. :-)
Hello, and thanks a lot for the effort and the videos, I really enjoyed them!
I would also like to recommend the Berkeley lectures from 2010 with Brian Harvey about OOP and message passing - th-cam.com/video/Y9ZYTTetURs/w-d-xo.html