# What are the novel ideas and profound insights in the design of the 
Lua programming language?

Lua is not really about novelty. Lua is more about taking existing 
ideas and combining them into a little gem of simplicity, 
expressiveness and power. Lua is not the most innovative language, but 
certainly one of the most thoughtfully designed.

That being said, here are a few interesting design choices Lua made. 
Note that since Lua is designed by academics there are very interesting 
papers you could read about all those and to go further.

## A single data structure

There are few fundamental types in Lua and only one of them is designed 
to store others: tables. That means what in other languages would be 
arrays (sequences) and dictionaries (maps) are the same thing.

This is probably the only thing that really bothers me in Lua. 
Sequential types are something fundamentally different from associative 
types in my mind, and I have on several occasions wanted them to be 
distinct.

## First order functions, closure and true tail calls

Not going to teach a CS class in a Quora answer to explain what the 
first two are, they are found in other languages but Lua does have 
them. The last one, however, is actually pretty rare in dynamic 
languages. Some Lisps have it, but not, for instance, Python, Ruby or 
Clojure.

What it means in practice is that returning a call to a function does 
not make the execution stack grow. For instance, this code will work 
for any value of n (ignoring numeric issues) whereas in other languages 
you would have a stack overflow for large values of n:

    local function f(n)
      if n < 1 then
        return true
      else
        return f(n-1)
      end
    end

Of course this is a stupid example, but this property is actually very 
useful. One application is state machines: just represent each state as 
a function and call a state to transition to it.

## The language is a library

Lua is made to be embeddedable in a larger program (usually written in 
a static language like C). It can be compiled as a library and linked 
with that other program; standard libraries can be included or not.

Communication between Lua and its host is made via a stack, which is 
also something rare in other languages but is arguably simpler once you 
get used to it. This is also how you can write C libraries to be used 
in Lua programs.

Lua is also very portable, and to do so limits itself to ANSI C. This 
has some issues, for instance the language does not have a sleep 
function because ANSI C does not have one... External libraries solve 
that problem.

## Register-based Virtual Machine

This is actually a rather innovative point. Most virtual machines (e.g. 
the JVM) are stack-based. Lua went with a register-based VM, which 
increases the complexity a VM itself but reduces the number of 
instructions of the bytecode and the speed of execution.

## Single-thread collaborative concurrency

Being designed to work embedded in other programs or on hardware, Lua 
does not deal with multi-thread concurrency itself. It does, however, 
make sure a C program using it as a library can be multithread (among 
other things, Lua States are reentrant).

A pure Lua program can perform concurrent operations, however, thanks 
to coroutines. Again, not going to give a CS class, but coroutines are 
like green threads without preemptive scheduling. Oh, and if you are 
wondering: yes this is way better than callbacks :)

## Mechanisms, not policies

This is the core design principle of Lua: it provides powerful generic 
blocks to build upon. An illustration is metatables, which are a way to 
change the behavior of tables selectively.

Metatables are extremely powerful. For instance, Lua does not have an 
object model but you can implement one with metatables. Of course the 
drawback is that there are lots of different ways you could do that, 
and it results in a diversity of incompatible object models implemented 
by various libraries...

Metatables are not the only illustration of this principle. Lua 5.1 
kind of broke it by introducing helpers to make modules, but in 5.2 the 
authors returned to the "mechanisms" mindset by removing them and 
introducing goto which, if you think about it, clearly falls into that 
bucket (for instance it makes it easy to emulate continue).