Like the post says, there are plenty of others on the web about implementing interpreters or compilers for more useful languages, and, even if it's just Scheme, those tend to spend nearly all their time on the parser. I really like this series because it skips the parsing part to get to the most interesting and relevant topic: how actual language runtimes are implemented.

Well, why not just make yet another one for one of those more useful languages, but not fall under the same trap of spending too much time on the parser?

Because then you're increasing the cognitive overhead for the reader and the time commitment overhead for the writer.

But yeah, if the author wanted to make a part 3 it might be interesting to see his implementation for something like (a simplified subset of) Java bytecode.

I agree that the article itself seems great, but I like to follow along and the output adds an extra step. I shouldn't complain, really.

Can you clarify what you mean by "copying everything"?

A good thing about BF, IMHO, is that its syntax is trivial to the point of almost non-existence, and that its memory model is C-like.

Yes, sorry, I mean to make it human-readable, I always copy BF to https://copy.sh/brainfuck/ so I can check whether the output is correct. '12345' is a lot easier to read than +++++++- ++++++-+ ++++++-- +++++-++ +++++-+- or whatever.

I agree that the language itself is very likeable for the reasons you stated, but I'm partial to things that I can easily check. It's called Brainfuck for a reason. ;)