I strongly agree to the core message of your videoclip (as an application specialist for legacyware in a big company). Without overthinking too much. This concept seems to be the most familiar to me when I look at a modern day microservice architecture, which seems to be bloated at times, but does not have to be at all.
He should have brought in the term modules. Modules fit in with black box mentality. They can be binded at the very last minute. A program would think of modules as blobs of code and the only means of communicating with them is thru an agreed upon machine-to-machine language (what small talk calls messages). And yes, I believe its an incredibly powerful yet unexplored concept. Machines need a vocabulary of their own which is basically standardized data types.
Sorry but this video only convienced me that "message passing" is really what we would call "method calling" in modern OO languages, and Object Orientation is exactly what pretty much any modern OO language developer would know as Object Orientation. We can argue about terms all day and night, but when they all come to mean the same thing we should realize it's a waste of time and only makes things more confusing, not helping anyone. The only thing I got out of this video is that data in an Object shouldn't be directly modifiable, or even accessible, from the outside, which although is not enforced in many modern OO languages, like Java (Is it enforced in SmallTalk btw? I saw earlier in the series that you were modifying arrays, so my understanding so far is it's not), it's a thing that you learn early on and any proper OO tutorial, teacher or any method that you choose to learn an OO language. They will tell you how much of an "antipattern" is to modify or even access data within an object directly, and that you should hide those data fields if the language permits you to do it (making them private for example).
So an object-oriented language is to functions as a functional language is to variables? By this I mean that in functional languages, variables only exist within the local scope of a blackbox function, and in an object-oriented language functions (methods) only exist within the local scope of a blackbox object. Would you say that is an acceptable analogy?
I just spent over four hours trying to find an explanation of what OOP really is about and why it looks like something I can do with functions and a database. The video before you actually said we are moving the focus of programming from function centered to data centered. (I can't relate to writing 50 lines of code to say an apple is red and an orange is orange.) You really cleared it up with your explanation about "Black Box" and "Communication". You also pointed to "variables" which make more sense than orange oranges. Now I can understand how the code works. When I wanted hours worked from an employee, I would call a function that would retrieve his data and another function would total his hours. But, now, the same line of code would be something like hoursWorked = payroll.hoursworked(employeeid); or YTD = payroll.YTD(employeeid); It might be that one or both of the above examples would call an object that gets information from another object. I realize that this is just scratching the surface for me, but your giving me the background, and more importantly, the purpose of the "black box" giving only one response, makes a lot of sense. I actually think I can understand OOP, mentally, but not necessarily programming wise yet. Now that I know the purpose, I think I can better understand the process. Thank you very much. I'll be checking out your channel.
Many thanks for your very detailed comment. I've often noticed how overly-complicated some explanations of OOP tend to be. I do my best to try to keep things as simple as possible. I'm pleased you found it useful!
@@LearnWithHuw I have been hearing about OOP since about 1986, but it has always been the same thing. Cars have engines that go voom, birds tweet, and cats and dogs meow and bark. Never has anyone tried to identify it in terms of programming. Thank you. I subscribed. I am also checking out your adventure game series. I had to download the completed files because you the newer version of VS '22 is different enough I get confused. I also see why my son calls C# "Microsoft Java", LOL. Thank you again.
@@BlessedLaymanNC Glad to help. I hope you enjoy the adventure game series. It delves into a huge range of programming topics and techniques so you can make it as simple or as complicated as you like. Have fun!
Real OOP could be done in Redbol langs using DSLs, i.e., in Red 0.6.5,, R3 or REBOL 2.7.8. A message would need to be a dialect and need a parser to comprehend that dialect. Unless Smalltalk was doing it that way, it was not doing message passing. Thus Alan Kay was pipe dreaming.
To be honest I am still struggling to understand the fundamental difference between calling a function in a class and sending a message to an object. In this case it seems that if you send a message to the object, then the object accesses the function and then returns a value then all you have done is added additional steps into the process of calling that function. It may be just me failing to understand a fundamental concept here (I am a bit stupid sometimes) but it doesnt seem to give any intrinsic value to me?
The basic idea is that the methods define interfaces. The only way to communicate with an object is by requesting something via a message that can be handled by a method. In principle a message may request anything like asking an object to return itself in uppercase. But only an object with the appropriate method (e.g. a string) will fulfil that request (an integer won't). My video on modularity may help to understand this: th-cam.com/video/MYDAAhB1QIo/w-d-xo.htmlsi=83d8NpXqdHWfmule Also, here is someone else's explanation, which may also help: medium.com/@marinbenc/what-is-message-passing-and-what-does-it-have-to-do-with-the-liver-pwotd-aa714cde7cda#:~:text=Message%20passing%20is%20a%20way,is%20to%20send%20a%20message.
@@doyouwantsli9680 I agree - it is the SAME thing. Anytime you use a method of a object, then the compiler is figuring out the message system behind the scenes for you. So, not a big deal. So, the the elephant in the room? The simple matter is when you use a property/method of a object, then the compiler is taking care of the messaging for you already! This thus gives little more benefit and rise to saying that when you assign some simple value to a variable, then you using the DMA memory controller, and then go on to state how important that DMA memory controller is. No, not really important at all (when writing code). Same goes for deciding to place another layer on top of that object to allow use of methods that don't exist. Well, not really a benefit, since someone MUST be writing some code to create that request that does not exist in the first place! We can't leave out that someone has to write that invalid code!!! Worse yet? The benefits of compile time resolution far outweighs the benefits of what is called late binding. So, this is not about messaging at all. It is what we call late binding vs early binding. So, what developers do is develop using early binding, but deploy using late binding. Why? Because it then allows the objects your consuming to be changed - including that of the interface. I mean, how does the .net interface to office (Excel, Word, Outlook etc.) work? Hint: They ALWAYS behind the scenes use late binding - ALWAYS!!! So, then how do you get compile time verification and checking? They build a separate interface with early binding (compile time resolution), but consume the office objects as late binding. That allows one to upgrade their version of office, but not break existing code! So, I not convinced that I would want to introduce a developer written layer over what the compiler already does for the developer in the first place. I don't care if when I consume that object that there is some old man with a telegraph or whatever - I ONLY care that I have a valid method anyway. So, no need to introduce some whole new layer of messaging here. The concept goes back to even the old VB5 days - and the term is called late binding. Late binding allows you to freely use and specify methods that don't exist - you just have to trap such errors....... I mean, if you were forced to create some message (in place of a simple use of some method and let the compiler do the messaging for you), then such code WILL STILL have to deal with a invalid return from that object. In most cases, it is better to have the object deal with the error and issue - not the client side calling code anyway. While the concept of introducing messaging on top of object that ALREADY have messaging built for you by the compiler? All you really gain is the ability to write code with invalid methods that don't exist yet - and in our industry for the last 25+ years, the term is called late binding, and thus no need exists to start hand writing a message system on top of the built in compiler generated messaging that already occurs and is done for the developer automatic. We no more care about messaging to a object anymore then that one is using a DMA controller when doing a simple variable assignment - those are things for the compiler to worry about - not us developers to waste our time with. So, yes, I 100% agree with you - same thing!!!! The only real new issue here is does one need or want to write code and specify properties/methods that don't exist yet, and there are already solutions to that such as late binding as opposed to early binding......
@@Albertkallal Im not talking about it being the same thing on a lower level. It's the same on a code level. The first person was asking what's the difference in calling a function attached to a class (aka a method) and "sending a message". Yeah, it's the same thing. The difference is only in the programmers mind, you can choose to make a function where the caller has control, or you can choose to make one that is just sending a message. If you want you can just make all classes with a single public ".send("hi")" method. But it doesn't make a big difference if you have one method that takes a string argument as a message, or you have that string as the name of a method in your code editor.
@@doyouwantsli9680 Sure, but the elephant in the room was that under the covers, messaging is occurring already, and there is no need to start writing such code. I mean, oleDB (object linking and embedding), ActiveX, and COM object automation are actually all based on the same underlying technology. And if one wants run time use of methods and properties, then again, no need to write some new code - it's called late binding, or you can even use reflection in .net, once again achieving the same goal (in effect this again is late binding). So, WHAT does make a differences is if YOU the developer want run time resolving of those methods vs that of compile time - if you use late binding then you are free to use methods that don't actually exist in that class - be it a invalid message, or message that don't exist, or using methods that don't exist, we have far better tools then say this video that suggests messaging is some big new way of thinking about how objects work. My position is that you no more have to think about this issue then that of assigning some simple value to a variable, and then we being told to go watch a 1 hour video on DMA controllers that allows this to happen under the covers. But, to be fair, yes, I 100% agree this an issue of how the developer is thinking vs that of how the tools can achieve such goals for you. Left out of this video is that most development systems do the talking between objects for you, and we don't have to see or bother with that messaging or inter program communication. Had this issue and that of late binding vs early binding been pointed out in the video, then little confusing would have occurred here. the concept of early object binding vs late binding been around for more then 25 years, at least it has been with Microsoft tools and platforms.
I appreciate the messaging role more now but I can't just downgrade the role of the object for encapsulating all the data and methods. To downgrade its importance would be tantamount to downgrading the role of the cell membrane in a biological system. It seems more reasonable to think of messaging and the encapsulating objects as equally important.
Yes, they are two ways of describing the same thing, in a way. I discuss that in more detail in my video on modularity. th-cam.com/video/MYDAAhB1QIo/w-d-xo.htmlsi=wpoyIPV_6kVBlidA Best wishes Huw
It's a historically interesting view, but let's not get stuck thinking that the first iteration of a concept is necessarily the best and only one. It's a nice notion that the Doctor object will treat you in response to a simple message -- but how is it supposed to do that without inspecting your state deeply to perform a diagnosis? And whether it inspects that state directly or by sending messages back asking questions, the whole concept of diagnosing a problem rests on it understanding how you are supposed to work, i.e., understanding your implementation in detail. The problem inherently requires breaking encapsulation to solve. There are a lot of ways this model breaks down in actual practice. This oldschool OOP has a place to be sure, but there are other ways to understand programming and even OOP which are equally valid and often more useful.
I certainly wouldn't argue that OOP is the answer to all problems. I think the concepts embodied in Smalltalk are, however, useful to understand if you happen to be using one of the modern OOP languages.
I think the main concept being illustrated here is the idea of information hiding. The "Doctor" object should only expose information it wants to expose, and the "Patient" object should only expose the information it wants to share with the Doctor. The Doctor shouldn't need to see the full private state of the Patient in order to treat it. In pseudo-code, a Doctor.TreatHeadache method could look something like this: TreatHeadache(Patient p): vitals = p.GetVitals() if (vitals.Temp > 38) p.GiveAspirin(...) else: ....
The point is that a large portion of language features that we're familiar with today are artifacts of language features of pure OOP. We can stand to learn a lot from the paradigms and idioms of smalltalk which is a predecessor of modern multiparadigm OO languages. It's all abstraction and design at the day.
I was just thinking how modularity applies in functional programming and from what you've just said I'd say it's: take in only the objects that you need to operate on directly and nothing above them. That means that the function won't break if the reference to the value you need on the containing object has its name or type changed without it also being changed there.
Modularity can be implemented in most languages and is strongly enforced in some languages. However, the term "module" is used to mean other things too, which sadly adds to the confusion.
@@LearnWithHuw you would probably be talking about vaccination and climate change instead of explaining the logic of sending message between objects lol
In Java using the final keyword on primitive parameters solves the problem but when passing objects I am not sure what should be done to prevent mutating a passed object.
In languages such as Java and C# you can try to make data private but you can't easily enforce that if you are working with others. However, keeping the internal details of objects "hidden" may be a useful design decision.
@@LearnWithHuw I was referring more to the problem that you spoke on about how when a reference is passed in and ca be mutated by the receiving object and avoiding using a return value. It can be prevented using Final on primitives but seems impossible to counter when an object is passed in even if all the object's fields are private - the receiving object is able to call methods on the object it received as a parameter and thus cause a mutated object. Is it possible to pass objects as parameters in SmallTalk? It would seem so if everything is an object so how is this problem overcome?
@@drcl7429 I believe there are differences in the way arguments are passed in Smalltalk, which may be related to the implementation. Usually, (I thing), they are sent by reference so, in principle, side-effects similar to the ones I discuss in this video, could occur. I cannot, however, recall seeing a standard Smalltalk method that modifies arguments in a way that would cause this to happen. The tradition is very much that arguments are sent into a method and only the explicitly returned value is used by code outside the object. However, preserving an object's integrity - (no matter which language you use) does require an "approach" to the programming problem in addition to the restrictions imposed by the language itself.
@@LearnWithHuw With standard libraries in java this is the case too. I remember thinking to myself how inefficient it must be when it was apparent to me that a copy of an object or list of objects would be made and returned. Only later did I realise its bad form to mess with arguments.
Methods return one object, so the choice can be between having the receiver construct a return object, which the sender then has to pick apart, or the sender can send down "empty buckets" for the receiver to fill up, and which the sender can, on return, refer to by name, making the code more readable, particularly if the called method requires recursion control, such as on a Btree.
"Message is a request, not a command." Does that mean that there should always be some response? Not the void used in modern languages? does a method returning void in a modern language break this contract?
One huge thing that C# lacks is the Smalltalk environment. I haven't discussed this in detail up to now but the fully integrated and interactive environment and class browser makes it much simpler and more "natural" to program in the Smalltalk-OOP way.
The object orientation analysis paradigm is kind of unnatural. Human thinking is about real world objects, their qualities, persons, relations, attitudes and actions, not messaging-messaging-messaging. Strict OOP makes programs bloated and hard to understand. Reading object oriented autogenerated documentation is a pain, since inheritance hides necessary information needed to understand the objects. I think OOP is OK if it is held at a very modest level, it improves the structure of an imperative program, but object orientation everywhere is just insanity. Smalltalk is virtually dead for a reason.
I have sympathy with the view that OOP is often misused in modern languages and programming projects. That said, OOP is here to stay and I strongly believe that programmers can make much better use of it (and write better code) if they understand the ideas at the heart of Smalltalk.
I think this is judgement before try. If you'd understand a simplicity of Smalltalk object model, or if you could understand the essence of message sending together with using blocks (kinda anonymous functions, or closures), you would find as a secret ingredience. Smalltalk doesn't need often any documentation, because system is immersive, you could look at every aspect/detail of entire system, even how the message sending or method compilation is implemented), community refers to this as "turtles all the ways down". Smalltalk is definitely not mainstream, but not for a bad design, but because of history and greed of authors of commercial implementations. There are modern implementations like Pharo, which is MIT licenced and used for serious purpose.
@@LearnWithHuw One can't write good code in OOP. Why? Because most requirements do not follow the OOP pattern. A rare exception are graphical interface widget libraries. They fit OOP reasonably well. Beyond that the use of OOP mostly produces bloat- and painware. My suggestion: if you don't understand what you are doing when you use OOP, then don't use it. It won't help you to become a better programmer. At most you will become a one trick pony.
@@lepidoptera9337 I disagree. While I've seen a lot of toe-curlingly bad OOP code, the core ideas in Smalltalk (and ignored by many modern OOP languages) are extremely powerful. Which is what this series of videos is all about. :-)
I still find Smalltalk to be an inspirational language. Many programming languages "do the job" well enough but don't have the conceptual elegance of Smalltalk.
@@freindimania11 When they developed the origins of OOP in the late 1950s and early 1960s machines had very little memory. Saving a few bits and words by reusing code seemed like a good idea. Ideally one would want to automate that code reuse, so we have to tell the compiler when such reuse is possible. That's where inheritance comes into play. If a class doesn't override the implementation of the function of the parent, then the code of the parent can be reused. Instead of having two copies of the same function in memory there is only one copy. The downside is that now we have "hardcoded" this "simplification" into the structure of the program with the granularity of a whole function. If a child class wants to change just one line of 100 of a parent's class member function we now have to "fork" that entire function... which has disastrous consequences for debugging: bug fixes in either the parent of the child class members do not automatically percolate from one to the other! What looked like a good idea first becomes a nightmare in practice. The savings in memory are absolutely marginal on a modern machine that may have 16GB of memory in addition... so the original reason to do this has long disappeared. But since people have forgotten about the original reason a long time ago, they are not even aware why they are doing this bullshit to begin with. ;-)
Yeah, it’s the same idea, though some (possibly many) actor frameworks prevent you from directly messaging an actor, instead forcing you to go through a manager (or similar) object.
The most important thing about it is that it's a form of documentation. If you don't understand why it is that, then you need to take CS101 again. You were clearly not paying attention the first time around. ;-)
I will never for the life of me understand why so many people try to make rules for coding lol. So many videos on this is how you should use this, use this principle, do this, don't do that, you are using it wrong. Imo if you do something and it works then it works. Is there a better way of doing something. Probably, there always is. But just get the job done.
Would you feel the same way about other engineering? For example, would you trust a mechanic working on your car if he simply wanted to get the job done? FWIW, I feel like I should be more like you! I tend to obsess a little too much about this stuff, when in reality, much of it is subjective, and can be dogmatic.
A good language will impose the right limitations upon you automatically; if you don't have that luxury you have to impose the limitations upon yourself. It might seem a pain to have everything immutable, but it's far less a pain than having to deal with shared state in a multi-threading context and trying figure out which thread last changed said state. Global variables might seem quick, easy and convenient to add and reference where their values are needed but you'll thank yourself later if you have to debug the code and can instead trace where the value came from using a breakpoint and the call stack. Copying & pasting code then changing some of the behaviour in the copy might 'get it working' but now if you want to modify the common behaviour you have to remember to update it in two places instead of one. If you're writing a one-time-run throw-away script to, for example, update some data in a database, I can understand it not having to be the cleanest, most maintainable code - since it will never get used again. If you're writing code getting used and maybe even distributed to multiple customers which, even worse, may not be able to be changed once it's released (e.g. if it's written on a microchip) you'll 100% want to make sure you've not created a maintenance nightmare down the line for someone (unless of course that was your intent! :-D).
Missed the opportunity to call it "Message-oriented programming". Let me MOP my way out of here.
I strongly agree to the core message of your videoclip (as an application specialist for legacyware in a big company). Without overthinking too much. This concept seems to be the most familiar to me when I look at a modern day microservice architecture, which seems to be bloated at times, but does not have to be at all.
Thank you.
What do you mean by microservice architecture
He should have brought in the term modules. Modules fit in with black box mentality. They can be binded at the very last minute. A program would think of modules as blobs of code and the only means of communicating with them is thru an agreed upon machine-to-machine language (what small talk calls messages). And yes, I believe its an incredibly powerful yet unexplored concept. Machines need a vocabulary of their own which is basically standardized data types.
very good for security because when data types are standardized they can be scrutinized for malformity before they are passed on to your object.
@9:22 thats what I was talking about. modules
You may want to take a look at my other video which is all about modules: th-cam.com/video/MYDAAhB1QIo/w-d-xo.htmlsi=3P-WQ9lSRcnWs_n6
Best wishes
Huw
Sorry but this video only convienced me that "message passing" is really what we would call "method calling" in modern OO languages, and Object Orientation is exactly what pretty much any modern OO language developer would know as Object Orientation. We can argue about terms all day and night, but when they all come to mean the same thing we should realize it's a waste of time and only makes things more confusing, not helping anyone. The only thing I got out of this video is that data in an Object shouldn't be directly modifiable, or even accessible, from the outside, which although is not enforced in many modern OO languages, like Java (Is it enforced in SmallTalk btw? I saw earlier in the series that you were modifying arrays, so my understanding so far is it's not), it's a thing that you learn early on and any proper OO tutorial, teacher or any method that you choose to learn an OO language. They will tell you how much of an "antipattern" is to modify or even access data within an object directly, and that you should hide those data fields if the language permits you to do it (making them private for example).
So an object-oriented language is to functions as a functional language is to variables? By this I mean that in functional languages, variables only exist within the local scope of a blackbox function, and in an object-oriented language functions (methods) only exist within the local scope of a blackbox object. Would you say that is an acceptable analogy?
Thanks for explaining all this, Huw. Love the enthusiasm and detail!
Many thanks. Glad you liked it.
I just spent over four hours trying to find an explanation of what OOP really is about and why it looks like something I can do with functions and a database. The video before you actually said we are moving the focus of programming from function centered to data centered. (I can't relate to writing 50 lines of code to say an apple is red and an orange is orange.)
You really cleared it up with your explanation about "Black Box" and "Communication". You also pointed to "variables" which make more sense than orange oranges.
Now I can understand how the code works. When I wanted hours worked from an employee, I would call a function that would retrieve his data and another function would total his hours. But, now, the same line of code would be something like
hoursWorked = payroll.hoursworked(employeeid); or
YTD = payroll.YTD(employeeid);
It might be that one or both of the above examples would call an object that gets information from another object.
I realize that this is just scratching the surface for me, but your giving me the background, and more importantly, the purpose of the "black box" giving only one response, makes a lot of sense.
I actually think I can understand OOP, mentally, but not necessarily programming wise yet. Now that I know the purpose, I think I can better understand the process.
Thank you very much. I'll be checking out your channel.
Many thanks for your very detailed comment. I've often noticed how overly-complicated some explanations of OOP tend to be. I do my best to try to keep things as simple as possible. I'm pleased you found it useful!
@@LearnWithHuw I have been hearing about OOP since about 1986, but it has always been the same thing. Cars have engines that go voom, birds tweet, and cats and dogs meow and bark. Never has anyone tried to identify it in terms of programming.
Thank you. I subscribed. I am also checking out your adventure game series. I had to download the completed files because you the newer version of VS '22 is different enough I get confused. I also see why my son calls C# "Microsoft Java", LOL.
Thank you again.
@@BlessedLaymanNC Glad to help. I hope you enjoy the adventure game series. It delves into a huge range of programming topics and techniques so you can make it as simple or as complicated as you like. Have fun!
Object oriented programming is so much more concrete of an idea after watching your videos.
Thank you.
Real OOP could be done in Redbol langs using DSLs, i.e., in Red 0.6.5,, R3 or REBOL 2.7.8.
A message would need to be a dialect and need a parser to comprehend that dialect.
Unless Smalltalk was doing it that way, it was not doing message passing. Thus Alan Kay was pipe dreaming.
To be honest I am still struggling to understand the fundamental difference between calling a function in a class and sending a message to an object. In this case it seems that if you send a message to the object, then the object accesses the function and then returns a value then all you have done is added additional steps into the process of calling that function. It may be just me failing to understand a fundamental concept here (I am a bit stupid sometimes) but it doesnt seem to give any intrinsic value to me?
The basic idea is that the methods define interfaces. The only way to communicate with an object is by requesting something via a message that can be handled by a method. In principle a message may request anything like asking an object to return itself in uppercase. But only an object with the appropriate method (e.g. a string) will fulfil that request (an integer won't). My video on modularity may help to understand this:
th-cam.com/video/MYDAAhB1QIo/w-d-xo.htmlsi=83d8NpXqdHWfmule
Also, here is someone else's explanation, which may also help:
medium.com/@marinbenc/what-is-message-passing-and-what-does-it-have-to-do-with-the-liver-pwotd-aa714cde7cda#:~:text=Message%20passing%20is%20a%20way,is%20to%20send%20a%20message.
Yep. Same thing.
@@doyouwantsli9680
I agree - it is the SAME thing. Anytime you use a method of a object, then the compiler is figuring out the message system behind the scenes for you. So, not a big deal.
So, the the elephant in the room? The simple matter is when you use a property/method of a object, then the compiler is taking care of the messaging for you already!
This thus gives little more benefit and rise to saying that when you assign some simple value to a variable, then you using the DMA memory controller, and then go on to state how important that DMA memory controller is. No, not really important at all (when writing code).
Same goes for deciding to place another layer on top of that object to allow use of methods that don't exist. Well, not really a benefit, since someone MUST be writing some code to create that request that does not exist in the first place! We can't leave out that someone has to write that invalid code!!!
Worse yet? The benefits of compile time resolution far outweighs the benefits of what is called late binding.
So, this is not about messaging at all. It is what we call late binding vs early binding.
So, what developers do is develop using early binding, but deploy using late binding.
Why?
Because it then allows the objects your consuming to be changed - including that of the interface.
I mean, how does the .net interface to office (Excel, Word, Outlook etc.) work?
Hint: They ALWAYS behind the scenes use late binding - ALWAYS!!!
So, then how do you get compile time verification and checking? They build a separate interface with early binding (compile time resolution), but consume the office objects as late binding. That allows one to upgrade their version of office, but not break existing code!
So, I not convinced that I would want to introduce a developer written layer over what the compiler already does for the developer in the first place. I don't care if when I consume that object that there is some old man with a telegraph or whatever - I ONLY care that I have a valid method anyway.
So, no need to introduce some whole new layer of messaging here. The concept goes back to even the old VB5 days - and the term is called late binding. Late binding allows you to freely use and specify methods that don't exist - you just have to trap such errors.......
I mean, if you were forced to create some message (in place of a simple use of some method and let the compiler do the messaging for you), then such code WILL STILL have to deal with a invalid return from that object. In most cases, it is better to have the object deal with the error and issue - not the client side calling code anyway.
While the concept of introducing messaging on top of object that ALREADY have messaging built for you by the compiler?
All you really gain is the ability to write code with invalid methods that don't exist yet - and in our industry for the last 25+ years, the term is called late binding, and thus no need exists to start hand writing a message system on top of the built in compiler generated messaging that already occurs and is done for the developer automatic.
We no more care about messaging to a object anymore then that one is using a DMA controller when doing a simple variable assignment - those are things for the compiler to worry about - not us developers to waste our time with.
So, yes, I 100% agree with you - same thing!!!!
The only real new issue here is does one need or want to write code and specify properties/methods that don't exist yet, and there are already solutions to that such as late binding as opposed to early binding......
@@Albertkallal Im not talking about it being the same thing on a lower level. It's the same on a code level. The first person was asking what's the difference in calling a function attached to a class (aka a method) and "sending a message". Yeah, it's the same thing. The difference is only in the programmers mind, you can choose to make a function where the caller has control, or you can choose to make one that is just sending a message. If you want you can just make all classes with a single public ".send("hi")" method. But it doesn't make a big difference if you have one method that takes a string argument as a message, or you have that string as the name of a method in your code editor.
@@doyouwantsli9680
Sure, but the elephant in the room was that under the covers, messaging is occurring already, and there is no need to start writing such code. I mean, oleDB (object linking and embedding), ActiveX, and COM object automation are actually all based on the same underlying technology.
And if one wants run time use of methods and properties, then again, no need to write some new code - it's called late binding, or you can even use reflection in .net, once again achieving the same goal (in effect this again is late binding).
So, WHAT does make a differences is if YOU the developer want run time resolving of those methods vs that of compile time - if you use late binding then you are free to use methods that don't actually exist in that class - be it a invalid message, or message that don't exist, or using methods that don't exist, we have far better tools then say this video that suggests messaging is some big new way of thinking about how objects work. My position is that you no more have to think about this issue then that of assigning some simple value to a variable, and then we being told to go watch a 1 hour video on DMA controllers that allows this to happen under the covers.
But, to be fair, yes, I 100% agree this an issue of how the developer is thinking vs that of how the tools can achieve such goals for you.
Left out of this video is that most development systems do the talking between objects for you, and we don't have to see or bother with that messaging or inter program communication. Had this issue and that of late binding vs early binding been pointed out in the video, then little confusing would have occurred here.
the concept of early object binding vs late binding been around for more then 25 years, at least it has been with Microsoft tools and platforms.
Really enjoying this series - thanks Huw. What do you think of the Pharo language?
I appreciate the messaging role more now but I can't just downgrade the role of the object for encapsulating all the data and methods. To downgrade its importance would be tantamount to downgrading the role of the cell membrane in a biological system. It seems more reasonable to think of messaging and the encapsulating objects as equally important.
Yes, they are two ways of describing the same thing, in a way. I discuss that in more detail in my video on modularity. th-cam.com/video/MYDAAhB1QIo/w-d-xo.htmlsi=wpoyIPV_6kVBlidA
Best wishes
Huw
It's a historically interesting view, but let's not get stuck thinking that the first iteration of a concept is necessarily the best and only one.
It's a nice notion that the Doctor object will treat you in response to a simple message -- but how is it supposed to do that without inspecting your state deeply to perform a diagnosis? And whether it inspects that state directly or by sending messages back asking questions, the whole concept of diagnosing a problem rests on it understanding how you are supposed to work, i.e., understanding your implementation in detail. The problem inherently requires breaking encapsulation to solve.
There are a lot of ways this model breaks down in actual practice. This oldschool OOP has a place to be sure, but there are other ways to understand programming and even OOP which are equally valid and often more useful.
I certainly wouldn't argue that OOP is the answer to all problems. I think the concepts embodied in Smalltalk are, however, useful to understand if you happen to be using one of the modern OOP languages.
I think the main concept being illustrated here is the idea of information hiding. The "Doctor" object should only expose information it wants to expose, and the "Patient" object should only expose the information it wants to share with the Doctor. The Doctor shouldn't need to see the full private state of the Patient in order to treat it.
In pseudo-code, a Doctor.TreatHeadache method could look something like this:
TreatHeadache(Patient p):
vitals = p.GetVitals()
if (vitals.Temp > 38)
p.GiveAspirin(...)
else:
....
The point is that a large portion of language features that we're familiar with today are artifacts of language features of pure OOP. We can stand to learn a lot from the paradigms and idioms of smalltalk which is a predecessor of modern multiparadigm OO languages. It's all abstraction and design at the day.
I'm glad I found this channel. I'm struggling with OOP.
Thanks. I have lots on that subject so I hope it all helps.
I was just thinking how modularity applies in functional programming and from what you've just said I'd say it's: take in only the objects that you need to operate on directly and nothing above them. That means that the function won't break if the reference to the value you need on the containing object has its name or type changed without it also being changed there.
Modularity can be implemented in most languages and is strongly enforced in some languages. However, the term "module" is used to mean other things too, which sadly adds to the confusion.
Thanks for teaching me programming Bill Gates very generous of you!!
Ha! If only I had Bill's wealth.
@@LearnWithHuw you would probably be talking about vaccination and climate change instead of explaining the logic of sending message between objects lol
In Java using the final keyword on primitive parameters solves the problem but when passing objects I am not sure what should be done to prevent mutating a passed object.
In languages such as Java and C# you can try to make data private but you can't easily enforce that if you are working with others. However, keeping the internal details of objects "hidden" may be a useful design decision.
@@LearnWithHuw I was referring more to the problem that you spoke on about how when a reference is passed in and ca be mutated by the receiving object and avoiding using a return value. It can be prevented using Final on primitives but seems impossible to counter when an object is passed in even if all the object's fields are private - the receiving object is able to call methods on the object it received as a parameter and thus cause a mutated object.
Is it possible to pass objects as parameters in SmallTalk? It would seem so if everything is an object so how is this problem overcome?
@@drcl7429 I believe there are differences in the way arguments are passed in Smalltalk, which may be related to the implementation. Usually, (I thing), they are sent by reference so, in principle, side-effects similar to the ones I discuss in this video, could occur. I cannot, however, recall seeing a standard Smalltalk method that modifies arguments in a way that would cause this to happen. The tradition is very much that arguments are sent into a method and only the explicitly returned value is used by code outside the object. However, preserving an object's integrity - (no matter which language you use) does require an "approach" to the programming problem in addition to the restrictions imposed by the language itself.
@@LearnWithHuw With standard libraries in java this is the case too. I remember thinking to myself how inefficient it must be when it was apparent to me that a copy of an object or list of objects would be made and returned. Only later did I realise its bad form to mess with arguments.
Methods return one object, so the choice can be between having the receiver construct a return object, which the sender then has to pick apart, or the sender can send down "empty buckets" for the receiver to fill up, and which the sender can, on return, refer to by name, making the code more readable, particularly if the called method requires recursion control, such as on a Btree.
"Message is a request, not a command." Does that mean that there should always be some response? Not the void used in modern languages? does a method returning void in a modern language break this contract?
Ideally there should be a reply, even if it's as relatively unhelpful as "I don't know how to handle that message".
If a method makes no explicit return, the default returned object is itself.
I love your videos. Thank you for taking to to make these videos.
Many thanks!
A great video, thankyou
Many thanks.
Thank you so much for this video!
I'm glad it was of interest.
Thank you for Your videos! They are like a sunshine 🌞 through this war dark times!
I'm so glad to hear that. It must be very hard for you. Many thanks for your kind comments. And all my best wishes.
"Hello Joe!"
I guess C# could function this way if you used Delegates for literally everything
One huge thing that C# lacks is the Smalltalk environment. I haven't discussed this in detail up to now but the fully integrated and interactive environment and class browser makes it much simpler and more "natural" to program in the Smalltalk-OOP way.
Is there any other options to download the pdf tutorial, i'm sorry that i can not access it
I've just checked and both links are working. Alternatively browse to find the book here: stephane.ducasse.free.fr/FreeBooks/
The object orientation analysis paradigm is kind of unnatural. Human thinking is about real world objects, their qualities, persons, relations, attitudes and actions, not messaging-messaging-messaging. Strict OOP makes programs bloated and hard to understand. Reading object oriented autogenerated documentation is a pain, since inheritance hides necessary information needed to understand the objects. I think OOP is OK if it is held at a very modest level, it improves the structure of an imperative program, but object orientation everywhere is just insanity. Smalltalk is virtually dead for a reason.
I have sympathy with the view that OOP is often misused in modern languages and programming projects. That said, OOP is here to stay and I strongly believe that programmers can make much better use of it (and write better code) if they understand the ideas at the heart of Smalltalk.
I think this is judgement before try. If you'd understand a simplicity of Smalltalk object model, or if you could understand the essence of message sending together with using blocks (kinda anonymous functions, or closures), you would find as a secret ingredience. Smalltalk doesn't need often any documentation, because system is immersive, you could look at every aspect/detail of entire system, even how the message sending or method compilation is implemented), community refers to this as "turtles all the ways down". Smalltalk is definitely not mainstream, but not for a bad design, but because of history and greed of authors of commercial implementations. There are modern implementations like Pharo, which is MIT licenced and used for serious purpose.
SmallTalk may be dead but it is the ancestor of everything that followed…
@@LearnWithHuw One can't write good code in OOP. Why? Because most requirements do not follow the OOP pattern. A rare exception are graphical interface widget libraries. They fit OOP reasonably well. Beyond that the use of OOP mostly produces bloat- and painware. My suggestion: if you don't understand what you are doing when you use OOP, then don't use it. It won't help you to become a better programmer. At most you will become a one trick pony.
@@lepidoptera9337 I disagree. While I've seen a lot of toe-curlingly bad OOP code, the core ideas in Smalltalk (and ignored by many modern OOP languages) are extremely powerful. Which is what this series of videos is all about. :-)
Amazing when one thinks that this is a 40 year old technology! Seems to me that NextStep and everyone else has copied them …
I still find Smalltalk to be an inspirational language. Many programming languages "do the job" well enough but don't have the conceptual elegance of Smalltalk.
OOP originated in the 1950s and 1960s. It's at least 60 years old. It's also still as useless as on the first day. ;-)
@@lepidoptera9337Bold opinion why'd you think that?
@@freindimania11 When they developed the origins of OOP in the late 1950s and early 1960s machines had very little memory. Saving a few bits and words by reusing code seemed like a good idea. Ideally one would want to automate that code reuse, so we have to tell the compiler when such reuse is possible. That's where inheritance comes into play. If a class doesn't override the implementation of the function of the parent, then the code of the parent can be reused. Instead of having two copies of the same function in memory there is only one copy.
The downside is that now we have "hardcoded" this "simplification" into the structure of the program with the granularity of a whole function. If a child class wants to change just one line of 100 of a parent's class member function we now have to "fork" that entire function... which has disastrous consequences for debugging: bug fixes in either the parent of the child class members do not automatically percolate from one to the other! What looked like a good idea first becomes a nightmare in practice.
The savings in memory are absolutely marginal on a modern machine that may have 16GB of memory in addition... so the original reason to do this has long disappeared. But since people have forgotten about the original reason a long time ago, they are not even aware why they are doing this bullshit to begin with. ;-)
Yes, OOP is not about object, it's about message passing and message passing sucks.
This kinda sounds like what we would call actors now.
Yeah, it’s the same idea, though some (possibly many) actor frameworks prevent you from directly messaging an actor, instead forcing you to go through a manager (or similar) object.
The most important thing about it is that it's a form of documentation. If you don't understand why it is that, then you need to take CS101 again. You were clearly not paying attention the first time around. ;-)
I will never for the life of me understand why so many people try to make rules for coding lol. So many videos on this is how you should use this, use this principle, do this, don't do that, you are using it wrong. Imo if you do something and it works then it works. Is there a better way of doing something. Probably, there always is. But just get the job done.
Would you feel the same way about other engineering? For example, would you trust a mechanic working on your car if he simply wanted to get the job done? FWIW, I feel like I should be more like you! I tend to obsess a little too much about this stuff, when in reality, much of it is subjective, and can be dogmatic.
A good language will impose the right limitations upon you automatically; if you don't have that luxury you have to impose the limitations upon yourself. It might seem a pain to have everything immutable, but it's far less a pain than having to deal with shared state in a multi-threading context and trying figure out which thread last changed said state. Global variables might seem quick, easy and convenient to add and reference where their values are needed but you'll thank yourself later if you have to debug the code and can instead trace where the value came from using a breakpoint and the call stack. Copying & pasting code then changing some of the behaviour in the copy might 'get it working' but now if you want to modify the common behaviour you have to remember to update it in two places instead of one.
If you're writing a one-time-run throw-away script to, for example, update some data in a database, I can understand it not having to be the cleanest, most maintainable code - since it will never get used again. If you're writing code getting used and maybe even distributed to multiple customers which, even worse, may not be able to be changed once it's released (e.g. if it's written on a microchip) you'll 100% want to make sure you've not created a maintenance nightmare down the line for someone (unless of course that was your intent! :-D).
It's kinda cute, but smalltalk really is just a toy for bored programmers.
Well, up to a point...😏
funny guy, trying to define history to match his ideas, as do all the other funny people.
Me? Funny? Not intentionally but I take it as a compliment. ☺