Let's do a quick thought experiment. If you started programming today for the very first time and nobody told you what a variable was, would you be able to very easily tell the difference between a variable and a method? This is something we're talking about in today's episode. Today's episode is actually a re-airing of a previous episode, the messaging paradigm, this episode first aired back in September of 2015 and we're re-earing it today, partially quite honestly to give me a little bit of a break. In the last episode we talked about my son being born, this kind of an off topic episode for Developer Tea, but my son was due to be born on the 28th, he actually turned out to be born on the 13th, he was a little bit early, and so we're taking a little bit of time to do a few re-eared episodes, take a few episodes off. But this episode is just as relevant today as it was back in 2015 and it will continue to be relevant for the foreseeable future because I really want you to grasp this idea of message-oriented programming. In fact, Alan Kay talks quite a bit about message-oriented programming, maybe in different terms, but the original concept, the original driving idea behind object-oriented programming was in fact this message-oriented sending and receiving, responding to messages between multiple, a network of small objects. So I hope you enjoyed today's episode, I hope you enjoy the other re-eared episodes that we have in the near future. Thank you so much for listening to Developer Tea. Of course, keep in mind as you're listening to this episode that because it is a re-ear, some of the stuff we say may be a little bit out of date or maybe things that you know already or may reference sites or something like that that have been since taken down. So keep that in mind as you're listening, but hopefully you enjoy this episode about the messaging paradigm. So now I want to jump into the topic for today's episode and that is quite simply a message passing. Over this past weekend, I had the joy of meeting Avd Grim, Avd came down to speak to the Chattanooga Ruby meetup and he talked about object-oriented principles that he had to unlearn after years of working in the industry. He had gained some bad habits and a lot of these are passed on as kind of canonical wisdom in object-oriented programming practices, but in fact, as Avd points out in his talk, and also as you would probably find if you dug a little bit deeper, some of these things are not correct. At the beginning of his talk, Avd referenced a quote or a few quotes rather from Alan K. Alan is a computer scientist who created this small talk language, which a lot of people considered to be one of the most pure forms of object-oriented programming. And Alan actually said, and this is one of the quotes that Avd shared, I thought of objects being like biological cells and or individual computers on a network, only able to communicate with messages. Alan said this in an email, somebody was asking him a few questions back in 2003 about what object-oriented programming actually meant to him. Of course, I'll include a link in the show notes to a transcription of the email itself, but in this email, Alan goes on to explain kind of what he means by object-oriented programming. There's a lot of other really interesting quotes that you can find in this email, by the way. For example, Avd points out another quote that was in this email, specifically the quote says, I wanted to get rid of data. So the entire email is certainly worth reading, but I want to focus on this idea of passing messages or considering our programs as these biological cells or these things that can pass and receive messages. A common mistake that young programmers make when they first start out is confusing methods with variables, and perhaps this is informed by some kind of intuition. In fact, in many ways, in many different languages, variables are very much so quite similar to methods that are being called. So the challenge that I want to pose to you today is to start thinking about everything that you do in programming as a different message being passed to a different receiver. So let's return for a second to the example of the beginner programmer who is confused about the difference between a variable and a method. A variable in some ways holds some kind of information. It holds a reference to some kind of information. However, a method holds some kind of reference to some procedural information. And this is where things get interesting. When you want to access a method or when you want to access a variable, you send a message to something that interprets your request. Now for those of you who are experts on some kind of programming language theory that I don't have necessarily under my belt, follow the logic here with me because the semantics are going to be different in every scenario. But the same basic truth is underlying that any instruction that you give your program, whether that's setting a variable or creating a method or fetching a variable or perhaps calling a method that inside of that method, it modifies a variable. All of these things can be unified into a single concept of passing messages. Let's say for example, you set a variable in JavaScript, you set var, foo equals some kind of string. Well you are passing a message to whatever the current scope is in JavaScript to hold a variable in the reference of foo. And when you use foo, you are now sending a message to retrieve whatever is held in foo. Now why is this useful? Why is it useful to think about your programs in terms of passing messages? When you start to think about your program in terms of passing messages, then you start to create systems that pass these messages more efficiently and also systems that moderate the ways the messages are being passed and how they are actually parsed from one sender to one receiver. For example, any messages that live in the global space can be modified by other things that have access to the same space that those messages live in. This is a perfect justification for not using anything in the global space that you don't absolutely need. This is a good practice in any language. Operating your messages in a more controlled way is going to give you more dependable code. Of course there is an entire theory that goes a little bit deeper than what I am covering in today's episode with regards to object-oriented design and what those messages should look like what they should be concerned with. But the first step in understanding that design principle, specifically if you are coming from a background of either purely procedural programming like a lot of front-end developers who work only with JavaScript a lot of your thinking is probably based on that procedural thinking or perhaps your background is functional and you only think about things in terms of functions. The idea that your program can only communicate with itself through these messages is a powerful way of looking at programming and it's your job as the programmer to mediate these messages and respond to the messages in the proper ways. This more specifically it's your job as the programmer to determine who is sending the message and who should be receiving the message. When messages are combined with the single responsibility principle and other object-oriented design principles, the code that you write ends up becoming much easier to test. It ends up becoming much easier to maintain and in the end you're going to end up a better programmer. Now before the CS degree people in the audience get up in arms with me, I'm not trying to get you to redefine what a variable is and what a function reference is in your mind or to redefine what a method is in your classes or to redefine any of these things really other than the way you perceive them. Start thinking about things as messages. That may not be the semantic correct term but it certainly is a useful way of thinking about how you are programming, thinking about how you are setting things where you're setting them, how you're calling them, where you're calling them from, etc. So my challenge to you is quite simply to think about the messaging paradigm, the next time you're solving a programming issue, the next time you're solving a programming problem. Think about who is the actual messenger and who is supposed to receive the message and then also the things that are mediating that message as it is being sent. Think about whether or not that message should be authorized to be sent the way that it is. Each operation in your code, whether that's setting or defining a method or a variable or if it's calling a method, any of these things can be considered messages. And when you start thinking about the sender, the receiver and the mediators of those messages, I think you're going to see a brand new way of debugging your code, of building code that's more testable and I think you're going to have an enlightenment moment just like I did when I listen to obvious talk this weekend. Thank you so much for listening to today's episode of Developer Tea. I hope that these topics are stretching the way that you think and I hope they are helping you become a better programmer each and every day. Of course as always, I am open to hear your feedback. I would love to hear from you. You can reach out to me on Twitter at at Developer Tea. You can find me on Slack at spec.fm slash Slack. You'd have to sign up with your email and then you'll get an invite in your inbox just a few minutes after you sign up. You can come talk to me and the other people at spec.fm, including the guys from design details and immutable. I'd love to answer your questions about the topics of messaging or anything else that you're interested in talking about, whether that's your career paths or maybe specific programming language questions, anything that you guys want to talk about. I would love to discuss the things that aren't on your mind. Don't forget that if you don't want to miss out on any future episodes of Developer Tea, you should subscribe in whatever podcasting app you use. Thank you so much for listening to Developer Tea and until next time, enjoy your tea.