3 ms·

Bytecode encoding an interpreted language is only superficially similar to compilation. After all you can't perform meaningful optimizations when the environme

Bytecode encoding an interpreted language is only superficially similar to compilation. 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.

dragonwriter 3y ago
> Bytecode encoding an interpreted language is only superficially similar to compilation. 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”.
- Guvante 3y ago
  You have come up with your own definition that conflicts with what everyone is saying and are wondering why there is uncertainty...
  - dragonwriter 3y ago
    > You have come up with your own definition 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.
    - Guvante 3y ago
      I never said scripting languages can't have a compiler. I meant a compilation step means you aren't interpreting anymore. Apologies for my inexact verbiage.
  - horsburgh 3y ago
    I beg you, please don't speak with such certainty about definitions which you're not certain of, particularly when you've already been corrected. Take the opportunity to learn something new. Dragonwriter is using exactly the definition that people who work in this area use. 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.
    - Guvante 3y ago
      My point wasn't well made you are correct. 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.

dragonwriter 3y ago

> Bytecode encoding an interpreted language is only superficially similar to compilation. 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”.

Guvante 3y ago
You have come up with your own definition that conflicts with what everyone is saying and are wondering why there is uncertainty...
- dragonwriter 3y ago
  > You have come up with your own definition 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.
  - Guvante 3y ago
    I never said scripting languages can't have a compiler. I meant a compilation step means you aren't interpreting anymore. Apologies for my inexact verbiage.
- horsburgh 3y ago
  I beg you, please don't speak with such certainty about definitions which you're not certain of, particularly when you've already been corrected. Take the opportunity to learn something new. Dragonwriter is using exactly the definition that people who work in this area use. 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.
  - Guvante 3y ago
    My point wasn't well made you are correct. 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.