One of my favourite things about the question between compilers and interpreters is the Futamura projections [0] which is a way of using partial evaluation to construct both things. It could be interesting if we see that getting used more explicit than something like GraalVM which one could argue is getting there. [1]<p>[0]: <a href="http://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html" rel="nofollow">http://blog.sigfpe.com/2009/05/three-projections-of-doctor-f...</a><p>[1]: <a href="https://news.ycombinator.com/item?id=18995651" rel="nofollow">https://news.ycombinator.com/item?id=18995651</a> (and the parent: <a href="https://news.ycombinator.com/item?id=18995498" rel="nofollow">https://news.ycombinator.com/item?id=18995498</a>)
You can probably draw a sharp line in two ways:<p>1. You're interpreting if syntactic tokens <i>directly</i> drive evaluation. So only first two are interpreted.<p>2. Interpreters take syntactic input and evaluate to a result that comes from running the program, a compiler takes syntactic input and outputs a program that must then itself be run to compute the result.<p>That said, I agree that "interpreted language" or "compiled language" is not a formally correct term, it's a connotative definition implying what's typical or the purposes for which a language may be suited.
Of course even if you don't use a bytecoded language, your object code is interpreted by a program, the micromachine, in your CPU (unless you are running something VERY simple like a Z80 or small AVR, which implements the machine code in hardware).<p>One of the nice perspective insights from 3Lisp, which of course was very high level!
Crystal lang has both compiler and interpreter.<p><a href="https://github.com/crystal-lang/crystal">https://github.com/crystal-lang/crystal</a>
It's a long (but good) article, so don't miss the conclusion:<p>> Another thing I hope that I've indirectly shown, or at least hinted at, is that any language can be implemented in any style. Even if you want to think of CPython as an "interpreter" (a term that can be dangerous, as it occludes the separate internal compiler), there's PyPy, which dynamically compiles Python programs into machine code, and various systems which statically compile Python code into machine code (see e.g. mypyc).<p>(Emphasis mine:)<p>> There are interpreters for C and C++ (e.g. Cint or Cling).
Really great article, thank you author for writing it. I think the first 2 implementations are what I think as interpreted. The next two, not sure. For the last, there is no doubt of compiled. But that is just my understanding.
What would you classify TCC's "C scripting" as?<p>"just add '#!/usr/local/bin/tcc -run' at the first line of your C source, and execute it directly from the command line."
Compilation and runtime are nominal stages. JIT too.<p>It's all about transformation of code to other code... and we can be more flexible in our classification. If modern languages even need one.
I am going to hard disagree.<p>This analysis focuses on the language specification and ignores the wider picture.<p>The first question we have to ask about a language is what caused it to be created. Making a language is a lot of effort (though it can be a lot of fun), and there has to be a reason for it (even if it just curiosity).<p>Now to simplify stuff, let us choose to ignore purely exploratory languages.<p>The first question to ask is what problem the author was trying to solve with the language.<p>Take a look at C and AWK in which Brian Kernigan was heavily involved. The design goals for C were a lot different than the design goals of AWK. This led to C generally being compiled, and AWK being interpreted.<p>In addition, in the case of C, there were deliberate decision decisions made to make it easier and to compile and optimize (for example all the undefined behavior).<p>Now let's take a look at Java. The solution space that this was aiming for from nearly the beginning was a high-performance language compiled to a virtual machine using garbage collection. A lot of design decisions were made for the language with that goal in mind.<p>Or look at C++. The design goals basically necessitated a compiler (even if the output of the compiler was C as CFront did) vs an interpreter.<p>In addition, an ecosystem of a language is much more than the language, and can even be more important than the language itself. And the ecosystem, for the most part picks a side in the interpreted vs compiled debate.<p>You could have a Java without the JVM, but you would lose access to a lot of techniques, libraries, debugging tools, and development tools that you have now.<p>C++ does have interpreters, but these are all "use at your own risk" and many libraries will behave in weird ways (with regard to static initialization, etc) since they are being used in an unintended manner. I don't think anybody uses an interpreted C++ in a production system, and rather it is used more for exploratory development and analysis.<p>Similarly a compiled python loses compatibility with certain libraries and there are issues that pop up that you would not have with the more widely used interpreted version.<p>So yes, theoretically languages can be compiled or interpreted, but practically from the design going forward, usually one or the other is explicitly or implicitly aimed for, and using a language against that grain can lead to a lot of unnecessary pain.
To me, compiled means fast with static types only, interpreted means slower and with possibly dynamic types. Most people will probably agree that C is compiled and Python is interpreted. I know there are some counterpoints that break that, but I don't care, cause the designation is still useful.<p>The author has identified that "compiled" and "interpreted" don't mean much about how the code technically runs. What really makes the difference is the intended use case. Same reason tomatoes aren't fruits in layman's terms.