Tiny nitpick: the article describes JavaScript as an interpreted language without JIT when most major JS engines do have JIT optimisation. It’s difficult to make this call about any language with more than one implementation.
But anyway, kudos to the PHP folks for yet another improvement. It’s been a long time since I used it but I’m continually impressed by how far it’s come. And it’s a useful test to how flexible a developer is willing to be to ask them to code some PHP, there are fewer and fewer reasons against it these days other than personal style preference.
The whole idea of "language X is interpreted/compiled" is a simplification I wish people were more careful with.
Cpython is interpreted, pypy has JIT, mypyc is compiled. It's the implementation, or even implementation's specific runtime options that decide about things like that, not the language.
The statement would be far more accurate as "language X is [almost always/sometimes/often/commonly/etc.] interpreted/compiled". Unfortunately a lot of people seem to like speaking in absolutes.
Compilation is just interpreting what a program does and producing machine code (or other code in the case of transpilers) that computes the same thing.
Interpreters are just that, but instead of producing code, they run code in themselves thats computes the results directly.
One could even consider machine code just “obfuscated” assembly code. In that sense, machine code is just another language that also could be interpreted (intepretation-based emulators like Bochs) or compiled again (JIT-based emulators like DOSBox).
This brings up a slightly related question: is there a language that can’t be compiled?
Of course not, just compile your interpreter but instead of reading input from a file, have it read input from a fixed string (the source code) that is embedded in the binary. You've just created a super shitty compiler!
I personally wouldn’t consider that a compiler but just an interpreter bundled with the source. For example: Electron based desktop programs aren’t considered compiled (by anyone I know) even though they pack the interpreter (Chromium) with the source.
> This brings up a slightly related question: is there a language that can’t be compiled?
Not sure if you're asking this platonically, but Futamura shows us that if you can built an interpreter then you can always transform that automatically to be a compiler.
This is used in practice by some compilers today - they automatically produce a compiler from an interpreter!
That's not really a barrier. It's "can't be parsed without ambiguity", not "can't be parsed". You compile cases like that by compiling a check for the relevant condition, then compile the possible versions in the if/else branches. Unless you can prove which case it will be from other code - then you can simplify anyway.
By wielding the Futamura projections [0][1][2], any interpreter may be turned into a compiler. Perl is handled as one case. Crucially, the resulting compiler need not be fast; if the interpreter is slow, then the compiler will be slow too (this is a special case of the central meme from [3], "if the N'th Futamura projection has quality Q, then the N+1'th Futamura projection will also have quality Q.")
>Unfortunately a lot of people seem to like speaking in absolutes.
People like speaking in the general case. It saves time from enumeating any inconsequential / statistically not relevant exception.
The real problem is people misunderstanding casual discussion absolutes (which mean "for the large majority/for the ones people care about") with mathematical absolutes (i.e. "X is Y for each and every X")
I should probably add this kind of thing to the article then. It is nearly impossible to state "Language X is compiled/interpreted/jitted".
I didn't explicitly say that JS doesn't come with JIT, because I'd be putting Node.JS and every browser engine in the same bag. I simply can't be sure about all of them.
I'll add very soon this caveat that the dialect (js, php, python) doesn't really matter and make it clear that I'm talking about engines, possibly directly point to them.
I hope you understand, though, that I wanted to make JIT as a concept understandable. The language comparisons are secondary.
But anyway, kudos to the PHP folks for yet another improvement. It’s been a long time since I used it but I’m continually impressed by how far it’s come. And it’s a useful test to how flexible a developer is willing to be to ask them to code some PHP, there are fewer and fewer reasons against it these days other than personal style preference.