The design of Lua Anover view of Lua

Language design
• many tradeoffs
• similar to any other design process
• designers seldom talk about them
• what a language is not good for
Typical tradeoffs
• security x flexibility
• static verification
• readability x conciseness
• performance x abstraction
• specially in an interpreted language
Aspecial trade off
• simplicity x almost everything else
• several other conflicts can be solved by adding complexity
• smarter algorithms
• multiple mechanisms (« There’s more than one way to do it »)
Lua
• a scripting language
• simplicity as one of its main goals
• small size too
• « real » language
• many users and uses
• tricky balance between « as simple as possible » x « but not simpler »
Lua uses
• niche in games
• « Is Lua the ultimate game scripting language? » (GDC 2010)
• embedded devices
• cameras (Canon), keyboards (Logitech), printers (Olivetty & Océ)
• scripting applications
• Wireshark, Snort, Nmap
Lua main goals
• simplicity/small size
• portability
• « embedability »
• scripting!
Portability
• runs on most machines we ever heard of
• Symbian, DS, PSP, PS3 (PPE & SPE), Android, iPhone, etc.
• written in ANSI C ∩ ANSI C++
• avoids #ifdefs
• avoids dark corners of the standard
Embedability
• provided as a library
• simple API
• simple types
• low-level operations
• stack model
• embedded in C/C++, Java, Fortran, C#, Perl, Ruby, Python, Ada, etc.
Anover view of Lua
• Conventional syntax
• somewhat verbose function fact (n)
if n == 0 then
return 1
else
return n * fact(n – 1)
end
end
function fact (n)
local f = 1
for i=2,n do
f = f * i
end
return f
end

…