4 ms·

Now wait a minute. If you say that JavaScript is an interpreted language, you would also have to call Java an interpreted language. Do you agree with that? The

Now wait a minute. If you say that JavaScript is an interpreted language, you would also have to call Java an interpreted language. Do you agree with that? They both work in exactly the same way. Your source code is compiled to bytecode. That bytecode is then interpreted by a virtual machine. [1] That interpreter may then start a Just In Time compiler (JIT) to compile some of the bytecode down to machine code. Other than implementation details, both languages work the same way. Python also works like this, except it does not have the JIT. But it also has a compiler which generates bytecode. And even if a JIT generates what we fondly call "machine code", that code is interpreted too! What the CPU executes internally looks nothing like the machine code that we see as programmers. It's interpreters all the way down. [1] I don't mean in the sense of something like VMware; I'm talking about a software virtual machine that executes an instruction set which we call bytecode.

nobodyandproud 5y ago
Compilers actively translate code into a representation understandable by the machine. It just so happens that the “machine” is an abstraction of a CPU. Interpreted Javascript doesn’t fit this bill. If compiled to web assembly then it would.
- emtel 5y ago
  V8 compiles all JavaScript it executes to machine code. There is no interpreter included in v8.
  - pjmlp 5y ago
    https://v8.dev/blog/sparkplug https://v8.dev/blog/sparkplug > As we turn to improving the performance of the actual initial JavaScript execution, however, we start to hit limitations when optimising our interpreter. V8’s interpreter is highly optimised and very fast, but interpreters have inherent overheads that we can’t get rid of; things like bytecode decoding overheads or dispatch overheads that are an intrinsic part of an interpreter’s functionality.
  - nobodyandproud 5y ago
    Ignoring templates and generics, any Turing-complete language can be compiled down to bytecode or machine code. So when developers talk about a “compiled language” they really mean if the standard tooling supports a compiler; and if programs are generally distributed already-compiled. There are implications (good and bad) to programs that are already compiled, versus a just-in-time compilation via a runtime engine; which is largely transparent to developers and end-users.
kortex 5y ago
GP's point is about languages through history. Compiled-to-machine-code V8 JS came out in 2008. It's not just about compile-to-byte-code. It's about the "scriptyness" of that bytecode as well. Python bytecode operates at a much higher level of abstraction than machine code or even JVM. Also we tend to classify languages with more dynamic type systems as "interpreted". It's a nebulous boundary. Not black-and-white whatsoever.

nobodyandproud 5y ago

Compilers actively translate code into a representation understandable by the machine. It just so happens that the “machine” is an abstraction of a CPU. Interpreted Javascript doesn’t fit this bill. If compiled to web assembly then it would.

emtel 5y ago
V8 compiles all JavaScript it executes to machine code. There is no interpreter included in v8.
- pjmlp 5y ago
  https://v8.dev/blog/sparkplug https://v8.dev/blog/sparkplug > As we turn to improving the performance of the actual initial JavaScript execution, however, we start to hit limitations when optimising our interpreter. V8’s interpreter is highly optimised and very fast, but interpreters have inherent overheads that we can’t get rid of; things like bytecode decoding overheads or dispatch overheads that are an intrinsic part of an interpreter’s functionality.
- nobodyandproud 5y ago
  Ignoring templates and generics, any Turing-complete language can be compiled down to bytecode or machine code. So when developers talk about a “compiled language” they really mean if the standard tooling supports a compiler; and if programs are generally distributed already-compiled. There are implications (good and bad) to programs that are already compiled, versus a just-in-time compilation via a runtime engine; which is largely transparent to developers and end-users.

kortex 5y ago

GP's point is about languages through history. Compiled-to-machine-code V8 JS came out in 2008. It's not just about compile-to-byte-code. It's about the "scriptyness" of that bytecode as well. Python bytecode operates at a much higher level of abstraction than machine code or even JVM. Also we tend to classify languages with more dynamic type systems as "interpreted". It's a nebulous boundary. Not black-and-white whatsoever.