There seems to be a considerable amount of debate about what defines an interpreted language.
My view is pretty cut-and-dry:
A compiled language...
For further actions, you may consider blocking this person and/or reporting abuse
A few thoughts.
Does it actually matter?
"Interpreted language" should really be regarded more as a shorthand. It's not really the language which has the nature of being interpreted or not, but the execution environment. It just that some programs in some languages are more commonly run via an interpreter execution environment than others, and some languages lend themselves better to such an environment.
If a program is compiled (cross-compiled?) to bytecode, which is then translated to machine code immediately prior to it being run, then it is the bytecode which is the interpreted language, not the language in which the original source code was written.
It's really about what operations take place in a just-in-time-to-execute fashion. If the program is translated from its stored form to machine code just in time to execute it, then the program in the language in which it was stored can be said to have been interpreted from that language.
I think this makes the most sense. I'm a Java dev, and it doesn't matter that libraries are linked at runtime and bytecode is interpreted dynamically. Java has a compiler step, and it's actually quite difficult to get Java source code interpreted and run at runtime. There are solutions to execute Java from source at runetime, but they are all difficult and feel very hacky. Not to mention, the Java compiler is not distributed in the normal runtime, that's why there's a difference between the JDK and the JRE. Java is not an interpreted language, JVM bytecode is. But there are other JVM languages (Groovy) that do ship with their compiler and allow dynamic execution from source code, which are capable of working precisely because JVM bytecode is interpreted.
Now this I find intriguing.
Would you then say that Java is a compiled language? And, if so, what term do we apply to a language compiled down to machine code (C++), but not to a language compiled down to bytecode (Java). That seems like it would matter, since shipping a completed C++ project (here's the binary file, have fun) and shipping a completed Java project (runtime needed) are vastly different undertakings. What term do we use to distingish? "Assembled" language?
That's a matter of semantics. They're both compiled, because neither one can execute its own source code at runtime without considerable complexity. It's just that C/C++ is a language that effectively ships with it's runtime environment, Java is not.
I'm not sure this is accurate. By time a C or C++ application has been compiled and assembled, it is completely machine code, and is executed directly by the CPU. If it does not rely on any dynamically linked libraries (dependencies are a whole other topic), it can be executed on any machine for which the machine code is intended (X86, ARM, whatever). It isn't "shipping with its runtime environment," it doesn't have one.
Keep in mind that there is a difference between Java and the JVM. There are many different languages that run on the JVM, and not all of them are compatible with Java source code or Java libraries.
With widespread use of AOT, JIT, and native language bindings not to mention exotic things like Roslyn and hardware implementations (e.g. Java processor), the distinction is perhaps murky and mostly accademic.
In practical terms, it comes down to a programmer's workflow. Do you run a compile step? No: interpreted.
Interesting approach, but I'm not sure the Java processor really makes it a compiled language in the typical sense of the term. They still run it off their own custom bytecode, instead of assembling it down to actual machine language for common architectures. It's kinda "cheating" to me (but props that it works regardless).
I'm playing devil's advocate.
It's not all that exotic, ARM has Jazelle.
Similarly, many CPUs have complex instructions that are decoded at execution time into smaller, native instructions (i.e "interpreted").
Since the beginning Java has had
javac- the "Java compiler". Surely having a compiler makes you compiled.But mostly it doesn't really matter. It's an imprecise term that can be interpreted as pedantically as you like (pun intended).
Remember the definition, which I didn't make up.
You can compile to anything, but if the product of the compilation is not actually executable in and of itself, but requires an interpreter to execute, isn't that still an interpreted language?
After all, Python compiles to Python Bytecode (
*.pyc), but that still can only be executed through the Python interpreter. According to the language's own documentation, Python is an interpreted language, and not a compiled language.At least two transformations happen for any code to run on your computer, transformation from the source to machine code, and transformation from the machine code to actual state changes internal to the hardware that do what you want.
Some languages add an additional transformation from the source to an intermediary code that then gets translated to machine code (C and FORTRAN translate to assembly before machine code, Java goes to JVM bytecode, C# goes to CIL bytecode, etc), and some hardware adds an extra layer between the CPU instructions and the internal state changes (most modern x86 CPU's translate from the high-level x86 'machine code' to a different lower-level machine code specific to the micro architecture), but both cases still fit that 'two transformations' model at a large scale.
The classical differentiation between compiled and interpreted languages is when the series of transformations from source code to machine code actually happens. For compiled languages, it's done ahead of time. For interpreted languages, it's done at runtime (either while executing, or in a single pass right before execution). Some languages though don't quite fit this concretely (Java - which may be compiled directly to machine code, or might be compiled to JVM byte code which is then transformed to machine code at runtime - is a good example of such a language).
These days though, the primary differentiation most people think of is that interpreted languages have the option of some kind of interactive REPL, while compiled languages usually do not. Pretty much every language can be classified in this manner, though it can be fuzzy here too (see for example: github.com/evmar/c-repl).
Ultimately though, it's largely irrelevant these days unless you're doing cross-builds or porting to a new platform (languages that fit the classical definition of being 'compiled' tend to be easier to use in both cases). Yeah, it has some impact on how you might develop and debug, but that impact isn't anywhere near as binary as the terminology implies, and may even vary by individual workflow.
Haskell is interpreted? I thought it was compiled.
There is at least one (unsupported and outdated) interpreted implementation,
Hugs98.I was under the impression it was interpreted, but I'll change my example to Ruby just to be safe.
There is no debate, really. Not in the academic computer science, at least. Any attempt at defining an "interpreted" language outside of CS is doomed to fail.
There is no such a thing as an interpreted or a compiled language. There are languages that make it hard to produce an efficient compiler - e.g., some very dynamic languages like Python, or languages with fexprs, languages heavily relying on runtime reflection, etc.
It is still possible to have a not very efficient compiled implementation for such languages though, so we cannot use a presense of such features as a definition for an "interpreted language".
Besides that, nothing in a PL semantics says it's "compiled" or "interpreted", not to mention that the boundary between compilation and interpretation is very blurred.
EDIT: another important point - a programming language is defined by its semantics, while syntax and grammar are only of a secondary importance. And how do we define semantics? Normally, via term rewriting rules, i.e., an interpretation. When you look from this angle, all the languages are "interpreted first".
Here is an explain like I'm five, in case your wondering what is what.
What parsers and 2 year olds have in common. πΌ
Adam Crockett γ» Aug 7 γ» 2 min read
It is more an 'explain it like I have kids'
Well I do so I did π