[00:00:00] SY: Okay, so we are all sold out of earlybird tickets to Codeland. But regular tickets are now available. They start at 99 bucks, and they get you talks, a workshop, great food, great people, all in New York City on July 22nd. Go to codelandconf.com for more info. Link is in your show notes.

[00:00:30] (Music) Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron, and today, we’re talking about interpreters and compilers.

[00:00:43] Okay. Let’s set the scene. You open your browser. Maybe it’s Firefox or Chrome. You right click and select Inspect or Inspect Element. You navigate to your console where you can now type some JavaScript, and you type in 2+1. That’s the number two, the plus sign, and the number one. Now if you do that, then press Enter, you’ll get the value 3, which makes sense because two plus one equals three. But how does the computer know that we wanted to add a two and a one? When we type that plus sign, how did it figure out that we are trying to do addition? Figuring out what we need and giving us an answer is the job of the interpreter or the compiler, depending on the language. Sometimes it’s both. But what exactly is an interpreter and how does it work? And what’s the difference between a compiler and an interpreter?

[00:01:38] TB: My name is Thorsten Ball. I’m a software developer from Germany working at ioki.

[00:01:44] SY: And he wrote the book on this topic. Actually, he wrote two books and he gives us an amazing introduction to the world of compilers and interpreters. We’ve also got our fourth episode of Tales from the Command Line coming up after this.

[00:02:03] As you know, I’m a podcaster, and I love talking to people and hearing their stories, and I love it so much I actually host another podcast called Command Line Heroes. It’s produced by Red Hat. And in that show, I get to talk to tons of people doing incredible work in open source. But besides awesome interviews, it’s also got sound effects, background music, you know, creative audio stuff. So if you’re looking for some more awesome tech podcasts to fill your feed, check out Command Line Heroes. Go to redhat.com/commandlineheroes. Link is in your show notes.

[00:02:39] If you’ve got a personal project, a small business, or a big business with lots of data, Linode offers you secure hosting for all your infrastructure needs. They are a Linux Cloud Hosting provider where you can get a new server up and running in under a minute. Plans start at one gigabytes of RAM for just five bucks a month. And with the promo code CodeNewbie2019, you can get a $20 credit. So go to linode.com/codenewbie and give it a try. Also, they’re hiring. Check out their jobs at linode.com/careers. Links are in your show notes.

[00:03:14] If you’re listening to this, you’re already on your way to changing your life through code. At Flatiron School, you might end up with a job, a promotion or a better salary. But that’s just the start of changing your career, your life, and the world. On campus or online, you’ll join a community of learners that are empowered to change their future in the rapidly growing tech field. A bold change begins with a single step. To take yours, go to flatironschool.com/codenewbie. Link is in your show notes.

[00:03:47] DigitalOcean provides the easiest cloud platform to deploy, manage, and scale applications of any size. They remove infrastructure friction and provide predictability so you can spend more time building what you love. Try DigitalOcean for free by going to DO.co/codenewbie and get $100 in infrastructure credit. Link is in your show notes.

[00:04:12] SY: That is very, very exciting and I’m very excited to talk to you because compilers and interpreters, to me, are these very scary words and things that, if I had a computer science degree, if I studied this stuff in school, I would probably be familiar with but as someone who transitioned into code a little bit later in life, I never had the chance to learn about these things. So you’re going to teach us all about it. I’m super excited to have you here.

[00:04:39] TB: Right. I’m also super excited to be here and talk about the stuff.

[00:04:43] SY: Wonderful. Okay. So let’s start with… actually, let me ask you. What is the easier thing to start with, compiler or interpreter?

[00:04:50] TB: There’s no easy answer to this, but I would say an interpreter because it’s easier to build.

[00:04:55] SY: Okay. Cool. So let’s talk about an interpreter. What is it?

[00:04:59] TB: All right. So maybe let’s step back for a second and think about the problem an interpreter or a compiler is solving.

[00:05:05] SY: Okay.

[00:05:05] TB: You know, the problem is a computer only understands a single language and that single language is the so-called machine code. You know, literally, the zeros and the ones, and…

[00:05:15] SY: Okay. So when we talk about zeros and ones, I know we talk and that’s called binary. When we talk about that, is that real, like really, computers actually…? Because it feels like this thing that, you know, this thing that we use to explain something complicated, but is that really true computers really only read zeros and ones?

[00:05:33] TB: I mean, yeah. It’s not like you could hook up a keyboard to it and type in zeros and ones, right?

[00:05:37] SY: Yeah, okay.

[00:05:38] TB: But in the end, they work on this…

[00:05:40] SY: I need some help.

[00:05:41] TB: Yeah. They actually do work with this machine code that you encode in binary and, you know, binary in the end is zeros and ones in a digital computer.

[00:05:50] SY: Wow. Okay.

[00:05:51] TB: That being said, I have to put a huge asterisk to, you know, my earlier sentence because CPUs nowadays or computers are so complex and so incredibly advanced that any statement I might do now today in this conversation comes with a lot of, you know, exceptions and, “Well, not actually,” and blah, blah, blah. So take a little grain of salt, like what I’m saying is like a simplified version of what’s going on under the hood.

[00:06:20] SY: Fair. Okay. So machine code, zeros and ones. Okay. How does that get us to the interpreter/compiler question?

[00:06:28] TB: Right. Yeah. So typing in zeros and ones even if we could do it would be bad, right? Because it’s not expressive, you know, your fingers get tired probably. So what we need is, you know, a better language to talk to the computer so we can express ourselves better and solve problems better. And in order to do that, what you do is you implement the language. That means you build the program out of, or in the language the computer already understands, and this program makes the computer understand this new language you wanted to understand. And this program can either be an interpreter or a compiler. What they both do is they make the computer understand the language it couldn’t understand before, but how they do it, that’s the difference.

[00:07:14] And an interpreter, what it does is it reads in the language, you know, you want the computer to understand and it executes it on the computer. And just think of a simple example where you read in user input in any program. Let’s say you have a website and you have like a text input field and the user should enter Yes or No. And I’m simplifying here, but if you take the input of this text input and you have in your program like an “if statement” that says, “If user input is, ‘Yes,’ then do this, or if user input is, ‘No,’ then do that.” That’s an interpreter. You’re interpreting the thing the user put into the computer, right? And it’s the same thing with programming language except of course many more features than yes and no and, you know, other deeper integration into the existing languages. But the basic idea is that you take input that is a language and you interpret it by doing what the language is supposed to do.

[00:08:21] Let’s take another example. Let’s say you want to invent your own programming language that only has one possible statement and that possible statement is “Print Hello World,” like one word together, no spaces, “PrintHelloWorld.” If you feed this in any way through a computer, nobody is going to print Hello World on any screen. Nothing is going to happen. The computer will maybe stop or would go off it. But if you build an interpreter, you can actually make the computer print Hello World, and the interpreter, all it would need to do is it would need to read your input from a file or your keyboard and then check like if the thing I just read in is “Print Hello World,” then I’m going to print Hello World, because the interpreter itself is built in a language the computer already understands.

[00:09:11] SY: Interesting. So I mean, it is literally -- it is what it says it is. It is interpreting…

[00:09:15] TB: Right, yes, yes.

[00:09:16] SY: …my input. And it’s interesting what you said because the fact that we have an interpreter isn’t really for the computer’s benefit. You know, if I could just type machine code all day, then the computer would be fine with that. It sounds like the computer doesn’t really care, but it sounds like we build interpreters for us because we don’t want to write machine codes all day because it’s not really fun. And when we think about the example you just gave, “Print Hello World,” if you know English, then that makes sense to you, right? I’m going to print something that says Hello World onto it. It feels very intuitive and very natural, but we need something to help us take what feels normal and understandable to us and make it understandable to the computer. So it sounds like the interpreter is interpreting, interpreting that for us.

[00:10:02] TB: Exactly that, yeah.

[00:10:03] SY: Okay. Well, that doesn’t sound so scary.

[00:10:05] TB: No. Actually, it’s…

[00:10:07] SY: That sounds pretty cool.

[00:10:08] TB: Yeah, and it’s not scary, it’s amazing. Interpreters and compilers, they’re amazing things because in my opinion, they make something out of nothing, you know. The computer couldn’t understand the language at first, but now it can and now you can do other things in the language you just implemented in another language.

[00:10:26] SY: Okay. So if I am writing, “Print Hello World,” if I’m writing that in JavaScript…

[00:10:34] TB: Right.

[00:10:35] SY: JavaScript is the programming language. So where’s the interpreter for that?

[00:10:40] TB: This question tripped me up the most in the beginning when I started out programming because I couldn’t fathom the idea that somebody writes, “Download the programming language.” You know, these are instructions like, “In order to run this piece of code, you need to download Ruby or Python.” But in the end, programming language is either an interpreter or a compiler. To build a programming language, you have to implement an interpreter or a compiler, right? These are how you get the computer to understand it and otherwise the programming language is just an idea.

[00:11:13] And if we’re talking about JavaScript, your browser has the JavaScript interpreter built in. So if you’re opening a website that has some JavaScript in it, what the browser actually does is it scans your HTML for the JavaScript, it takes the JavaScript and feeds it to its own interpreter because the computer again doesn’t understand JavaScript. So the interpreter has to translate it for the computer. And the interpreter says like, “If the JavaScript code contains the line console lock Hello World, I’m going to print the string Hello World into my developer console.” You know, it’s the same thing again except that JavaScript has many more features than this.

[00:11:56] SY: Interesting. Okay. So in that example where I have JavaScript in my browser, is the interpreter part of the browser or is it part of the language? Where does it live?

[00:12:11] TB: The language itself is an idea.

[00:12:3] SY: Uh-hmm.

[00:12:14] TB: So you could say your new language is called fubar and it only has two commands. It has fu and it has bar. And fu means print “Hello World” to the screen, and bar means print “Good luck everybody” to the screen. Or something like that. Two commands, right? But it doesn’t have yet an implementation. Nobody can run programs written in fubar yet because it’s a fictional language that doesn’t exist. It’s not implemented. The computer needs an implementation that allows it to understand and speak in this language. And JavaScript is an idea, it’s a language and it’s implemented in different browsers. That’s also why you have differences in implementations that something runs in Chrome and something runs only in Firefox and stuff like this. Each of these browsers has their own implementation of JavaScript. They’re all trying to implement this idea of JavaScript, the specification, ECMAScript.

[00:13:14] SY: Yeah. Very cool. Okay. So if I compare this to a human language, what I’m hearing you say is… you know, for example, I’m Ethiopian, I speak Amharic, it’s one of our main languages, and that language in and of itself exists. It has its own rules, its own grammar. It knows who it is but for someone else who doesn’t speak that language to understand what I’m saying, we need a translator. We need someone to say, “Okay, this means this and that means that.” And so that person, that thing that says, you know, “Let’s take these rules and let’s make sense of it for the person who doesn’t speak that language,” that’s what the browser is doing with JavaScript?

[00:13:55] TB: Exactly. That’s exactly it. So in human languages, you have the concept of a dead language, a language nobody speaks, right?

[00:14:03] SY: Right. Right.

[00:14:04] TB: So if you make up your new programming language that is not implemented anywhere, then it’s a dead language because nobody understands it.

[00:14:12] SY: Same thing.

[00:14:13] TB: But you can write an interpreter for your new language and teach your computer by implementing this interpreter to understand this language, and then you can, you know, execute it and run it. Yeah.

[00:14:25] SY: So technically, with JavaScript, because JavaScript is a language, I could write my own browser and have its own little interpreter to interpret the language?

[00:14:35] TB: Exactly. Yeah, exactly. Yeah. You could write your own browser and say, “Not only understands JavaScript, but it understands JavaScript++,” whatever. And you can extend its version of JavaScript and now it speaks more JavaScript.

[00:14:51] SY: Wow. Fascinating!

[00:15442] TB: You know, in some READMEs or instruction manuals, you have like at the bottom the thing like, “In order to run this application, you need to download Java,” which is nothing more than downloading the interpreter/compiler that makes the computer understand Java because without it, the computer wouldn’t know what to do with files ending in .Java because they contain Java code and all the computer understands is the machine code.

[00:15:18] SY: Very interesting. Okay. So you mentioned compiler. So now I want to know, what is a compiler? How does it compare?

[00:15:25] TB: So you get me the perfect setup. Let’s say a friend of ours does not speak English, right?

[00:15:31] SY: Uh-hmm.

[00:15:31] TB: But the two of us, we speak English, and he only speaks German. So what I could do is I could translate for him on the fly and act as an interpreter, just like you described. So the two of us…

[00:15:42] SY: In real time?

[00:15:42] TB: Yeah, in real time. We are talking in English and after each sentence, I pause, I translate in my head and I tell him the German version of what we just said. Now, that’s interpreting. You know, this is on the fly. I do not stop or produce anything. A compiler, on the other hand, in this context, would be me listening to us talking in English or just listening to you talking in English and writing the German translation down. Instead of going to my friend directly after every sentence, I write the translation down. So I’m giving him the piece of paper so he can read the thing. Now, let’s translate this to programming languages. If you type in JavaScript in your browser, it executes immediately. There is no step in between where you have to push another button or something. A compiler, in classic languages like C or Go, for example, it takes in the programming code and it translates it to a language the computer already understands, for example, the machine code we mentioned earlier, and it produces a file called an executable most of the time in this machine language. So it translates the program you feed it into another language and produces a file that contains instructions the computer can understand. And later on, you can execute this file which the computer can now execute because it’s in the computer’s language and it can execute what you said in the other language. So it’s translating but with the step in between where you write stuff down and you can pause, you know. This is a big upside, but also a big downside of compilers, but you pause between the compilation step and when you actually run your program.

[00:17:34] SY: So when I think about inserting a pause, it feels like an extra step that I don’t know why I would want that because wouldn’t I want to get that program running as fast as possible in real time? What’s the point or what’s the benefit of stopping first to compile it?

[00:17:51] TB: That’s a pretty good question because there are huge downsides to this approach. You have to wait, right? And then you also have to execute it again. This is obviously a downside because most of the time, you want your programs to run as fast as possible.

[00:18:05] SY: Yeah.

[00:18:06] TB: But let’s say you want your compiler to also be smart and look at your program really closely and analyze it and find out which stuff it can get rid of. In an interpreter, the interpreter has to go through all of this stuff every time it executes a program. A compiler, on the other hand, can look at the program and go, “Look, this function is unused. It’s not called anywhere in the rest of the code. I can just get rid of it.” And what happens is that the translated code gets smaller and it also gets faster because the compiler can also optimize your code. And these are called compiler optimizations. And let’s transfer this upside back to an interpreter. If you’re running your code in the browser, you want to execute it as fast as possible. This is what we just said. And if we do these optimizations in between, that means there’s a little pause between us typing in the code and the computer actually executing it. But with the compiler, your approach is different. What you do is you write your code, you compile it, but you know that you compile it, it gets fast, it gets optimized and then later on at another time, you’re going to execute it. And you know, there’s also this whole topic of distributing your programs. With the compiler, you can basically compile your code to a single binary and then, you know, weeks, months later, you can copy this binary to another computer and then execute it. And you do not have to copy all of the source code and copy to another computer. You can just copy the binary.

[00:19:37] SY: Oh, interesting.

[00:19:38] TB: It’s still the same thing and another computer can understand it. So let’s say your computer understands your fubar language, right?

[00:19:46] SY: Uh-hmm.

[00:19:46] TB: We build a compiler for fubar and it produces machine code that does the thing fubar is supposed to do, like it has the fu and the bar command, and we can compile it to a binary and now it’s in the language a computer understands. That means we can copy it to a computer that has no implementation of fubar that never heard of the thing called fubar and it can execute it.

[00:20:10] SY: Yeah. Oh, it sounds really convenient. It kind of feels like, you know, short-term planning versus long-term planning, I guess. You know, you take up a little bit more in the future than you compile it first, make sure everything is good, and then you can ship it off to wherever it needs to go and not have to give it more stuff and know that it’s always going to work no matter… as long as you it’s on a computer, you know?

[00:20:33] TB: Exactly. You know, the old wisdom was basically that the code produced by compiler, the translated version, is much faster to execute than interpreting it because as I said when you interpret code, you have to interpret it all the time, like you have to look at it again and again and again. And with the compiler, you just do it once and then you can execute it.

[00:20:56] SY: Yeah.

[00:20:56] TB: So there’s a speed there, but I have to add that both approaches have their upsides and their downsides, and nowadays, it gets even fuzzier like what’s the better approach. There is no really clear answer to this anymore because programming languages are so advanced by now that, you know, you can’t really tell the difference between interpreter and a compiler anymore.

[00:21:18] SY: I was wondering that. Yeah. I was wondering, if my machine or the thing that’s interpreting it is really, really, really fast, would I be able to tell the difference if it was, you know, using an interpreter or a compiler?

[00:21:30] TB: I don’t want to confuse anybody, but I’m just going to say that the example of JavaScript was glossing over a lot of details because if you write JavaScript into your browser, there is actually not a single JavaScript interpreter, there are usually three or four of them. And there’s also a JavaScript compiler and they do different things.

[00:21:52] SY: Wow.

[00:21:53] TB: Yeah. The first interpreter executes your thing, like it prints “Hello World.” The second one analyzes it and you know, like, “Can we get this faster?” And the third one says, “You know what? I’m just going to compile this to a machine code in case you later need this again, and then we have the fast version of this.”

[00:22:09] SY: Interesting.

[00:22:10] TB: And then you have another compiler that looks at the compiled machine code version and goes, “I can make this even faster.” So if you have any time, I would look at those again and make it even faster. And then if you execute it a thousand times, we have the fastest version possible.

[00:22:23] SY: Whoa!

[00:22:24] TB: If you look at the diagrams of famous or the Chrome or Safari or Firefox JavaScript implementations, there’s a lot of arrows and like little circles where like your code starts here and it ends up there, and in the middle, it goes between here and there and there and there. It’s crazy. The amount of engineering that goes into a modern programming language implementation is staggering. It’s truly mind-bending.

[00:22:49] SY: Yeah. So that sounds… well, first of all, I’m shocked and flattered at how much help that I have.

[00:22:57] TB:  Yeah, yeah. There’s tons of help.

[00:22:58] SY: I had no idea that I had all these helpful things just, you know, running around in the background, making it easier for me. Thank you. Thank you, browsers.

[00:23:04] TB: Yeah.

[00:23:04] SY: But the other thing I’m wondering is why do we need all those interpreters and compilers? Can’t just one of them do the job? Why do we need five different tools, especially with it’s something as simple as, you know, print Hello World which seems like, at least to me, not very complicated? Why do we need so much help?

[00:23:23] TB: Yeah. So this is where people come into play because theoretically all we need is a single programming language, right?

[00:23:32] SY: Right. Yeah.

[00:23:33] TB: If the computer understands this, we would be fine. We could implement everything we want in this programming language. But we also know that we prefer some languages over other languages because, you know, some languages have different ideas baked into them. And different programming languages are good at different things because they were built for these different things. And in the end, it’s not about as you very well put it at the beginning. It’s not about what the computer understands, it’s about what we, as programmers, want to use and how we can use it. But there’s also, you know, this other side of which computer understands what because different computers understand different ones and zeros. And now, the challenge is, “Do I have to write my programs in each of these languages?” No, you could just write another computer language that compiles to each of these languages. You know, now you have a third language and it all goes from there.

[00:24:35] SY: Interesting. Yeah.

[00:24:36] TB: And the same thing happens with browsers, you know. You have different browsers and they want to implement JavaScript but each of them wants to implement it in a different way and you want to use a different browser. So this is what happens, basically. We could, theoretically, use one language but we do not want that. We want, actually, to have more languages at our disposal that are better at different things and allow us to express ourselves more easy, you know, with better ability to do the things we want to do.

[00:25:05] SY: So when we think about the differences and let’s just go with the JavaScript example, having different browsers who implement JavaScript differently. What are some of those differences? Are they things that as a developer I would care about or need to pay attention to?

[00:25:22] TB: Well, yes and no.

[00:25:25] SY: Okay.

[00:25:26] TB: So no as in different browsers implement JavaScript under the hood in different ways, and you won’t notice that as a programmer. Safari, for example, does HTML DOM element rendering triggered by JavaScript in a different way than Chrome does it, for example. You do not need to worry about that in most of the cases except you’re, you know, optimizing for performance. But you need to worry about it as soon as they start extending the implementation of JavaScript. So you probably heard of, you know, new ECMAScript versions like ES6 or ES7. You know, these are new versions or specifications, new ideas of what JavaScript could look like and then different browsers started to implement this in their own JavaScript interpreters. That means they extended the interpreter and said as before as in my example where you interpret the user input like if the user input is yes or no, they do the same thing. They go, “All right, this is a new thing we want to implement, so now we’re going to accept input where the function literal does not start with the function keyword but it starts with parenthesis and a fat arrow.” And we’re going to extend our interpreter, so it says like, “If there is a fat arrow, this is a probably a function.” And different browsers start implementing this at different times, you know. There’s tables on the internet where you can look up, you know, which browser has implemented which of these new JavaScript features and they’re trying to catch up all the time. And I think ECMAScript 6, for example, it took a long time from specification as in ideas were formulated and agreed upon to, you could use it in every browser. And this is when you need to worry about the actual implementation because they might differ in which version of JavaScript they’re offering.

[00:27:21] SY: And as far as the ECMAScript, do I need to know what that is? Is that basically like super JavaScript or, you know? Because I’m just trying to get a handle on JavaScript. Do I need to know all this other stuff too?

[00:27:33] TB: I’m getting into the deep water here because I myself am not that familiar with the ECMAScript process, but ECMAScript is the idea of the language. It’s the official definition of how JavaScript or ECMAScript, in this case, is supposed to work. It says, “If the user types in console.lock and then a string, print the string to your screen.” This is what it says in the ECMAScript definition. Now, JavaScript is an implementation, a realization of this idea. By implementing the specification, you made this language a real thing that users can use now and JavaScript is the real thing to the language specification called ECMAScript. Does that make sense?

[00:28:14] SY: Yeah. Yeah. Because we talked about kind of the separation between the language itself and then this idea of an interpreter/compiler and it sounds like even one language might have a couple interpreters and a couple compilers.

[00:28:37] TB: Yeah. Yeah.

[00:28:39] SY: Do I, as the developer, when I pick my programming language, do I also separately get to pick my interpreter and/or compiler or do they kind of come in sets? Right? So if I do JavaScript, it comes with these, you know, it comes with the browser and the browser decides it for me, or do I get to mix and match, or do I even want the ability to kind of mix and match how my language, my programming language gets interpreted or compiled?

[00:29:09] TB: Yeah, you do have choices, not for all the languages but for some. So, you know, there’s different implementations of the same language. As we just said, like the different browsers implement a different version of JavaScript. And you could very well say, “I am only going to write my code for the JavaScript implementation in Chrome.” In other languages, you sometimes have the same choice. For example, Ruby. Ruby has different implementations. One implementation, Matz’s Ruby Implementation, MRI, itself written in C. The Ruby implementation is in C, and that’s one way to run your Ruby programs. You download this implementation of Ruby and then you feed it your Ruby programs and it executes it, but there’s a different implementation of Ruby called JRuby. And this is not implemented in C, but it’s implemented in Java. Ideally, it gives you the same set of features inside Ruby, but it might execute faster or it might execute on more computers because the host language, this is what we call the language that implements another language, is different. In the JRuby implementation, the host language is Java, and in MRI, the host language is C. Now, C is the language that has to be compiled and it has to have a compiler that runs on different computers. So you have to have a compiler that, you know, runs on a Linux computer, it has to have a compiler that runs on a Mac and so on. One of the big advantages of Java is that it runs on a lot of different platforms and it’s really fast and it’s optimized and it has great tooling that comes with it like debugging support and profiling support, stuff like this. So if you worry about this stuff like debugging or profiling, then you might have more features at your disposal if you choose JRuby.

[00:31:59] SY: Yeah.

[00:32:00] TB: Different implementations might come with different let’s say additional features or the downside, different baggage, you know. (Music)

[00:31:08] SY: Coming up next, we talk about the benefits of learning how a programming language gets implemented under the hood, how Thorsten learned about these topics himself, and what it was like to write books about them after this.

[00:31:23] We’ve talked about open source a bunch of times on this podcast, but frankly, open source is so big and complex and fascinating that it needs its own show, and it has one. It’s called Command Line Heroes. It’s produced by Red Hat and it’s hosted by me. That’s right. I’ve got another tech podcast talking to incredible people about all things open source. We talk about the history of open source, the introduction of DevOps and then DevSecOps, and we even do an interview with the CTO of NASA. And that’s just the beginning. We also dig into cloud and serverless and big data and all those important tech terms you’ve heard of, and we get to explore. If you’re looking for more tech stories to listen to, check it out at redhat.com/commandlineheroes. Link is in your show notes.

[00:32:13] DigitalOcean is the easiest way to deploy, manage, and scale your application. Everything about it was built with simplicity at the forefront: setting, deploying, even billing. Their support is amazing. They’ve got hundreds of detailed documents and tutorials. So if it’s your first time deploying an app, they’ve got great tools and community to make it nice and easy. Try DigitalOcean for free by going to DO.co/codenewbie and get $100 in infrastructure credit. Link is in your show notes.

[00:32:45] Ready to change your life? Well, Flatiron School designed a school just for you. Flatiron is a global school with immersive and online courses designed for passionate people like you. If you’re looking to excel in a new, rewarding career, you can start right now. Check out Flatiron School’s free 75-hour boot camp prep, where you can learn JavaScript, Ruby, and do some interview prep. Flatiron School has helped thousands of students from all backgrounds invest in themselves by learning online or in person. By the way, did you know that they’re now part of WeWork, which means they now offer classes at a growing number of WeWork locations around the world. So go to flatironschool.com/codenewbie to learn more. Link is in your show notes.

[00:33:36] Linode is giving you a chance to try their powerful servers built for all your infrastructure needs. They’ve got nine data centers worldwide with new data centers opening up this year in India and Canada. Getting started with a shiny new server takes less than one minute, so you can get up and running in no time. And you can get a $20 credit by using the promo code CodeNewbie2019. Just go to linode.com/codenewbie for more info. Link is in your show notes.

[00:34:06] SY: Tales from the Command Line, it gives us a chance to dig into one particular part of the episode and hear a different perspective from a really experienced developer in the field, Scott McCarty.

[00:34:17] SM: Yeah. My name is Scott McCarty. I am a Principal Product Manager and I focus on containers, like all the technology within containers that enables Red Hat Enterprise Linux and OpenShift.

[00:34:30] SY: Let’s begin. So compilers, what is your experience working with compilers? Is that something you did when you were in school in college?

[00:34:40] SM: Well, it was something I was supposed to do, but I hit a wall at Analytic Geometry and Calculus II and Compiler Design or Compiler Design class, like those two really smacked me hard.

[00:34:56] SY: It sounds intense.

[00:34:57] SM: They are super intense.

[00:34:58] SY: Yeah.

[00:34:59] SM: They’re the reason why I ended up getting a minor in computer science instead of a major.

[00:35:02] SY: Interesting. Wow!

[00:35:04] SM: Yeah. I ended up with a Major in Anthropology and a Minor in Computer Science because of that. Compiler Design is complex and painful and we had this professor named [Dr. Margish], which was teaching the class, and he was super, super intense, like I don’t even know how to explain. His rules were the first day of class, he would show up, he’d be like, “All right, you have five projects this semester. If any of them don’t work a hundred percent correctly, you fail.”

[00:35:31] SY: Oh, wow! Oh my goodness!

[00:35:34] SM: “I’m going to run like thousands and thousands of pieces of data through these programs,” or maybe even a million, whatever. He’s like, “And if any of the results are wrong, you fail.” And I was like, “Okay. That’s painful.” He’s like, “If it works correctly, it’s a C-.” And he’s like, “If it works correctly and it’s designed elegantly and it’s documented well, you can get an A.” And he was not joking. So he was famous for failing--

[00:36:01] SY: That is intense.

[00:36:02] SM: --an entire class of people. He failed 30 people.

[00:36:06] SY: Is that allowed?

[00:36:08] SM: It apparently is when you’re Dr. [Margish]. So he failed my friend Chad, the guy that got me into Linux. He failed the entire class, and my friend Matt. Two of my good friends, you know, failed that class because he failed everyone. He was like, “This class isn’t good enough. I’m failing everyone.” And that was it. He just failed the whole class. So I took him later for computer architecture where we actually designed -- we literally used an electronics package to design a microchip. We designed a memory unit, we designed the accumulator, we designed the ALU, we designed the control store, and all these are like low level pieces of a CPU that like most people will never learn about. But like we put it all together and you could see it running. It had its own clock and you could see all the wires laid up as essentially the electrical signals are coming across and you could add numbers, you could multiply, divide, you could subtract, and like we basically built an arithmetic logic unit that would do all the math. And then we had to to hand assemble, you know, a Fibonacci sequence into binary and make this program run on the CPU we made. And you literally, the first day of the class is like, “I think we’re going to build a CPU and an electronics package.”

[00:37:15] SY: No big deal.

[00:37:16] SM: And I was like, “That doesn’t sound like a good idea, like this sounds like a very dangerous idea.” He’s like, “No, I think we can make it work.” I must have worked like… oh my gosh! I worked so many hours that semester. And that was his computer organization class, but like his compiler design class, I dropped out, like I just couldn’t do it. He’s like, “We’re going to build blah, blah, blah.” I remember the first day he had, he had a… he had written randomly in Visual Basic essentially a virtual machine. So he had written a virtual machine in Visual Basic that you can inspect and then we are going to write a compiler and an assembler for this virtual machine that he’d written in Visual Basic. And you could see all the registers, and you could see what was happening, and it was insane. And I was like, “This is too much.”

[00:37:57] SY: Okay. I understand why that major didn’t happen and that minor did it instead. That makes a lot of sense.

[00:38:05] SM: Yeah. It was terrifying.

[00:38:07] SY: I actually find that very validating because I think that, especially for those of us who didn’t major or minor in computer science and didn’t study it in college, we have like a ton of insecurities about a lot of things that we don’t know. So it’s actually reassuring that you have been in tech, have a very successful career at a huge respected company like Red Hat, you’ve been doing this for over 20 years, and you have worked, you know, with and used compilers but you didn’t take a class and you haven’t designed one. So thank you.

[00:38:38] SM: Yeah, absolutely.

[00:38:40] SY: Have you ever felt, at any point in your career, like those classes that you ended up not doing has affected your ability to do a project or… yeah, in any other way, affected your job or your career?

[00:38:57] SM: So that’s an interesting question. I think I would answer that in two ways like, has it ever had a direct effect or has it ever had an indirect effect? I would say from a direct effect perspective, it’s never had an impact. It’s like there’s never been… they’re like, “Scott, we need you to write a compiler. And by the way, we need it by next week.” And I was like, “Oh my gosh.”

[00:39:16] SY: Yeah.

[00:39:16] SM: That’s never happened. Indirectly, I think it can definitely affect you in that, like you have a little bit of an insecurity about it, like that is real. And I admit, many engineers don’t want to talk about it. This is the first time in my career that this has really become a thing where people talk about it. These emotions affect your ability to perform things and engineers like to deny that they have emotions, but we do absolutely have emotions and we absolutely make most of our choices based on emotion and then we justify them with logic. So people will avoid, I see it all the time, they’ll avoid very technical like libraries. They don’t want to learn it. They’re like, “Oh, that library is too hard.” And so they’ll make up again these value propositions in their mind. They’ll say, “Oh well, that’s too hard, so it’s not worth learning.” And you’re like, “Eh!”

[00:40:01] SY: Yeah. And I think for a lot of folks in our community, the big question is, is the investment going to be worth it, especially when we can’t quantify the way things are being affected, right? So it’s one thing to do a string of interviews for, you know, companies you want to work for and have them all say, “No computer science degree, no job.” Right? Like that’s very quantifiable. But when we are still technically getting those interviews and those jobs, we still feel like, “Ah, I think I’m kind of like missing. I’m missing something, I’m missing some knowledge. Should I go back to school? Should I do an evening class or should I just kind of like power through that emotion and eventually it’ll leave me alone?” That’s when it gets hard to figure out if it’s time to make an investment or to just kind of ignore that feeling and hope it goes away. How do you think about that? How do you think about that decision?

[00:40:52] SM: So I’ll answer this in that I grew up in an area that was very economically depressed. I grew up with a single mom, a sister. I mean, we were very poor growing up. I mean, on government assistance. I mean like all the things. And I grew up with a lot of people that, you know, alongside a lot of people that had these exact same problems. And so there’s kind of two ways I look at it, right? Like two of my smartest friends never got a degree at all and they honestly probably make more money than I do. One of my friends definitely does. In a nutshell, they’ve done very well for themselves. I think, though, that then I see a lot of other people that like struggle to find traction, and even some of them that are very smart, like smart is not the bottleneck. Sometimes knowledge is not the bottleneck, either sometimes confidence is. Sometimes just putting in hard work is the bottleneck. I have one friend, in particular, that has kind off and on been in tech and has gotten some traction but not quite gotten as much traction as I would expect for how smart he is. And I see him struggle with it and I try to give him advice. One time I said, “Get your Red Hat Certification. Just do that. Because not that that, in particular, might be the thing that differentiates you that gets you a job but the fact that you forced yourself to do it even though you don’t want to will change you in a way that will then enable you to do other things.”

[00:42:13] I don’t like to beat up on people and say that they’re not trying hard enough. That’s not quite the right way, but like you’ve got to believe, you’ve got to find hope and believe that you can, like do things past the summit of the mountain, right? Like you’ve got to look at the summit and then realize, “Okay, I can get to that thing if I take baby steps and it’s about mindset.” It’s not always about intellect. It’s not always about how much you know. A lot of it is just making sure you really have the right mindset. You know, if a company doesn’t offer you a job, ask why. I interviewed at Google many times, like three… I think on the third time that I interviewed at Google, they finally made me an offer. It was miserable. It was probably one of the most miserable things on my ego that I’ve ever seen. I joke I wanted the offer more than I wanted the job. I just wanted validation that I was smart, basically, in a nutshell. And the first time, they called me up and they asked me some questions and they said, “Ah, thanks. No, thanks.” And I was like, “What? What did I do wrong?” And then the second time, they called me up and it went a little further and they just kind of went quiet. And I went, “I guess I’m not that caliber.” And then I asked them that time, I said, “What was it?” They’re like, “No, we just didn’t have enough information. It’s not that you’re not good enough. We just don’t know.” They’re like, “We just don’t know what we don’t know.” So then later, the third time they called me and that time they made an offer, it was a long process. But they made an offer and they’ve figured out what they wanted to figure out to figure out if they wanted me. And some of that is just bottleneck, like you know, sometimes a company just won’t know enough about you to hire you and you can’t blame yourself for it. You just got to go, “Ah, keep doing my thing, figure out what the next thing is. Keep making myself better, you know, learning more, getting more experience and then move on to the next opportunity.” It’s hard though. It definitely puts a ding in your ego.

[00:43:53] SY: Absolutely.

And now, back to the interview.

[00:43:59] SY: So all of this sounds pretty advanced. It sounds like a lot to think about as a developer. When do these things come in handy? When do they tend to impact the things that we build? You know, is it something that new developers need to think about or worry about? Do you see this as more of, you know, an intermediate/advanced topic? You know, at what point should we start to really think about and consider, you know, how do we want our language to be interpreted? How do we want it to run? When should we think about this?

[00:44:29] TB: So ideally, you shouldn’t have to worry about this stuff for a long, long time after you got your application, your program. What you to want to write, finish. It’s nice to have different options once you get into debugging or scaling things, where your language has to not only run on computer but a thousand computers at the same time, stuff like this.

[00:44:52] SY: Yeah.

[00:44:52] TB: But you know, ideally, you shouldn’t have to worry about this. You should just have to download your one language like, “I want to learn Ruby.” Download Ruby here and you should be able to start. This would be perfect.

[00:45:03] SY: Yeah. So what value do you see there is in us understanding that this is going on? So even if we don’t use it to make a decision, even if we go about coming the way we have been so far, do you see a benefit to understanding a little bit more about what’s going on under the hood?

[00:45:22] TB: So it’s a lot of fun. (Laughter) That’s a huge benefit. This is why I got into this. The idea that you can create the language out of another language and then it suddenly exists is really amazing. It’s a lot of fun to think about and it’s mind-bending. But if you know about how your language is implemented better, then you know, as a beginner usually does, then you’re sometimes more able to troubleshoot certain problems. You can debug issues more. You know, if you know how rep requests or network requests are implemented in your specific Python implementation, you can maybe troubleshoot a problem that arises in your program where if you open 50 requests at the same time, one of them always leads to an error or something like that because you then know, “Okay, under the hood, I know what this Python interpreter is actually doing,” and it helps you troubleshoot these problems. And it also helps you lead to better performance, you know, because you now can predict what this implementation is going to do, what this compiler is going to do to your code and you can write your code more efficiently to take more advantage of these optimizations and stuff like this.

[00:46:39] SY: Yeah, absolutely. So how did you personally learn about all this stuff?

[00:46:44] TB: Three years ago, I started working through a book called Structure and Interpretation of Computer Programs. Everything in the book is written in a programming language called Scheme, which I haven’t used before. And I was, you know, astonished. I basically fell in love with this language. And I worked through this book and I was fascinated by this language and how could a language that looks so strange work like this. And you know, it prepared my thoughts for this, how do programming languages actually work? Because up to that point, I was only used to, you know, Ruby, Python, and languages I would call curly braces languages like C, you know.

[00:47:20] SY: Yeah.

[00:47:22] TB: And then in the fourth chapter of the book, you actually write an interpreter for a computer language. You write your own version of this language scheme in Scheme. And yes, it’s as mind-bending as I just described it. You write an interpreter for a language in the language you’re writing the interpreter, and yes, it’s as confusing as it is.

[00:47:46] SY: Interesting. Yeah.

[00:47:47] TB: And it’s also a lot of fun.

[00:47:48] SY: Yeah. Okay.

[00:47:48] TB: Yeah, exactly, exactly. They call it the meta-circular interpreter. So I came away from this book hooked, on this like, “How do you implement a programming language?” And then I started diving deep into, “Okay, but how do you actually implement a language that looks more like these curly braces languages that I’ve been using, you know, or a language that looks like Ruby?” And then I started digging through code bases and starting reading the source code of actually the programming language implementations because the good thing is that a lot of languages we use today are open source and you can actually read the source code. This is basically how I jumped into the rabbit hole and I’m now talking to you still in the rabbit hole.

[00:48:30] SY: Well, you’re jumping in the rabbit hole and then you wrote a couple of books about it. (Laughs)

[00:48:35] TB: Right. Yeah. Yeah.

[00:48:36] SY: You wrote two books about it, which is pretty amazing. So when you were writing your own interpreter, you wrote the writing interpreter in Go and writing a compiler in Go, is that right?

[00:48:47] TB: Right. Yeah. Yeah. Yeah, that’s it.

[00:48:50] SY: Yeah. So when you were writing an interpreter, writing a compiler, what was that experience like for you? It sounds like it was a lot of fun, but was it hard? Was it confusing? How much learning did you have to do on your way? Tell us a little bit about the journey of writing.

[00:49:05] TB: To answer the first question, was it a lot of fun? Yes, but it was also incredibly hard and exhausting and writing a book or two is really hard.

[00:49:17] SY: Yeah.

[00:49:18] TB: So let’s jump back a couple of years. I am still in the rabbit hole at this point. You know, back then, I was also in the rabbit hole. And I tried to find out how languages work and how to implement my own. So I started to implement this fictional language that I called Monkey. So Monkey, the idea was a language that looks kind of like JavaScript. It has curly braces. It has functions. You can pass around to other functions and you can print stuff and you can do math and add two numbers together and stuff like this. A really simple language and I started to implement it. This was my project like, “All right, I’m going to understand how programming languages work by implementing my own.” So I started to build an interpreter for Monkey. And this was really hard to do because the resources available to me at the time either were really, really lightweight or they were super, super heavy, like 500 pages books, you know, the books I’m just resting the microphone on. So there was no middle ground for me. So what I had to do was I had to take both of these types of resources and take, you know, what I could from each of them and try to build my interpreter, and then also at the same time, read through the code bases available to me. So I dug through all of these like code bases, theory books, tutorials to try to build my interpreter.

[00:50:47] And once I had it done, it was just, and I’m putting this in air quotes here, “Just 3,000 lines of code,” written in Go. And this was not a lot. And I thought to myself, “Look, this was such a struggle for me to get this, you know, this information like if I could just combine all of this and write a text that showed someone like me with my background, which is not in academia, how to write a programming language by starting with zero lines of code and ending at line 3,000 and explaining all the lines in between, then this would be a huge help. You know, this would be amazing.” So I thought naively, “You know what? I’m going to write a book.” So I thought, “Look, I got the code ready. I got Monkey implemented. Now I just need to explain it.” But still it was a really, really exhausting process because I don’t know how often you read through your code that you write, but if you actually read through your code to put it down in a book, you read it many times. And the more times you read it, the more flaws you find in it.

[00:51:55] SY: I was going to say… (Laughs)

[00:51:57] TB: Yeah.

[00:51:58] SY: The more it hurts. Yeah. (Laughs)

[00:51:59] TB: This is incredible like you think, “All right, this is bug free. This is as clean as it gets.” A week later, you read through the same thing and you go, “No, how could I name this like this? No, this is not good. Let’s get rid of that.” And then at this point, you already wrote the previous chapter. So now you have to go back to the previous chapter because you just changed the code, you know, that was explained in the previous chapter. So yeah, it took me a year of writing on the train, commuting to work, like to and back from work and I get up really early in the morning to write. Get up at 6:00 in the morning and then I write, and then I go to work. And on the train to work, I also write. And I did this for a year and then I self-published the first book.

[00:52:43] SY: That’s awesome. What was the response from the community?

[00:52:46] TB: The response was amazing. It was much better than I ever expected it to be because when I set out to write this book, I thought, you know, I actually said to my wife like, “If 10 people read this, this is going to be amazing.” (Laughter) There were so many people that wrote me emails and said like, “Thank you for writing this book because this is exactly what I needed. This is exactly the missing piece.” And I realized, “Yes, they were exactly in the same position that I was in where they couldn’t grasp these theory books but the tutorials, on the other hand, were also not enough.” This was really good. And especially, you know, they said like, “I also like your jokes in the book.” So all was well.

[00:53:24] SY: Yeah. (Laughs)

[00:53:25] TB: Success, right? This is the most important bit.

[00:53:28] SY: Nice. Wonderful. So if I’m listening and I want to learn more about interpreters and compilers, is the book you wrote, is it good for new folks, people just getting started or is there a different recommendation for folks who are taking the first step and understanding this world of interpreters/compilers?

[00:53:49] TB: Yeah. I’m going to toot my own horn here, but yes, this is definitely the book if you want to get started with understanding how programming languages work by implementing your own, and with the added disclaimer that you should have knowledge of programming, like you should have prior programming experience. This is not the, “I’m going to teach you programming, and at the same time, I’m going to teach you how to build your own language.” The requirement is basically, you should be comfortable programming and you should be comfortable reading Go Code, which, you know, we’re using the Go programming language in both books.

[00:54:25] SY: Yeah. Nice. So now, let’s move on to some fill in the blanks. Are you ready?

[00:54:30] TB: Yeah. Yeah.

[00:54:31] SY: Number one, worst advice I’ve ever received is?

[00:54:34] TB: Talent is really important in order to succeed.

[00:54:38] SY: Tell me about that.

[00:54:39] TB: When I started out programming in my teens and I thought about studying computer science, the public opinion was, “Look, you need to know math. You need to be really good at math.” And at the same time, math was shown as this thing that you either have or you don’t have. And this idea of talent is everything, this has followed, you know, me through the rest of my life, basically. When I picked up music and started playing guitar, there’s also this conception of, you know, “You need to have some talent,” and stuff like this. But the older I get, the more I realize that this is harmful advice because it discourages people from attempting to do things because they think “I don’t have the talent for this. I did not get up this morning and knew how to do the thing without having done anything before. That means I do not have talent. I’m bad at it. I’m not going to attempt to do it.” In addition to that, I think that, you know, persistence and discipline and actually practice and doing the thing is much, much, much more important than just talent.

[00:55:43] SY: Absolutely.

[00:55:44] TB: I know. I would describe talent as the thing that makes you enjoy practicing, you know, like if…

[00:55:49] SY: I like that. Yeah.

[00:55:50] TB: If you have a lot of talent, you know, practice comes to you maybe more easily than to others.

[00:55:54] SY: Yeah.

[00:55:55] TB: But in the end, the amount of practice you put in, that’s what counts.

[00:55:59] SY: That’s what matters. Yeah, it’s the growth mindset, right? This idea that if you try, if you push yourself, if you practice, if you do the work, you can grow. You know, the current state that you’re in is not your permanent state. It’s just where you are right now. And if you do things differently, then you’ll end up in a different state. That’s simple.

[00:56:16] TB: Yeah, exactly.

[00:56:17] SY: Yeah.

[00:56:17] TB: And of course, we have to add that, you know, persistence, you know, like keep practicing and you’ll get there one day, this is also not, you know, 100 percent true, like this is also really bad advice that, you know, like keep just doing this and someday you will succeed, you know, when people, you know, build their own company and they have this idea and they go, “Look, nobody likes it, but if we just keep on doing this, somebody will show up someday.”

[00:56:43] SY: That’s true. There’s a balance. Yeah.

[00:56:44] TB: Yeah, there’s a balance. At some point, you have to realize, “Okay, persistence is also not everything and if we keep persisting on doing this, you know, we’re not going to succeed.” Like, if I would have persisted on trying to be a professional guitar player, I swear to you I wouldn’t be a professional guitar player by now.

[00:57:00] SY: I believe in you. I think you could do it.

[00:57:03] TB: Yeah. And I’m not saying that it has…

[00:57:07] SY: Yeah.

[00:57:08] TB: It has nothing to do with skills, you know, at some point. It has to do with luck and, you know, like the situation you’re in and like, I don’t know, the circumstances that you can influence. So you know, take also this persistence and discipline and hard work with a grain of salt.

[00:57:23] SY: Absolutely.

[00:57:24] TB: Yeah.

[00:57:25] SY: Number two, my first coding project was about?

[00:57:28] TB: My first coding project was an IRC bot, chat bot. That was basically 15 years before chat bot became popular. So I was 13 or 14 years old and I basically hung around IRC channels all day and I couldn’t imagine anything cooler than a program talking to me in the chat. I don’t know what that says about me, but I thought it was amazing like, “Wow, you can… like other people are talking in this chat and I can build a program that also, you know, talks in this chat?” So yeah, I started out programming this IRC client called mIRC where you have like your own scripting language inside of it and you can basically program it to have predefined responses to certain things people say in the chat. So if somebody says, “Hello,” you can say, “All right.” If the other person says “Hello,” you can answer with, “Hello to you,” and then the nickname of the other person. And this was in the IRC client and then later on, I built this in Python, which back then, I got into and nowadays, I can’t remember a lot of, but it was in Python and I was so proud of it that I put my name on top. And that was my first real thing where I put my name on it and uploaded it to the internet.

[00:58:47] SY: Very nice.

[00:58:49] TB: Yeah.

[00:58:50] SY: Number three, one thing I wish I knew when I first started to code is?

[00:58:54] TB: That code is not everything, that writing lots of code is not as important as I thought it would be when I started out. And for two reasons really, the first one is that nowadays I think in a code base that a lot of people work on over a long period of time that less code is better than more code because more code means more bugs, means more maintenance, means more debugging, means slower test times, slower compile times or interpretation times or deployment times, and less is more in this case. I really like deleting code. If I can, you know, make it pull request that says like, “Minus 2,000 and plus 10 or something,” that’s a good day for me. Like this is amazing. I like getting rid of code. And the second thing is people sense that code is also not that important because in the end, you know, it’s about solving problems and it’s about helping others solve their problems. Or as author Kathy Sierra said it, like making your users badass, like they should be able to do amazing things. And often, that’s not about the code you write and, you know, you can fix a lot of things by just using an Excel table or something or a Google form or just playing old email and stuff like this. Software developers pride themselves that code is the most important thing in an organization and it’s more important than other people and stuff like this and I heavily disagree with that nowadays and I think that getting along with the people in your company and understanding their problems and solving them, however that might be, is much more important than just banging out code on a keyboard all day, even though I would love to do that. I would love to, but it’s not as important as you think it is.

[01:00:49] SY: Yeah. That’s always been hard for me to accept personally because, you know, especially…

[01:00:53] TB: Yeah. Yeah, it is.

[01:00:54] SY: Well, especially when I first started coding and I graduated from my boot camp and I had, you know, I had my new skills, I said, “I’m going to code everything.” You know, every problem is going to have a code solution. And I’ve learned over time that sometimes you just need to scratch this website. You don’t always need to build your own site from scratch. Sometimes you can use a lot of things that are off the shelf or just don’t feel very code-y, you know, and as long as they get the problems solved, that’s really what matters. And I think, especially earlier in my development career, I didn’t want to believe that but it’s true. It’s true.

[01:01:33] TB: Yeah, it’s totally true and I think that nowadays there’s a whole movement, basically, of this, you know, scene of Indie entrepreneurs that basically build company out of spreadsheets, [INAUDIBLE 01:01:53] than that, and you know, Amazon services, and they make millions of revenue per year without having written any single line of code.

[01:01:54] SY: Yup. Yeah, it blows my mind.

[01:01:55] TB: I’m not saying that this is the perfect solution for every business, but I’m saying that this is a solution. You know, you can do it without code. And the other dimension of this code is not as important as you think it is is, I started out thinking that the best technical solution will win like this product is technically far superior to this product. That means this is going to succeed, right? And a few years in in my professional career as a software developer, I realized there’s so much more that goes into this. You know, there is marketing, there’s hype, and we as software developers, we pride ourselves as being immune to hype, right? You can’t fool us, you know. We have rational minds. You can’t fool us, but in the end, like the new database comes out and we go, “Oh shiny, I need that,” you know. We still fall prey to this hype and this also goes to show, you know, that in the end, like the technical advanced product might lose to the thing, you know, that has more marketing or better documentation even or better… you know, it doesn’t have to be bad thing like hype has this bad connotation, but the other thing might be better document has a better user experience. And it also goes to show that, you know, better code or more code is not the most important thing in the world.

[01:03:13] SY: Absolutely. Well, thank you so much for spending your time with us and sharing all about interpreters and compilers and writing our own languages. Thank you so much for all that. You want to say goodbye?

[01:03:23] TB: Yeah. Goodbye and thank you for having me. I enjoyed this and I hope that someone at least got a little bit interested in programming languages and want to explore how they work.

[01:03:33] SY: And that’s the end of the episode. Let me know what you think. Tweet me at CodeNewbies or send me an email, hello@codenewbie.org. For more info on the podcast, check out www.codenewbie.org/podcast and join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. Thanks for listening. See you next week.