3 ms·

> interpreted language like Python/Ruby/PHP There is no such thing as an "interpreted language." An interpreter is a class of programming language implementati

> interpreted language like Python/Ruby/PHP There is no such thing as an "interpreted language." An interpreter is a class of programming language implementation. The languages you listed do not even have interpreters as their standard implementations; they have bytecode virtual machines. There are alternative compiler implementations for Python and PHP.

nostrademons 9y ago
Everybody says this - believe me, I was one of them when I was younger - but if you've ever tried to write a compiler for Python or Ruby, you'll understand why they're often called "interpreted languages". (Interpretation vs. compilation is a continuum, anyway; even a compiled language like C uses a runtime for several operations like malloc or strings, while modern JITs like V8 or PyPy can compile a trace of methods and then fall back on an interpreter for uncommon cases. Nevertheless, there's still an important distinction there: in a "compiled language" like C or Rust common syntactic forms like addition, property access, or function calls can semantically map to machine instructions or memory locations fairly easily, while in an "interpreted language" like Python or Javascript, even a property access or arithmetic operation may invoke an arbitrary, not-predictable-at-compile-time piece of code, and hence require runtime dispatch.)
- sedachv 9y ago
  > but if you've ever tried to write a compiler for Python or Ruby, you'll understand why they're often called "interpreted languages". Why, I happen to have hacked on Lisp implementations. Including Thinlisp, which is a compiler for a non-garbage collected real time subset of Common Lisp. And what you say is still wrong. An interpreter is not the same as a bytecode VM, and is not the same as native code compilation. And none of those things are a property of programming languages. The only programming languages where that might remotely be true are purely string-based ones like TRAC and maybe some of the term rewriting ones. > even a property access or arithmetic operation may invoke an arbitrary, not-predictable-at-compile-time piece of code, and hence require runtime dispatch.) If that's the criterion, then vtables make C++ "interpreted."
  - kazinator 9y ago
    > If that's the criterion, then vtables make C++ "interpreted." So do function calls; you don't know until the .o is linked where a read call will go. Unix C library? Or some local override of read? And, speaking of vtables, modern shared lib calls give obj->virtual(args) a run for its money in terms of overhead. It's worse because a vtable's structure is determined at compile time, so it's just positional referencing; a shared lib call has the referencing through a table plus string name lookup to figure out the offsets at run-time (at least the first time through).
  - nostrademons 9y ago
    There's a reason why C++ requires the "virtual" keyword on methods that may be overridden...

nostrademons 9y ago

Everybody says this - believe me, I was one of them when I was younger - but if you've ever tried to write a compiler for Python or Ruby, you'll understand why they're often called "interpreted languages". (Interpretation vs. compilation is a continuum, anyway; even a compiled language like C uses a runtime for several operations like malloc or strings, while modern JITs like V8 or PyPy can compile a trace of methods and then fall back on an interpreter for uncommon cases. Nevertheless, there's still an important distinction there: in a "compiled language" like C or Rust common syntactic forms like addition, property access, or function calls can semantically map to machine instructions or memory locations fairly easily, while in an "interpreted language" like Python or Javascript, even a property access or arithmetic operation may invoke an arbitrary, not-predictable-at-compile-time piece of code, and hence require runtime dispatch.)

sedachv 9y ago
> but if you've ever tried to write a compiler for Python or Ruby, you'll understand why they're often called "interpreted languages". Why, I happen to have hacked on Lisp implementations. Including Thinlisp, which is a compiler for a non-garbage collected real time subset of Common Lisp. And what you say is still wrong. An interpreter is not the same as a bytecode VM, and is not the same as native code compilation. And none of those things are a property of programming languages. The only programming languages where that might remotely be true are purely string-based ones like TRAC and maybe some of the term rewriting ones. > even a property access or arithmetic operation may invoke an arbitrary, not-predictable-at-compile-time piece of code, and hence require runtime dispatch.) If that's the criterion, then vtables make C++ "interpreted."
- kazinator 9y ago
  > If that's the criterion, then vtables make C++ "interpreted." So do function calls; you don't know until the .o is linked where a read call will go. Unix C library? Or some local override of read? And, speaking of vtables, modern shared lib calls give obj->virtual(args) a run for its money in terms of overhead. It's worse because a vtable's structure is determined at compile time, so it's just positional referencing; a shared lib call has the referencing through a table plus string name lookup to figure out the offsets at run-time (at least the first time through).
- nostrademons 9y ago
  There's a reason why C++ requires the "virtual" keyword on methods that may be overridden...