Hey everyone and welcome to Developer Tea, my name is Jonathan Cutrell, and today I'm going to be talking about passing messages to your programs. Today's episode is brought to you of course by SPEC.FM. SPEC is the network that I teamed up with the guys from Design Details, another great podcast. We created SPEC, and it is constantly being updated with new content. In fact, Bryn Jackson from Design Details started a new show. It's similar to Developer Teain some ways. It's a short show, but it's focused on answering your questions. You can send them questions in Slack or on Twitter. Bryn started this with Sam Sofis. Sorry Sam, if I'm getting that slightly off. But check it out, it's SPEC.FM. Of course, the show will be on SPEC.FM along with Developer Tea and Design Details. So go and check out all of those things. 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 OVD Grim. OVD 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 canonical wisdom in object oriented programming practices. But in fact, as OVD 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, OVD referenced a quote or a few quotes rather from Alan Kay. 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 OVD 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, OVD 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. Moderating your messages in a more controlled way is going to give you more dependable code. Of course there's an entire theory that goes a little bit deeper than what I'm 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're 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. Perhaps 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. 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. I think you're going to have an enlightenment moment just like I did when I listened to Ovidis 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. I hope that you're 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.