3 ms·

I'm well aware of V8 and pypy. I also really like Python as a language, especially with mypy. It just makes me sad that in a world with multiple high-performan

I'm well aware of V8 and pypy. I also really like Python as a language, especially with mypy. It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). There is a really important (if not "magic") difference between JavaScript and Python. JS has always (well, since IE added support) been a language with multiple widely-used implementations in the wild, which has prevented the emergence of a third-party package ecosystem which is heavily tied to one particular implementation. Python on the other hand is for a large proportion of the userbase considered CPython, with alternate implementations being second class citizens, despite some truly impressive efforts on the latter. The fact that packages written in JS are not tied to (or at least work best with) a single implementation is also what made it possible for developers of JS engines to experiment with different implementation approaches, including JIT. While I'm not intimately familiar with writing native extension modules for Node (having dabbled only a little), my understanding is the API surface is much narrower than Python, allowing for changes in the engine that avoid breaking APIs. But there is less need for native modules in JS, because of the presence of JIT in all major engines.

zzzeek 4y ago
> It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). this is misleading, if one sees the phrase "interpreter" as that code is represented as syntax-derived trees or other datastructures which are then traversed at runtime to produce results - someone correct me if I'm wrong but this would apply to well known interpreted languages like Perl 5. cPython is a bytecode interpreter, not conceptually unlike the Java VM before JITs were added. It just happens to compile scripts to bytecode on the fly.
- chrisseaton 4y ago
  Bytecode is just another data structure that you traverse at runtime to produce results. It's a postfix transformation of the AST. It's still an interpreter.
  - an1sotropy 4y ago
    Well, ok, but then isn't a CPU is also just an interpreter, traversing the object code text of compiled code?
    - chrisseaton 4y ago
      We don't normally call hardware or firmware implementations an 'interpreter'. Almost all execution techniques include some combination of compilation and interpretation. Even some ASTs include aspects of transformation to construct them from the source code, which we could call a compiler. Native compilers sometimes have to interpret metadata to do things like roll forward for deoptimisation. But most people in the field would describe CPython firmly as an 'interpreter'.
      - zzzeek 4y ago
        I call it "bytecode interpreted" to distinguish it from traditional parse-tree interpretation such as Perl 5 and others
        deleted 4y ago
        [deleted]
  - zzzeek 4y ago
    so you'd call the pre-JIT JVM an "interpreter" and you'd call Java an interpreted language?
    - chrisseaton 4y ago
      > so you'd call the pre-JIT JVM an "interpreter" Yeah? I think almost everyone would? > and you'd call Java an interpreted language? Java is interpreted in many ways, and compiled in many ways, as I said it's complicated. It's compiled to bytecode, which is interpreted until it's time to be compiled... at which point it's abstract interpreted to a graph, which is compiled to machine code, until it needs to deoptimise at which point the metadata from the graph is interpreted again, allowing it to jump back into the original interpreter. But if it didn't have the JIT it'd always be an interpreter running.
mkoubaa 4y ago
This is in the process of being addressed - look into the HPy project

zzzeek 4y ago

> It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). this is misleading, if one sees the phrase "interpreter" as that code is represented as syntax-derived trees or other datastructures which are then traversed at runtime to produce results - someone correct me if I'm wrong but this would apply to well known interpreted languages like Perl 5. cPython is a bytecode interpreter, not conceptually unlike the Java VM before JITs were added. It just happens to compile scripts to bytecode on the fly.

chrisseaton 4y ago
Bytecode is just another data structure that you traverse at runtime to produce results. It's a postfix transformation of the AST. It's still an interpreter.
- an1sotropy 4y ago
  Well, ok, but then isn't a CPU is also just an interpreter, traversing the object code text of compiled code?
  - chrisseaton 4y ago
    We don't normally call hardware or firmware implementations an 'interpreter'. Almost all execution techniques include some combination of compilation and interpretation. Even some ASTs include aspects of transformation to construct them from the source code, which we could call a compiler. Native compilers sometimes have to interpret metadata to do things like roll forward for deoptimisation. But most people in the field would describe CPython firmly as an 'interpreter'.
    - zzzeek 4y ago
      I call it "bytecode interpreted" to distinguish it from traditional parse-tree interpretation such as Perl 5 and others
      - deleted 4y ago
        [deleted]
- zzzeek 4y ago
  so you'd call the pre-JIT JVM an "interpreter" and you'd call Java an interpreted language?
  - chrisseaton 4y ago
    > so you'd call the pre-JIT JVM an "interpreter" Yeah? I think almost everyone would? > and you'd call Java an interpreted language? Java is interpreted in many ways, and compiled in many ways, as I said it's complicated. It's compiled to bytecode, which is interpreted until it's time to be compiled... at which point it's abstract interpreted to a graph, which is compiled to machine code, until it needs to deoptimise at which point the metadata from the graph is interpreted again, allowing it to jump back into the original interpreter. But if it didn't have the JIT it'd always be an interpreter running.

mkoubaa 4y ago

This is in the process of being addressed - look into the HPy project