[00:27:46.13] Alright. First of all, the difference is an interpreter takes source code as input and executes it, and it doesn’t leave anything behind except what the source code tells the interpreter to do. A compiler takes source code as input and produces something that can then be executed. For example, Ruby the is an interpreted language, and if you want to run Ruby source code, you take Ruby source code and pass it to the Ruby interpreter, and it executes the source code. And a compiler, like the Go compiler, it takes Go code and produces and leaves behind an artifact, an executable binary file you can then run on your computer and your operating system, and your CPU can now understand this. That’s the big distinction. But again… It’s turtles all the way down. The lines get fuzzy real fast if you start to dig in, because there are certain interpreters – for example those highly optimized Javascript engines – that kind of cross the line, because they’re compiling while they are executing. This is called “just in ” compilation (JIT).

So the question is, “Is this a compiler, or is this an interpreter?” because it takes source code, it then compiles it to get machine code, and it then executes this machine code directly, just in time. The question is, “Is this a compiler or an interpreter?” I don’t know what the answer is… They’re called JIT interpreters or JIT compilers, and they’re really fascinating.

The reason why I chose to explain how an interpreter works is because I think compilers are much more, let’s say — I won’t say ‘complex’, but you have to do a lot more to get it working. I wanted to keep the scope of the book small, so I only chose to show how an interpreter works as a starting point. Because if you follow the book and you do everything in the book, you get away and you know how the puzzle works or how it’s built, and how you can build your own, and you know how to work the abstract syntax tree. Those are all parts you can use, again, in a compiler.

The other thing is I’m not a compiler wizard, or anything. I’m not a compiler expert, and it’s a topic that’s still kind of intimidating to me because I don’t know everything about it and I don’t really know how those big compilers (like GCC) work. I’m starting to dig in… I tried to build a compiler for the Monkey language, or I’m currently building it, I’m playing around with it, and I think if I chose to do that, to explain how a compiler works, the book would have been like 200 pages longer. It was just a question of scope, and it was a question of how easy is it to get started and how easy is it to finish the book.

I think in the end it’s not one or the other, because if you learn how to write an interpreter, you’re perfectly well equipped to write a compiler afterwards. In my opinion, it’s the first stepping stone to understand compilers better.

Source link


Please enter your comment!
Please enter your name here