Why is there such a clear cut between interpreted and compiled languages?

Question

When learning a compiled language like C or C++, you get to know the compiler. In order to run your code, you have to compile it first. Compiling your code translates it from a textual representation into something that can be executed. The resulting code is very fast and can make use of preprocessors and the like.

When learning a dynamic language like Python, Matlab, or Ruby, you get to know the interpreter. In order to run your code, you just type it into the interpreter. Thus, you can play with your code at runtime and change the behavior of your program on the fly. The downside of this seem to be that interpreted languages are rather slow and the lack of a clear compilation time seems to makes preprocessors impossible.

Then there are just-in-time compilers which are used like interpreted languages but with less of a performance deficit compared to compiled languages. But they generally do not sport preprocessors and do not output ready-to-run binaries.

And then I learned Lisp, which can be compiled, interpreted and what have you, all the while being both fast and having a powerful preprocessing system (macros). This seems to be common sense in the Lisp world, but not anywhere else.

Why are there no popular interpreters for C or compilers for Python? Why the strong divide between interpreted and compiled languages? (I know some projects exist that can compile Python or interpret C, but in general they seem to not be very popular).

Answer 1

Most popular compiled languages were designed from the ground up to be compiled: they tend to avoid features that would make it difficult to produce efficient compiled code. These language features include the convenient "dynamic" ones such as dynamic typing, nonuniform containers, and ad hoc object namespaces.

So, an interpreter for a compiled language can't take advantage of the dynamic features that are available to a interpreted language, but lacks the performance advantages of a compiled implementation.

Conversely, a compiler must duplicate all features and behavior of an interpreted language, regardless of expense. In general, this means that the compiled program for an interpreted language will carry much of the overhead of the interpreter. As one example, any kind of eval() functionality effectively requires inclusion of the interpreter.

Finally, these effects are amplified by the mutually reinforcing advantages of large user base, good support, and robust implementation.