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.