[chaoky]

The public domain CMUCL/SBCL line of compilers (as well as most commercial common lisps) are notorious for being the fastest dynamic/interactive systems since the 1990's. Most dynamic languages are still nowhere near the speed of the assembly code produced by most common lisp compilers while still retaining the impressive dynamic & incremental aspect of the language (although every year they are closing in). In the end, it comes down to how much effort was put into these compilers, rather than the language itself. For years DARPA spent loads of money on a highly trained team of compiler experts to work on CMUCL (later SBCL) led by Scott Fahlman. I doubt Ruby and Python will be able to attain JS speed until more effort goes into on these systems, which so far are still defined by a canonical, byte-code interpreted implementation.

[Solarsail]

Isn't finding what function to call at a particular function call much easier in Lisp (or Julia) than it is in Python/Ruby/JS? The vast numbers of CL and Scheme compilers are relatively easy to write, exactly because the languages leave (somewhat) less to decide / change at runtime than Python/Ruby/JS.

Edit: PL's aren't physics.

[chaoky]

Definitely not. It's almost hard to think of what Lisp doesn't let you change at runtime, since the compiler is always there. Common Lisp is in fact much more dynamic at run time than python/ruby/smalltalk. I would say that Python and Ruby are the more limited ones. You can recompile functions whenever in CL, you can even compile functions that call undefined functions at runtime. Lisp is known for its extreme late binding and reflection, with almost everything redefine-able on the fly (except functions declared inline, you need to recompile to callers afterwards. but only if you declare them inline). Even in defining classes, Common Lisp will redefine a class and update all the _old_ instances of the class as well. As far as I know, Ruby and Python do not automatically update old instances. Ruby, like Common Lisp, does allow you to add new methods at runtime without redefining the entire class, and as far as I know python does not.

> The vast numbers of CL and Scheme compilers are relatively easy to write, exactly because the languages leave (somewhat) less to decide / change at runtime than Python/Ruby/JS.

I would say it's a mistake to conflate Scheme and Common Lisp. Scheme isn't even defined well enough to say something implementation independently about whether the environments should decide things at runtime or not. But Common Lisp as a language has special/dynamically scoped variables and runtime definable macros which make it much more difficult to write a compiler for it. I would say that Common Lisp has way more things to decide at runtime than python or ruby. Maybe they're about the same in terms of difficulty of writing a compiler for, if only because lisp has no parsing/lexing pass. Again, in the end, it's mostly not a language issue. It's how much money and how many compiler experts work on your implementation.

[est]

The difference is that SBCL compiler targets x86, Python runtime targets C.

[chaoky]

SBCL targets x86, alpha, ARM, x86-64, and PPC in fact. Python doesn't actually target C, it targets a bytecode VM that's interpreted by C. which obviously is much easier to do. (there are many CL implmentations that use this approach as well eg ECL CLISP...) It just doesn't seem like Ruby or Python has the sophistication/resources yet to move their main implementations to native code, aggressively optimized compilers (yet). Which is unfortunate considering CL, Dylan and small talk got there first 30 years ago.