No, that is also wrong.

Even if you only consider compilers and interpreters (in real life there are many in-betweens: bytecode/VW, JIT, etc.), a language is not either interpreted or compiled. Maybe its reference/canonical implementation is an interpreter or a compiler, but that's all.

What would stop anyone from writing a C interpreter? Or a Python compiler?

Now consider OCaml, which canonical distribution comes with the `ocaml` interpreter, and the `ocamlc` and `ocamlopt` compilers: how do you classify the language?

Some languages cannot be compiled because their behavior is dependent on runtime values. An example is John Shutt's Kernel language.

Here's what Shutt has to say about the difference between interpreted and compiled languages: https://fexpr.blogspot.co.uk/2016/08/interpreted-programming...

tl;dr: The choice of compiled vs interpreted is made early on and greatly affects the design of the language semantics early on.

I don't think this breaks my point. For example, I don't see of any reason a language could be compiled but not interpreted. And that alone breaks the idea that a language is necessarily either compiled or interpreted.

Moreover, the distinction that Shutt makes in this blogpost between compiled and interpreted is not very clear: most of what he says rings more to me as a distinction between static and dynamic rather than between compiled and interpreted, but I concede that I read the blogpost rather quickly and without taking the time to fully grasp everything.

Interpreters are more flexible; I'd expect that any compiled language could also be interpreted. I'd expect that at least some languages where the canonical implementation is an interpreter could also have an ahead-of-time compiler implementation, but that some of those languages would have at least sections of the program that need to be just-in-time compiled (or even recompiled) at runtime. That would pose extra difficulty in making a compiled implementation of the language.

It's interpreters all the way down. (https://news.ycombinator.com/item?id=15233188)

Edit: Just adding that it helps to think of some interpreters as faster than others, and it may pay to translate code from one interpreter to another.

"ocaml does both" wfm.

This is an introduction, details will be glossed over.

Sorry, I don't understand, what does "wfm" mean?

> This is an introduction, details will be glossed over.

Maybe, but I really don't like this. Sometimes it is necessary to simplify things (at least in the first place) to teach them, but it is very rarely the case that it is necessary to say something actually wrong. For example I think it is totally acceptable to ignore the existence of VM and JIT in this chapter, because explaining what they are requires knowledge that the targeted readers don't yet have.

But I don't see what good it does to say that the two types of languages are compiled languages and interpreted languages. It may even be counterproductive because the same paragraph which explains what a compiled language is as opposed to an interpreted one ends with this sentences: “You can think of the C language as a compiled language because most C language vendors make only C compilers to support programs written in C.”. This sentence is now confusing for the inexperienced reader, while it is the only acceptable one in the paragraph.

It would not have been more complicated to explain that languages can be implemented either with a compiler or an interpreter, then explain what is the difference between the two (this is already done), and then finish with that same sentence :).

> what does "wfm" mean?

"works for me" https://www.urbandictionary.com/define.php?term=wfm

> Maybe, but I really don't like this.

I think it's a useful simplification to say something like "C can be interpreted, but it's almost always compiled in practice, so we usually say that it's a compiled language". Even with that, you've got to have an explanation of "compilers" vs "interpreters", with the attendant decisions involving the balance of simplification vs pedantry that it's so easy to get mired in (this thread being an example).

A document claiming "Learn [topic] in [short amount of time]" seems likely to err on the side of simplification (the alternative being perceived by the author as over-explanation). In that position, my solution might've been to avoid the compilation vs interpretation discussion, describe a compiler as a program for converting source code into a computer-friendly format, add a footnote to something in the appendix with a deeper explanation of other methods of preparing source code to run as a program, and move on.