Implementing a programming language in C, part 1
bread-man.github.io
bread-man.github.io
What? This doesn't seem right. I think this is only true if your interpreter does something like compile down to byte code a la Python. In a language like BASIC or certain implementations of Forth there should not be such an intermediary step.
"On Linux, considering apt is your package manager, run sudo apt-get install clang to get the Clang compiler installed."
I really like Debian, but I think there's a large portion of the Linux community (Red Hat, SUSE, Arch, etc) guys that will feel shafted at that statement, and probably will mutter something about Ubuntu destroying the Linux community.
I'm sure this will be an interesting series, I just think given how hard language design is, that I'm not yet filled with warm fuzzies about this write-up. I think the author is doing a good thing, and going out on a limb that most wouldn't but I think it might be good to emphasize that all best practices may not be present.
There are many ways to implement interpreters besides VMs, including "threaded" interpreters and tree-walking evaluators.
I don't fault anyone for not knowing something, but that calls for asking questions, not making incorrect assertions.
Imagine it said, 'On Linux, given apt is your package manager, run ...'
That would make it a statement covering a common case without assuming it's always the case.
>> What? This doesn't seem right.
The interpreter itself is the virtual machine that runs a program written in the interpreted language, just like JVM is a virtual machine that runs a program written using byte-code.
In some sense, python and ruby compile into bytecode, and then the bytecode is executed using an interpreter. There are also concepts such as partial evaluation (where you do a little interpreting while you compile) and JITing (where you do a little compiling while you interpret) which also seem to mix compilation and interpretation, but can be clearly specified as a particular combination of them.