Hacker News Reader

Comment by haberman | Hacker News Reader

The web page rubs me the wrong way. How can you claim to be the fastest anything without a single benchmark? How can you claim to be a "scripting language" when you're statically-typed and compile to C++? What does "scripting language" even mean then? How can you say things like "it will be a bit slow the first time but subsequent runs will load much faster than any VM." Any VM? Are you really "much faster" than:

  $ time lua empty.lua 

  real	0m0.005s
  user	0m0.002s
  sys	0m0.002s

  $ time ./luajit empty.lua 

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

Maybe there's cool stuff going on here but I can't get past being annoyed at these over-hyped claims.

View on HN

Indeed. In my experience, LuaJIT is insanely fast and is widely considered to be one of the fastest dynamic languages around. The term "scripting language" is, in my opinion, meaningless these days, but either way, claiming to be as faster than LuaJIT and aiming to be faster than C (while compiling to C++? [1]) and not demonstrating this to be true just seems pretentious.

[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.

Macbook Pro:

  ~/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

What are the LuaJIT timings on the same machine also is this the proof that it is "The fastest scripting language on Earth."? Please provide your profiling results with the languages tested, the files ran and the timings.

My "good enough" definition: a scripting language is a language that does not require you to write a main() function or define a class / object in order to produce output and features automatic memory management.

So Common Lisp and Fortran are scripting languages? This test seems to be more like "Is the language heavily influenced by C or C++?"

Then add it's easy to create one-liners.

I will add this as a great qualifier, though i fear the day where someone says that APL is a scripting language ;)

I'm not familiar with APL, but after seeing the examples from Wikipedia [1], I think I know what you mean:

    # 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∘.⌽⊂⍵}

[1] http://en.wikipedia.org/wiki/APL_%28programming_language%29#...

are you referring to the "The fastest scripting language on Earth" tagline? i saw that as a way to say "look, this is a compiled language that you can use as a scripting language" with a touch of whimsical humour.

Interesting. If that's the way it is intended I missed it completely; I'd definitely be much more receptive to that line of meaning.

Python and Lua are both compiled languages, almost all languages are compiled these days. They compile to bytecode rather than native machine code, then run an interpreter which may well do on-the-fly compilation to machine code (JIT). Bytecode target makes the compiler platform independent. Felix does the same, except the "bytecode" is ISO Standard C++.

Python and Lua are both compiled languages, almost all languages are compiled these days.

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.

> 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.

> Compiled languages generally don't support eval.

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.

> 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).

> 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.

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.

> That's my point. It's a misnomer.

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; }

You can directly compile this into the following machine code, which needs no supporting runtime:

  lea    eax,[rdi+0x2]
  ret

Now take the equivalent function in Python:

  def plus2(x):
    return x + 2

Yes, it's true that this "compiles" (internally) to the following byte-code:

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

The question is: can you execute this byte-code without implementing an entire Python interpreter? The answer is no, because the BINARY_ADD opcode has to handle the case where "x" is an object that implements an overloaded operator __add__(). In this case, the user's __add__() method can be arbitrary Python code, and therefore requires an entire Python interpreter to fully and generally execute.

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.

I'm not sure what any of this has to do with the verbiage about "scripting languages," but I'd be much more interested in reading about Felix if it didn't involve so many attempts to redefine colloquially-understood terms in non-standard ways.

(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.)

Did I mention Felix is based on Cat-e-gory theory and named for the inventor of one-sided donuts?

This was pretty much exactly my reading.

Reply on news.ycombinator.com