> Then you missed my actual explanation and description, which is described in the rest of the post. Since others are also apparently confused, I'll re-state it here.
I think the confusion stems from using the word "operates", which suggests a VM that exists at runtime:
> There’s just one problem with this: C also operates inside of a virtual machine.
I agree with the sibling comment that in this context the term abstract machine would be better. Also, saying "C is defined in terms of an abstract machine" instead of "operates" might be better.
In the language of the spec, it does “operate” inside the machine. Well, the spec says “execute” but that’s even more likely to be confused with a runtime thing.
Additionally, and this is something I really didn’t get into, languages aren’t inherently compiled or interpreted. You could have a C interpreter.
> Additionally, and this is something I really didn’t get into, languages aren’t inherently compiled or interpreted. You could have a C interpreter.
Of course; I was only addressing the confusion that other posters mentioned. While one could have a C interpreter (or any interpreter), for the purposes of the article this seems to be only a marginal point. In practice, C is (almost) never run that way, but your choice of words could suggest a parallel between the C abstract machine and the Ruby or Java VMs, and I think the way usual C implementations differ from those is more informative than how they are alike.
You do explain later that the C abstract machine is a compile-time construct, but many people read selectively and react immediately, as evidenced by several posts on this page.
I think the confusion stems from using the word "operates", which suggests a VM that exists at runtime:
> There’s just one problem with this: C also operates inside of a virtual machine.
I agree with the sibling comment that in this context the term abstract machine would be better. Also, saying "C is defined in terms of an abstract machine" instead of "operates" might be better.