[1] I guess it should be faster than hand-written C, which is, of course, possible. ATS supposedly generates C code which is very competitive.

  ~/felix>flx --test=build/release --static mt
  ~/felix>time ./mt

  real	0m0.004s
  user	0m0.001s
  sys	0m0.002s

  ~/felix>time ../lua-5.2.1/src/lua mt.lua

  real	0m0.006s
  user	0m0.001s
  sys	0m0.003s

    # generates a typical set of Pick 6 lottery numbers
    x[⍋x←6?40]
    # finds all prime numbers from 1 to R
    (~R∊R∘.×R)/R←1↓⍳R
    # game of life
    life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

For some strange reason, certain misconceptions in CS/programming have half-lives measured in several decades, such as this annoying distinction between interpreters/VMs/compiled languages. We're at least 20 years out from interpreters being meaningfully distinct from VMs and compiled languages.

Compiled languages generally don't support eval. That's a pretty meaningful difference.

Python is compiled to bytecode. It supports eval. So does Smalltalk. Lua would fall into this category as well, and a whole bunch of others. I don't think "compiled" means what you think it means anymore, which is my whole point.

See my other reply (http://news.ycombinator.com/item?id=5012218). "Compiled language" is an informal term that usually means "to machine code." If you take it to mean "compiles to any kind of IR at all," then basically all languages are compiled and the term is meaningless. But that's not how the term is generally used -- for example, see the Wikipedia article (http://en.wikipedia.org/wiki/Compiled_language).

There is a real difference between languages that can meaningfully be compiled directly to machine code and those that can only JIT-compile type-specialized traces/functions (with guards that fall back to the interpreter if the assumptions do not hold).

That's my point. It's a misnomer. It's the same thing as calling technology with the ability to parse context free grammars "regexes." It's a common usage that pollutes the precise meaning of technical terms. (And at the same time, generates misconceptions based on those technical terms.)

> There is a real difference between languages that can meaningfully be compiled directly to machine code and those that can only JIT-compile type-specialized traces/functions

Well, not so much as you'd think. In theory, the ability to do things like eval cuts off a lot of direct compilation to machine code, but in practice, we know this isn't necessarily true.

I disagree (as do the books sitting on my shelf), but I'm not really interested in debating this point of terminology.

> Well, not so much as you'd think.

No, really there is. Trying to deny this isn't insightful, it's myopic. Take the C function:

  int plus2(int x) { return x + 2; }

  lea    eax,[rdi+0x2]
  ret

  def plus2(x):
    return x + 2

  3           0 LOAD_FAST                0 (x)
              3 LOAD_CONST               1 (2)
              6 BINARY_ADD          
              7 RETURN_VALUE

I expect you will want to talk about the limited circumstances where you can specialize this function ahead-of-time, thereby avoiding the fully-general implementation. This would again be missing the point. Python and C are different beasts, and this difference has far-reaching consequences on their implementations. Trying to draw an equivalence between all "compiled languages" does a disservice to people who are trying to understand the differences between them.

(Yes, most languages compile to bytecode, but people generally use the colloquial term "compiled language" to refer to a language whose implementations usually compile to machine code. JIT compilers for dynamic languages are quite a different thing because they generally only compile type-specialized fragments of code; such machine code has guards that fall back to the general-purpose interpreter if the expected preconditions do not hold.)