compilation speed matters. it matters to some more than others, obviously, but it absolutely matters, and to some it matters a great deal.
There is no requirement that a compiler has to produce a binary. Compilers can also produce byte code or JavaScript or C code.
Also very few languages are purely interpreted.
Python, Ruby, and Pearl aren't (purely) interpreted. They're compiled
to bytecode, then that bytecode is interpreted. At least for primary version there's also jvm/.net versions of python and ruby and pypy(jit). Compilation happens at import/run time. Emscripten uses llvm to compile c/c++/rust into JavaScript.
Java and C# are recompiled into byte code which is then interpreted or jit compiled or both.
I'm pretty sure this is nonsense and is not a consistent way to distinguish languages that are considered scripting languages and languages considered compiled languages.
> Compile litterally means "group together".
Maybe so, but as a technical term in computer science, it means translate from one language to another.
That said, I definitely agree that compile times matter.
But most scripting languages are usually compiled (even if not to always AOT and not always to native code, but instead to bytecode of some kind), so how can a difference between compilation and interpretation, even if it was a valid one, be relevant here?
After all you can't perform meaningful optimizations when the environment your code is running completely defines what the code does.
Sure you don't know the details of how syscalls work but you do know the exact process necessary to call a function in compiled languages. Interpreted languages tend to just emit the original names in the bytecode because you don't know want the function `sin` when that is environment dependent.
No, its literally compilation, not something superficially similar to it.
> After all you can’t perform meaningful optimizations when the environment your code is running completely defines what the code does.
The environment your code is running on completely defines what the code does in all cases, and yet, meaningful optimization is possible, and bytecode for abstract/virtual machines are common for both things both for things that are commonly called scripting languages and things that generally are not. (Sometimes, the implementation of an abstract/virtual machine may involve another, JIT, compiler to some other – maybe native, maybe not – target.)
It’s true a lot of the languages called “scripting” languages have semantics that are structurally very difficult to optimize, but that has nothing to do with “interpreted vs. compiled”.
No, I haven’t. Compilation is well-defined (unlike, really, "scripting language", though there are clearly languages that are frequently called that despite the absence of any coherent definition bounding the class), and its unquestionable that many implementations of languages usually called "scripting languages" use it.
> and are wondering why there is uncertainty…
No, I’m not “wondering” anything, and “uncertainty” isn’t even part of the discussion.
I meant a compilation step means you aren't interpreting anymore.
Apologies for my inexact verbiage.
My copy of the red dragon book defines a compiler as a program for translating from one language to another. A translator from source to bytecode clearly meets this definition. If you have a problem with that definition then you're on pretty shaky ground since you're essentially making the argument that you know more about this sort of thing than Aho, Lam, Sethi and Ullman.
The distinction between a compiler and an interpreter is most clearly illustrated by old school (pre-JIT) java, where javac is clearly a compiler which translates Java source to Java bytecode (language -> language) and the java executable itself which interprets bytecode.
That distinction still exists in most interpreted language implementations, though not all. Python being a good example. It has a compiler which translates source to bytecode and an interpreter which executes the bytecode. They just both exist in the same program but crucially it certainly includes a compiler.
It was that there needs to be a distinct target language.
Encoding the source language in a more compact form without meaningfully changing it beyond superficially isn't compilation.
Like a web server that compresses JavaScript isn't a compiler.
My point was anything that outputs something that has to be interpreted is on sketchy grounds: if you are interpreting it how is that a distinct language from the original.
CPython can interpret py files or compile them into pyc.
CPython does not interpret the resulting bytecode. It executed on its virtual machine that bytecode.
Similarly Java and .NET languages are compiled into a bytecode which is executed on a virtual machine.
You don't interpret a compiled output.
The confusion comes from languages which support both like Python. We call Python interpreted as a shorthand for "can be interpreted" but modern Python often is compiled for the enormous performance benefits.
To reiterate you don't interpret bytecode you translate or execute it on a virtual machine.
I agree with most of your comment, but how do you explain languages with end-of-block markers? E.g. in Ruby, if you stop execution before the end you will surely get an error:
def test
puts "test"
end
So compilation time obviously only applies to compiled languages.
Saying that the compilation time is not a concern to you and shouldn't be to anyone is also very short sighted. I'm pretty confident that you would consider it to be a problem if a "Hello world" took a week to compile. Maybe you meant "Compilation is fast enough for me", which is fine, but there is no reason why your speed expectation should be more legitimate that anyone else's.