Another way of approaching the implementation versus abstraction issue when it comes to misconceptions about programming languages and their toolchains/runtimes is to make "[programming languages are notation, and] notation is not machinery" something of a catchphrase.

This passage is something like an ideal target (case study is misapprehension).

No, this was never the case.

now a property of the program

To re-iterate: that's how it's always been. Programming languages and compilers are two different things. To conflate them is a category error.

No. Languages are neither fast nor slow. Only language implementations.

s/more efficient programming language/programming environments with more efficient implementations/

NB: the requirement wasn't actually "parsing JSON in C"; it's that for the JSON parsing the machine ultimately executes the same (or similar) instructions that it does when the JSON parsing is written in C and that C is compiled with GCC.

That seems like unnecessarily tight coupling. Surely there's a better level of abstraction that's higher than "emulate the hardware platform".

There's a weird (read: "weirdly obvious") category error here. NodeJS is not a language. (This wouldn't be so notable if the comment didn't go on to say "The key point is writing to an interface and not an implementation.")

The puzzle piece that fits the shape of the hole here is "JS". JS is the language, NodeJS is one of its implementations—and chubot knew both of these things already, so it's odd that it was expressed this way. Plus, there's a lot more diversity of JS implementations than exist for e.g. Python...

A similar mistake is being made here as the one that precedes the reminder that there is no such thing as a fast programming language—only a given implementation can be called fast.