Hacker News new | ask | show | jobs
by viraptor 2115 days ago
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.

2 comments

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.

C can be interpreted too: https://en.wikipedia.org/wiki/CINT

Theoretically, any language can be interpreted.

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!

"question: is there a language that can’t be compiled?"

There is some question whether Perl could be, because parsing it without running it has some ambiguity. https://www.perlmonks.org/?node_id=663393

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.")

[0] https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...

[1] http://blog.sigfpe.com/2009/05/three-projections-of-doctor-f...

[2] https://www.gwern.net/docs/cs/2009-gluck.pdf

[3] https://www.itu.dk/people/sestoft/pebook/

>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")

And the Rust compiler ships with a Rust interpreter, used to evaluate const fns (functions whose output can be determined at compile time).
const fns can only use a subset of the language AIUI
Well, the idea being that CPython is 99% of what people use, and the other are nearly irrelevant projects...