On R performance

Isn't R much like Lisp under the covers? Afterall, it evolved from Scheme.
Hasn't there been a great deal of work done on optimizing Lisp over the
last 30 years? This suggests that instead of dropping the R/S semantics
and moving to another language like Julia, the proposals of Ross Ihaka
and Duncan Temple Lang could be followed to provide the familiar
R/S syntax on top of an optimized Lisp engine.

I think R started off as a Lisp-like language, but since adopting S
semantics, it has diverged quite a ways. I think it's better to think
of R as a combination of two languages: a dynamically-typed high-level
language, much like Javascript or Lua, and an array language, like
APL. I think those are the right places to be looking to see how to
make R fast. Fortunately, all three of those languages have had a lot
of performance work done already that R could just steal from
wholesale.

Another possibility is to implement R/S on top of an optimized virtual
machine like the JVM, LLVM, etc.

I like this in theory. But in practice, I'm not sure how well it would
work for R. JVM implementations of dynamic languages, like JRuby and
Jython run marginally faster (30-40%) than their C interpreters. You
do get the Java ecosystem, which is nice, but the performance
improvements probably aren't enough to make it worthwhile. And, of
course, R already has a pretty good Java connection story.

LLVM is a better option; I know there's another group out there
looking at R on LLVM. But I'll just note that the really high
performance dynamic languages (e.g. Google's V8 implementation of
Javascript and Mike Pall's LuaJIT) are hand-rolled JITs. LLVM-based
implementations of dynamic languages, like Unladen Swallow, have not
been particularly successful. It remains to be seen how well R would
map to LLVM.

Justin