_vya7

For those who are not familiar with Lua, or who have heard the prevalent "conventional wisdom" about it, here's a quick clarification:

A. Lua's source code is really really small and extremely well-commented[1].

B. Lua is super easy to integrate... you can literally just throw Lua's entire source code into your app[2] and it'll compile just fine.

C. Lua's C API is super easy to use, and way more thought-out than Python's or Ruby's (no offense to Matz or Guido) -- yes, it is stack-based, but this actually makes its API much simpler and smaller than it would otherwise be. You can probably learn all of it in an afternoon (with the right guide).

D. Lua is uncannily similar to JavaScript in semantics, and the syntax[3] is ridiculously simple to learn. Semantically, it has way less magic to learn than either Ruby or Python.

E. Lua isn't only for scripting video games. I wish this "conventional wisdom" would just die. Yes, it is good for scripting video games, for the same reason it's excellent for scripting anything.

F. Table indices starting at 1 is not hard to reason about, not hard to use, and it's not hard to switch back-and-forth between Lua and languages where indices start at 0. This is a complete myth.

[1]: http://www.lua.org/source/5.2/

[2]: like this: https://github.com/sdegutis/mjolnir/tree/master/Mjolnir/lua

[3]: here's Lua's EBNF in its entirely, fitting on a single screen for me: http://www.lua.org/manual/5.2/manual.html#9

> But in the given example, shouldn't the compiler be able to see, via a simple analysis, that this function is only being applied to lists of numbers?

No, that's the beauty and curse of dynamic languages such as the Scheme mentioned here. Of course, you could do special optimizations, such as inlining bindings that never get used out of scope or defining special functions that don't operate on real Lisp data structures but plain C structures, but they add extra complexity and duplicated logic to the compiler. I'm sure those kind of optimizations would be out of scope of this article.

> in practice I have not seen any optimisation that would take that Scheme-compiled C program and turn it into one a C programmer would write

Obviously Scheme code is going to look different than C code, they're different languages. I think the point being made was that it's okay to emit some C code that's a little extra verbose, doing things like defining extra vars and such, knowing that the compiler will simplify many such things.

> There's also the question "why even generate 'superfluous stuff' if it's going to disappear anyway?"

To keep the compiler's implementation simple and understandable. The more complex output it has to produce, the harder it is to read/write/debug.

That said, I tried out VS Express the other night, and I forgot just how neat it is after all these years (last one I used was VB6). Certainly starting to prefer it over Xcode. And I'm loving Windows 8's UI/UX innovation over OS X's lack thereof lately. But the tides will change, and one day I'll probably be writing software using some awesome tools in an OS that hasn't been invented yet, by a future startup-turned-monopoly.