> 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 :).
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.
> 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 :).