Hacker News Reader

Comment by FigBug | Hacker News Reader

> No languages are inherently "compiled" or "interpreted", that's a property of the implementation.

A language and it's implementation are usually designed at the same time. Compiled or interpreted will affect design choices that go into the language. While additional implementations may follow, it can be hard/impossible to design a compiler (machine code, not byte code) for a language that was designed to be interpreted without dropping features (ie eval).

It may be more correct to say 'Python was designed to be interpreted' than 'Python is interpreted'

View on HN

Not really - Javascript was designed to be interpreted, and yet V8/SpiderMonkey/Nitro all JIT-compile it down to machine code, sometimes very effectively.

When people talk about "compiled" vs. "interpreted" they usually mean AOT compilation, not JIT.

Then Java and .NET are considered "interpreted"? And Android under Dalvik is "interpreted", but under ART is "compiled" (using Java as the language, which I'd always thought of as compiled, yet apparently is interpreted under your definition)? What if you embed Clang & LLVM in your application to run C++?

I think this just illustrates the fuzziness of these definitions. A compiler is just a piece of code; you can embed it into another piece of code and run it whenever necessary. Maybe in the world of shrink-wrapped desktop software there was a sharp distinction between AOT compiled languages and interpreted ones, but we haven't lived in that world for a couple decades now.

I feel that what most people actually mean when they say "compiled" vs. "interpreted" is whether or not the language specification has additional static checking beyond what is required by parsing. Essentially it is whether the language defers all errors to run-time or attempts to detect classes of them at compile-time. A language like JavaScript accepts as a program any string that parses, while a language like Java rejects many strings based on additional checks such as type rules. You can add static type-checking to JavaScript or Python, but it isn't part of the language spec. You can run C++ or Java with run-time type-checking, but it doesn't conform the to spec. In this way you could say that the language is fundamentally compiled or interpreted.

Of course, this doesn't address issues of incremental evaluation which often requires additional semantics for compiled languages.

Let's just say that the lines got a lot blurrier over the last couple of decades. The difference is generally if there's an explicit compilation step that is not hidden from developers. If you "run the source file", then it's interpreted. If you "run something generated from the source file(s)", then it's compiled. Stronger type checking and compiled mode is likely since the cost of compilation is higher and more resource intensive, so it makes sense to push it into an offline step.

> You can run C++ or Java with run-time type-checking, but it doesn't conform the to spec.

I'm not sure what you mean by "conforming with the spec". You can opt out of type checking by using only `object` or `void*`. But golang has a mode where you run a go file directly and a mode where you generate a binary. There are no traditional interpreted languages anymore (or at least only very few). And what we call "compiled" languages today are not actually compiled ones. The way Java runs is closer to how JavaScript runs than to how C runs. It's only about the interface the offer to developers.

Reply on news.ycombinator.com