3 ms·
> 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 ha
by 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 agoThere's a reason why C++ requires the "virtual" keyword on methods that may be overridden...