A computer scientist, a mathematician and an engineer… November 10, 2007
Posted by nathany in : Lua , trackbackThe Lua programming language was developed by three members of Tecgraf, the Computer Graphics Technology Group of PUC-Rio, a University in Rio de Janeiro. Not merely an academic pursuit, it was developed primarily as a replacement for SOL (meaning “sun”) and DEL (data entry language) for Brazilian oil company Petrobras.
Lua was started in 1993, near the same time as Matz began working on Ruby. It was designed to be a small and efficient scripting language that could easily be embedded in C/C++ on practically any platform.
Aiming for simplicity, Lua implements a single collection type called “tables”. PHP also takes this approach, with Arrays that can act as hashes (associative arrays) and standard arrays. Python uses its dictionaries (hashes) for namespaces and passing named parameters to functions. Lua does this and more, making extensive use of tables.
One of Lua’s precepts is to “provide mechanisms instead of policies.” You won’t find Ruby’s emphasis on object-oriented programming in Lua, but it still is easy enough to OOP. In fact, Lua works somewhat like the prototype system in today’s JavaScript.
First-class functions allow functions to be passed as arguments, stored in tables, and basically treated like any other value. Proper tail calls allow for recursion without stack overflows. Closures are a bit hard to explain without an example. You are free to make use of all these mechanisms, which originated in functional programming, a distinct discipline from the typical C-style of programming.
Lua isn’t alone in mixing programming paradigms, but its overall simplicity as a language makes it a good place to begin computer programming.
In 1996, Lua found its way into Dr. Dobb’s Journal and from there into adventure game Grim Fandango and many other games since the 1999 Game Developers’ Conference, including the ever-popular World of Warcraft.
Lua has grown in response to the demands of game programmers. It now posesses an incremental garbage collector to avoid long pauses. Coroutines provide programmers with co-operative multitasking. Lua’s virtual machine is register-based, making it one of the fastest interpreted languages available.
Due to a rather strict adherence to ANSI C, Lua doesn’t run multi-core out of the box. But Lua can take advantage of your OS-dependent threading code, having a fully reentrant API. Lua states isolate each thread, so scripters don’t need to concern themselves with the typical locking complexities of concurrency. Perhaps a future version of Lua 5.2 could see an optional library with OS-specific threading support.
If you want to dig deep into Lua’s history, take a look at The Evolution of Lua paper (26 pages), as was presented at the 2007 History of Programming Languages (HOPL) Conference. I will conclude with a quote from the paper:
“It is much easier to add features later than to remove them. This development process has been essential to keep the language simple, and simplicity is our most important asset. Most other qualities of Lua — speed, small size, portability — derive from its simplicity.”
And contrast it with a quote from Yukihiro “Matz” Matsumoto from Beautiful Code:
“When simpler tools are used to solve a complex problem, complexity is merely shifted to the programmer, which is really putting the cart before the horse.”
While there is validity to his statement, the beauty of Lua is how it manages to be a quite powerful language, despite its simplicity.
Comments»
Dang. By the post title, I thought you were going to tell a good geeky joke. I guess I’ll go back to reading Dilbert now…
“Lua 5.2 may yet see an optional library with OS-specific threading support.”
as much as i’d love to see this; i still haven’t seen any hit about that possibility.
maybe by the “mechanisms, not policies” mantra could there be an way to create a value reference from one Lua State to another? If that was possible, a LuaLane could ‘publish’ a value to be used from another Lane, with locking only on these cross-state accesses, not ALL accesses, like LuaThreads.
– Javier
On the mailing list Duck wrote:
I’m not sure what authority he wrote that with, or if it was just a suggestion. I guess we won’t know what will be in 5.2 until it comes out
.
The “mechanisms, not policies” mantra avoids tough decisions, of which concurrency brings many. A standard way to serialize data would be a step in the right direction, but there are many ways to do that as well.
For now, it’s certainly nice that the Programming in Lua book has examples of threading. I haven’t yet checked out LuaLanes, but it has me interested, at a conceptual level.