Why interpreters matter (at least for high level programming languages)

I've been in the compiler camp originally, simply because I found it more intuitive to translate a language into another one than interpret syntax tree data structures.<p>But recently I've started playing with interpreters and have found them very appealing.<p>There are multiple reasons for this:<p>- With an interpreter, there are <i>no separate object files</i>. So you only need to slurp the source code and call <i>eval</i> on it. This reduces workflow overhead to zero and should not be underestimated. For example, in a JS-based language for browsers, this means you don't need an extra set of scripts for a native JS environment (like node.js) for creating JS object files.<p>- With an interpreter, there's <i>no phase separation</i>. In a compiler you're always dealing with <i>expressions</i>, and you can't deal with the <i>values</i> they evaluate to. In an interpreter you have access to both, so you can do a lot more fun crazy things.<p>- With an interpreter, the implementor keeps <i>more control</i> of programs. It's simply much easier to instrument and manipulate the execution of programs when you are interpreting them than when they run on their own on the target architecture.<p>- Potentially <i>smaller code sizes</i>. In languages with macros, source code is highly compressed and irredundant - basically all boilerplate has already been stripped away by the programmer. If you compile this code, you have a huge code expansion compared to the source code.

The memory point is huge.<p>For your decently coded basic webserving app, the bottleneck is almost never your code. It is the network, databases, etc. And in my experience, the bound on how many simultaneous requests you can serve is generally not your CPU. It is how much memory it takes to have enough processes ready to handle requests. (Admittedly my experience is mostly with Perl, where multi-threaded code is a bad idea. But Python has the GIL, so again I would plan on using more processes instead of heavily multi-threaded code for concurrency.)<p>Given this, for the kinds of web applications that I have worked on, reducing memory consumption is the thing that most helps scalability.

Memory consumption for code isn't usually a big issue these days -- at least if you're programming on a mainstream computer or well-powered tablet. (Memory consumption of data keeps me up at night, but that's another issue.)<p>I've seen that some people are concerned about webapp memory consumption, and that might be very real for CGI scripts (I remember memory being primary in 1999), but working with PHP, Java and ASP.NET, I see code size as a secondary concern. Facebook developed HipHop because CPU time really is the bottleneck with PHP; and I can say that when I need to upgrade a busy PHP box it's nowhere near running out of memory.<p>Now there are embedded systems, and sometimes there it's worth making radical efforts to shoehorn things. Some people do it for work, some people do it for a hobby, but if I'm programming for fun I've got better things to do than scrutinizing my toolchain to squeeze out everything that wastes memory so I can run Linux in 8MB of RAM.

Author has recently submitted a patch to CPython which he believes will speed up the interpreter (looks too invasive and not discussed enough to have a chance of landing anytime soon IMHO): <a href="http://bugs.python.org/issue14757" rel="nofollow">http://bugs.python.org/issue14757</a>

The time required to JIT compile code apparently has a big effect on web browser JavaScript performance. Web pages often have a lot of cold code that isn't run often.<p>JavaScriptCore is getting a new fast interpreter that will be the first choice way to run code that hasn't proven hot: <a href="http://trac.webkit.org/changeset/108309" rel="nofollow">http://trac.webkit.org/changeset/108309</a>

I'm curious--by what criteria is Java a "lower" level language than, say Python? You don't really get more access to the machine with Java than with Python and both have similar reflection capabilities. Java is obviously statically typed where Python is dynamically typed, but that is orthogonal to how low-level a programming language is.

The best dynamic code compiler out there is Java Hotspot VM. Your demonstrations are just based on Python runtime. Please do a comparison with Java Hotspot for credibility.

This only applies to languages of the Ruby/Python/Lua/Javascript/etc type. If you remove a bit of dynamicity for metaprogramming in favor of compile time metaprogramming, then compilation becomes both simple and has huge speedups. As an example, see Lisp/Scheme/Clojure.