5 ms·

No popular language is interpreted these days outside of some specific domains where you might have an embedded scripting environment. But for all the major run

No popular language is interpreted these days outside of some specific domains where you might have an embedded scripting environment. But for all the major runtimes, even the JIT languages are now compiled. This has been true for as long as Go has existed too.

yjftsjthsd-h 5y ago
Er. Python is one of, if not the most popular languages on the planet, and its official/primary implementation is only just now moving towards JIT, having been interpreted for the previous 3 decades.
- laumars 5y ago
  It’s still compiled to byte code. It’s not been interpreted in decades. I’ll accept that the definition of “interpreter” is a little more blurred these days now that pretty much all JIT languages compile to byte code. But I’d argue that the byte code is typically closer to machine code than it is source and thus the only languages that are common place and truly still fully interpreted are shell scripts (like Bash).
  - coldtea 5y ago
    >It’s still compiled to byte code. It’s not been interpreted in decades. Its "byte code" is a not that different than the interpreter reading the lines directly.
    - laumars 5y ago
      As an old engineer who’s written a number of compilers in their time, I very much disagree with your analysis there. I posted more about my point below (https://news.ycombinator.com/item?id=30208039 https://news.ycombinator.com/item?id=30208039) little point repeating myself here too
      - yjftsjthsd-h 5y ago
        > But it seems people have warped “interpreted” to mean JIT to compensate for the advancements in scripting runtimes. That is a bastardisation of the term in my opinion. Python's not JIT, either. It reads bytecode - which AFAIK is just the source code but tokenized - and it runs it, one operation at a time. It doesn't compile anything to native CPU instructions.
        laumars 5y ago
        That’s the 2nd time you’ve posted that and it wasn’t right the first time you said it either. CPython’s virtual machine is stack based thus the byte code is more than just tokenised source code. In fact there’d be very little point just tokenising the source code and interpreting that because you get no performance benefit over that vs running straight off the source. Whereas compiling to a stack machine does allow you to make stronger assertions about the runtime. One could argue that the byte code in the VM is interpreted but one could also argue that instructions in a Windows PE or Linux ELF are interpreted too. However normal people don’t say that. Normal people define “interpreted” as languages that execute from source. CPython doesn’t do this, it compiles to byte code that is executed on a stack machine. Hence why I keep saying the term “interpreted” is misused these days. Or to put it another way, Visual Basic and Java behaved similarly in the 90s. They compiled to P-Code/byte code that would execute inside a virtual machine and at that time the pseudo code (as some called it - not to be confused with human readable pseudo code but technically “pseudo” is what the “P” stands for in “P-code”) was interpreted instruction by instruction inside a stack machine. Those languages were not classed as “interpreted”. The only distinction between them and CPython is that they were AOT and CPython is JIT. And now we are back to my point about how you’re conflating “interpretation” with “JIT”.
        coldtea 5y ago
        >The only distinction between them and CPython is that they were AOT and CPython is JIT. And now we are back to my point about how you’re conflating “interpretation” with “JIT”. Talking about conflating though, AOT and JIT mean different things in a programming context...
  - yjftsjthsd-h 5y ago
    In the context of my statement >>> Go will generally be vastly faster than interpreted languages regardless of versions. Python is clearly in the latter group. As for, > byte code is typically closer to machine code than it is source I would very much like to see some evidence; last I'd seen, it was basically tokenized source code and that's it, still nowhere near anything resembling binary executable code.
    - laumars 5y ago
      It’s compiled to a stack machine. Exactly like how a lot of AOT compiled languages originally used byte code too. Oddly enough they were never called “interpreted” languages. Which means the difference here isn’t the tech stack / compilation process but rather at what stage the compiler is invoked. I’ve written more on to your other post https://news.ycombinator.com/item?id=30215323 https://news.ycombinator.com/item?id=30215323
Cthulhu_ 5y ago
You are being confidently incorrect and making sweeping generalizations and assumptions. The vast majority of anything Javascript is still being interpreted (or as you mentioned going through a JIT interpreter), which represents all browsers and a lot of apps.
- laumars 5y ago
  The v8 engine in Chrome and node is a JIT compiler not an interpreter. Moreover it even compiles to machine code: https://en.wikipedia.org/wiki/V8_(JavaScript_engine) https://en.wikipedia.org/wiki/V8_(JavaScript_engine) You’d have more luck if you exampled Bash scripting :P If you want to be pedantic then these days even those languages that were considered “interpreted” have had their interpreters rewritten to produce byte code that is generally closer to machine code than it is the original source. So they’ve grown beyond the original definition of “interpreted” and evolved into something much closer to a compiled languages. So if think it’s disingenuous to still call them “interpreted”. And in the case of JavaScript (your example), the largest runtime in use is most definitely a compiler considering it spits out machine code. So that’s definitely not interpreted like you’ve claimed.
  - zingplex 5y ago
    V8 does actually include a bytecode interpreter called Ignition to reduce memory usage on stuff that doesn't really need to be heavily optimized.
    - laumars 5y ago
      It contains a byte code compiler. The point is that one of the stages of the compiler rather than the byte code being interpreted at runtime. In the link I posted: > V8 first generates an abstract syntax tree with its own parser.[12] Then, Ignition generates bytecode from this syntax tree using the internal V8 bytecode format.[13] TurboFan compiles this bytecode into machine code. In other words, V8 compiles ECMAScript directly to native machine code using just-in-time compilation before executing it.[14] The compiled code is additionally optimized (and re-optimized) dynamically at runtime, based on heuristics of the code's execution profile. Optimization techniques used include inlining, elision of expensive runtime properties, and inline caching. The garbage collector is a generational incremental collector.[15] Emphasis mine. So no, it is not an interpreter. It is definitely a compiler. It seems people today are confusing “interpreter” with “just in time”…

yjftsjthsd-h 5y ago

Er. Python is one of, if not the most popular languages on the planet, and its official/primary implementation is only just now moving towards JIT, having been interpreted for the previous 3 decades.

laumars 5y ago
It’s still compiled to byte code. It’s not been interpreted in decades. I’ll accept that the definition of “interpreter” is a little more blurred these days now that pretty much all JIT languages compile to byte code. But I’d argue that the byte code is typically closer to machine code than it is source and thus the only languages that are common place and truly still fully interpreted are shell scripts (like Bash).
- coldtea 5y ago
  >It’s still compiled to byte code. It’s not been interpreted in decades. Its "byte code" is a not that different than the interpreter reading the lines directly.
  - laumars 5y ago
    As an old engineer who’s written a number of compilers in their time, I very much disagree with your analysis there. I posted more about my point below (https://news.ycombinator.com/item?id=30208039 https://news.ycombinator.com/item?id=30208039) little point repeating myself here too
    - yjftsjthsd-h 5y ago
      > But it seems people have warped “interpreted” to mean JIT to compensate for the advancements in scripting runtimes. That is a bastardisation of the term in my opinion. Python's not JIT, either. It reads bytecode - which AFAIK is just the source code but tokenized - and it runs it, one operation at a time. It doesn't compile anything to native CPU instructions.
      - laumars 5y ago
        That’s the 2nd time you’ve posted that and it wasn’t right the first time you said it either. CPython’s virtual machine is stack based thus the byte code is more than just tokenised source code. In fact there’d be very little point just tokenising the source code and interpreting that because you get no performance benefit over that vs running straight off the source. Whereas compiling to a stack machine does allow you to make stronger assertions about the runtime. One could argue that the byte code in the VM is interpreted but one could also argue that instructions in a Windows PE or Linux ELF are interpreted too. However normal people don’t say that. Normal people define “interpreted” as languages that execute from source. CPython doesn’t do this, it compiles to byte code that is executed on a stack machine. Hence why I keep saying the term “interpreted” is misused these days. Or to put it another way, Visual Basic and Java behaved similarly in the 90s. They compiled to P-Code/byte code that would execute inside a virtual machine and at that time the pseudo code (as some called it - not to be confused with human readable pseudo code but technically “pseudo” is what the “P” stands for in “P-code”) was interpreted instruction by instruction inside a stack machine. Those languages were not classed as “interpreted”. The only distinction between them and CPython is that they were AOT and CPython is JIT. And now we are back to my point about how you’re conflating “interpretation” with “JIT”.
        coldtea 5y ago
        >The only distinction between them and CPython is that they were AOT and CPython is JIT. And now we are back to my point about how you’re conflating “interpretation” with “JIT”. Talking about conflating though, AOT and JIT mean different things in a programming context...
- yjftsjthsd-h 5y ago
  In the context of my statement >>> Go will generally be vastly faster than interpreted languages regardless of versions. Python is clearly in the latter group. As for, > byte code is typically closer to machine code than it is source I would very much like to see some evidence; last I'd seen, it was basically tokenized source code and that's it, still nowhere near anything resembling binary executable code.
  - laumars 5y ago
    It’s compiled to a stack machine. Exactly like how a lot of AOT compiled languages originally used byte code too. Oddly enough they were never called “interpreted” languages. Which means the difference here isn’t the tech stack / compilation process but rather at what stage the compiler is invoked. I’ve written more on to your other post https://news.ycombinator.com/item?id=30215323 https://news.ycombinator.com/item?id=30215323

Cthulhu_ 5y ago

You are being confidently incorrect and making sweeping generalizations and assumptions. The vast majority of anything Javascript is still being interpreted (or as you mentioned going through a JIT interpreter), which represents all browsers and a lot of apps.

laumars 5y ago
The v8 engine in Chrome and node is a JIT compiler not an interpreter. Moreover it even compiles to machine code: https://en.wikipedia.org/wiki/V8_(JavaScript_engine) https://en.wikipedia.org/wiki/V8_(JavaScript_engine) You’d have more luck if you exampled Bash scripting :P If you want to be pedantic then these days even those languages that were considered “interpreted” have had their interpreters rewritten to produce byte code that is generally closer to machine code than it is the original source. So they’ve grown beyond the original definition of “interpreted” and evolved into something much closer to a compiled languages. So if think it’s disingenuous to still call them “interpreted”. And in the case of JavaScript (your example), the largest runtime in use is most definitely a compiler considering it spits out machine code. So that’s definitely not interpreted like you’ve claimed.
- zingplex 5y ago
  V8 does actually include a bytecode interpreter called Ignition to reduce memory usage on stuff that doesn't really need to be heavily optimized.
  - laumars 5y ago
    It contains a byte code compiler. The point is that one of the stages of the compiler rather than the byte code being interpreted at runtime. In the link I posted: > V8 first generates an abstract syntax tree with its own parser.[12] Then, Ignition generates bytecode from this syntax tree using the internal V8 bytecode format.[13] TurboFan compiles this bytecode into machine code. In other words, V8 compiles ECMAScript directly to native machine code using just-in-time compilation before executing it.[14] The compiled code is additionally optimized (and re-optimized) dynamically at runtime, based on heuristics of the code's execution profile. Optimization techniques used include inlining, elision of expensive runtime properties, and inline caching. The garbage collector is a generational incremental collector.[15] Emphasis mine. So no, it is not an interpreter. It is definitely a compiler. It seems people today are confusing “interpreter” with “just in time”…