But the second and, in our view, most important reason was that almost nobody needed other iterators.

A camel is a horse designed by a committee.

So, we settled for a small set of control structures, with syntax borrowed from Modula (while, if, and repeat until). From CLU we took multiple assignment and multiple returns from function calls (a much cleaner concept than in-out or reference parameters). From C++ we took the neat idea of allowing a local variable to be declared only where we need it.

One of the few (rather small) innovations was the syntax for string concatenation. Because the language allows coercion of strings to numbers, a + signal would be ambiguous; so, we created the syntax .. (two dots) for that operation.

A polemic point was about the use of semicolons. We thought that requiring semicolons could be a little confusing for engineers with a FORTRAN background, but not allowing them could confuse those with a C or Pascal background. At the end, we settled for optional semicolons (a typical committee solution).

Like any language feature, it was too easy to add it (although it did complicate the lexer) and soon programmers began to use it (programmers will use any language feature).

Because the new language was a modified version of Sol (sun), a friend at TeCGraf suggested the name Lua (moon, in Portuguese), and Lua was born.

Replacing the scanner generated by lex with a hand-written one almost doubled the speed of the Lua compiler.

It is much easier to add features later than to remove them.

Our decision not to hard-code any of those possible behaviors led to one of the main design concepts of Lua: meta-mechanisms. Instead of littering the language with lots of features, we provided ways so that the user could program the features herself, in the way she wants them, and only for those features she needs.

Everyone that works with programming languages knows how easy it is for people to start "religious wars" about the subject. An interesting characteristic of those wars is that, usually, the more mundane the subject, the hotter the discussion. For instance, people get much more excited discussing semicolons than discussing higher-order functions. Of course, one reason for that is that many more people have opinions about the former than the latter. But another, more important reason is that mundane details have a strong impact in how comfortable people feel with the language. It is no use to create a marvelous, well-thought tool, if it does not have a good grip – no one will use it.

Like in Lisp, nil represents false, and any other value represents true. This is one of the few economies that we sometimes regret today.