Engineering Philosophy: Roberto Ierusalimschy

Key Takeaways

• He designed the scripting language hiding inside an enormous share of the software you touch. Roberto Ierusalimschy led the design of Lua, created in 1993 at PUC-Rio’s Tecgraf lab with Luiz Henrique de Figueiredo and Waldemar Celes. It runs game logic in World of Warcraft, Roblox (via its Luau dialect), Dota 2 and Garry’s Mod, scripts Redis and nginx (through OpenResty), drives Adobe Lightroom and Wireshark, and embeds into devices down to robots with no operating system underneath.¹²⁷
• Mechanisms, not policy. Lua’s defining choice is refusal – it does not ship a class system, an object model, or a paradigm. It gives you a few powerful, general mechanisms (tables, metatables, coroutines) and lets you build your own abstractions on top. “Lua does not force any object or class model onto the programmer,” the designers wrote; instead they “provide flexible mechanisms” so you can build whatever model fits the application.³
• Smallness is a feature, not a limitation. The reference implementation is tiny and clean – the Lua 5.1 source is around 17,000 lines of C, the whole distribution fits on a floppy, and the built interpreter is roughly 143 KB. Most scripting languages are an order of magnitude larger; Lua stays small precisely because it is meant to be embedded, and simplicity is what makes a small, fast implementation possible.³
• Portability and embeddability were design goals from day one. Lua is written in “clean C” – the intersection of C and C++ – and “compiles out-of-the-box on most platforms,” from Linux and Windows to handheld devices and microcontrollers. A well-defined C API lets a host program fully control and extend it, which is exactly why the game industry adopted it as a near-standard.³⁴

The Principle

“We did not want to turn Lua into an object-oriented language because we did not want to fix a programming paradigm for Lua… Lua does not force any object or class model onto the programmer. Instead… we decided to provide flexible mechanisms that would allow the programmer to build whatever model was suitable to the application.” – Roberto Ierusalimschy, Luiz Henrique de Figueiredo, and Waldemar Celes, The Evolution of Lua³

Most language design is the accumulation of policy. A team decides that objects should work this way, that error handling should look like that, that concurrency means threads or async or actors – and they bake those decisions into the language, so every program written in it inherits the choices. The decisions are usually reasonable. The problem is that they are decisions, made once, for everyone, by people who could not know your application. Ierusalimschy’s instinct ran the other direction. Rather than decide for you, Lua hands you a small set of general mechanisms and gets out of the way, so you can build the policy your problem actually needs.³

The clearest case is object orientation. In the early 1990s, when object-oriented programming was at the peak of its hype, users pressed the Lua team to add classes and inheritance. They refused – not because OOP was wrong, but because fixing one model was wrong for a language meant to be embedded into wildly different applications. Objects and classes “could be implemented with tables if needed,” they reasoned, since a table can hold both data and methods and functions are first-class values.³ So instead of an object system they built extensible semantics – a mechanism that lets you intervene in how tables behave – and let users assemble inheritance, defaults, read-only views, and full class hierarchies themselves. “Extensible semantics has become a hallmark of Lua,” they wrote, and they have “not changed our minds to this day.”³

That refusal is only affordable because of three other commitments that travel with it. Simplicity – the language stays small enough that the mechanisms are comprehensible and the implementation is correct. Smallness as a feature – the whole reference implementation is around 17,000 lines of clean C, small enough that adding Lua to an application “does not bloat it.”³ And portability – writing in the intersection of C and C++ means the same source compiles everywhere from a supercomputer to a sensor.³ Give people a few sharp, general levers instead of a cabinet full of pre-decided buttons, and keep the whole thing small enough to carry anywhere. That is the principle, and everything else in Lua is a consequence of it.

Context

Roberto Ierusalimschy was born on 21 May 1960 in Rio de Janeiro, and his entire career has stayed close to one institution – the Pontifical Catholic University of Rio de Janeiro (PUC-Rio), where he took his PhD in computer science in 1990 and where he is a full professor of informatics. He did a post-doc at the University of Waterloo and a stint as a visiting professor at Stanford, but PUC-Rio is home, and the Lua story is inseparable from a particular lab there.⁵

That lab is Tecgraf, the Computer Graphics Technology Group, founded in 1987 to build software tools for industrial clients – one of the largest of which was, and still is, the Brazilian oil company Petrobras.³ The origin of Lua is partly a story about Brazilian trade policy. From 1977 until 1992, Brazil maintained a policy of strong trade barriers – a “market reserve” – on computer hardware and software, driven by a nationalistic conviction that the country could and should build its own. In that climate, Tecgraf’s clients “could not afford, either politically or financially, to buy customized software from abroad.” Buying foreign tools meant a “complicated bureaucratic process to prove that their needs could not be met by Brazilian companies.” Those restrictions, combined with Brazil’s geographic isolation from other research centers, “led Tecgraf to implement from scratch the basic tools it needed.”³ Lua is, by the designers’ own account, “the only language created in a developing country to have achieved global relevance.”³

Before Lua there were two little languages, both built for Petrobras. DEL – “data-entry language” – generated graphical front-ends so engineers could enter simulator inputs by clicking on a diagram instead of editing columns of numbers.³ SOL – “Simple Object Language” – was a configuration language for a report generator, with a type-declaration syntax influenced by BibTeX.³ By early 1993 both had outgrown their original scope; DEL’s users wanted real control flow, and SOL needed procedural power. In mid-1993 Ierusalimschy, de Figueiredo, and Celes concluded the two could be replaced by a single, more powerful language – and the Lua team was born.³ The name is a small joke that stuck. SOL means “sun” in Portuguese; a friend at Tecgraf, Carlos Henrique Levy, suggested calling the successor ‘Lua’ – “moon” in Portuguese.³ By July 1993, Waldemar Celes had finished the first implementation, built as a course project supervised by Ierusalimschy and following the Extreme Programming tenet of “the simplest thing that could possibly work.”³

The Work

Tables and metatables: one data structure, one mechanism

Start with the table, because it is the whole language in miniature. Lua offers a single data-structuring mechanism – the table, its term for an associative array – and that one structure does the work of records, arrays, sets, lists, modules, and objects.³ “Although most scripting languages offer associative arrays,” the designers note, “in no other language do associative arrays play such a central role.”³ A record is a table keyed by field names; an array is a table keyed by integers; an object is a table that happens to hold both data and methods. One mechanism, many uses – which is exactly the “mechanisms, not policy” bet applied to data.

The lever that makes tables programmable is the metatable. Normally, looking up a key the table does not have returns nil. But you can give a table a metatable – a second table that describes how the first should behave in unusual situations. The most important entry is __index: when a lookup misses, Lua consults the metatable’s __index, which can point at another table to search next. Chain those, and you have inheritance built from nothing but tables and a single redirect. The same mechanism, under different metamethods, gives you operator overloading, default values, read-only proxies, and lazy fields. None of it is a language feature in the usual sense – it is all one mechanism, used in different shapes.³

This mechanism did not arrive whole – its evolution is itself a lesson in restraint. It began in Lua 2.1 (1995) as “fallbacks”: hooks Lua called when an operation was applied to the “wrong” kind of value, so the programmer could decide what happened next.³ The table-indexing fallback let userdata and other values “behave as tables,” supporting “many forms of inheritance (through delegation).”³ Fallbacks were global – one hook per event – which made them awkward to share across libraries, so Lua 3.0 (1997) replaced them with per-type “tag methods,” and Lua 5.0 (2003) unified everything into metatables and metamethods, the form Lua uses today. (The term “metatable” was suggested by Rici Lake in 2001.)³ Each step generalized the mechanism rather than piling on new features – the same instinct that kept the language refusing to ship a class system.

Embeddability, the C API, and why games adopted Lua

Lua is not really meant to be a standalone language. The designers call it an “extensible extension language” – an extension language because it extends a host application through configuration and scripting, and extensible because it can in turn be extended with C functions.³ The hinge is a well-defined C API that “allows full communication between Lua code and external code,” built around a clean stack metaphor for passing values back and forth between Lua and the host. The API lets Lua interface not only with C and C++ but, through them, with Fortran, Java, C#, and other languages entirely.³

The payoff arrived in games, and the story is specific. In January 1997, Bret Mogilefsky – lead programmer of the LucasArts adventure Grim Fandango – told the Lua team he had replaced the game’s home-brewed scripting language with Lua, and that “a tremendous amount of the game was written in Lua.”³ Mogilefsky talked about it at a Game Developers’ Conference roundtable, and from there “Lua spread by word of mouth among game developers to become a definitely marketable skill in the game industry.”³ The fit is structural. A game engine is exactly the kind of host that benefits from an embedded scripting layer – the heavy lifting (rendering, physics) stays in fast C++, while game logic, quests, and behavior live in small Lua scripts that designers can edit and reload without recompiling the engine. Small, fast, portable, and embeddable was precisely the profile a game needed, and Lua had been built for it from the first release.³⁴

Coroutines, and a small, fast implementation

The third great mechanism is the coroutine – and like OOP, it is the team’s deliberate refusal of a policy. Through the late 1990s, users pushed for multithreading, and the obvious move was to adopt the standard preemptive, shared-memory threading model. The Lua team declined, on two grounds: implementing preemptive threads in C requires primitives “that are not part of ANSI C,” which would have broken Lua’s portability, and – more fundamentally – “we did not (and still do not) believe in the standard multithreading model,” where “no one can write correct programs in a language where ‘a=a+1’ is not deterministic.”³ So instead of threads they shipped coroutines in Lua 5.0 (2003): a mechanism for cooperative, non-preemptive multitasking where a function can suspend itself and later resume exactly where it left off.³ Coroutines give you the expressiveness of concurrency – generators, cooperative schedulers, state machines – without the nondeterminism that makes shared-memory threads so hard to get right. A mechanism, not a policy, once again.

Underneath all of it sits an implementation that is fast precisely because it is small. Lua’s virtual machine was stack-based through Lua 4.0; with Lua 5.0 it became register-based, which gave the code generator more room to optimize and cut the number of VM instructions a typical program executes. The designers note that “the virtual machine of Lua 5.0 was the first register-based virtual machine to have wide use.”³ Memory is managed by an incremental garbage collector (introduced in Lua 5.1) that does its work in small steps rather than long stop-the-world pauses – important for the real-time loops of a game.³ Independent benchmarks place Lua among the fastest of the interpreted scripting languages, fast enough that, by the designers’ account, “over 40% of Adobe Lightroom is written in Lua,” around 100,000 lines of it.³

Lua’s reach: from World of Warcraft to a robot with no OS

Add it up and Lua became the invisible scripting layer of an enormous slice of software. In games, World of Warcraft exposes its entire interface to Lua so players can write add-ons; Roblox built Luau, a Lua dialect, as the language millions of young creators learn to code in; Dota 2, Crysis, and Garry’s Mod embed it too.¹ Outside games, Redis runs Lua scripts atomically inside the database; nginx, through the OpenResty distribution, uses Lua to program the web server itself; Adobe Lightroom and Wireshark are built substantially on it; Neovim adopted Lua as a first-class configuration and plugin language.¹ And because the interpreter is small and portable, Lua reaches into hardware that has almost nothing else – the designers tell of Crazy Ivan, a RoboCup-winning robot whose “brain” ran Lua “directly on a Motorola Coldfire 5206e processor without any operating system; in other words, Lua was the operating system.”⁷ One small language, built in a Rio lab under trade restrictions, ended up everywhere – because it asked for almost nothing and gave you the levers to build the rest.

The Method

Read across DEL, SOL, the metatable, coroutines, and thirty years of refusing to bloat the language, and the same moves recur. Ierusalimschy’s method is less a slogan than a set of standing commitments.

Ship mechanisms, not policy. The defining habit is to provide a general lever and refuse to decide how it must be used. No built-in class system, no fixed concurrency model – just tables, metatables, and coroutines, from which you build whatever your application needs. The general lesson transfers far past language design: the most durable tools are the ones that grant capability without dictating the shape of the solution. It is the opposite of Guido van Rossum’s “one obvious way to do it,” and the contrast is the point – both are coherent, and knowing which philosophy your tool should embody is the actual decision.³

Keep it small enough to be correct and to carry anywhere. Lua’s reference implementation is around 17,000 lines of clean C, an order of magnitude smaller than other scripting languages, and that smallness is a deliberate feature – it is what makes the language embeddable, portable, and trustworthy. The discipline is to keep cutting until removing one more thing breaks it, which makes Lua the software mirror of Sophie Wilson’s ruthless minimalism in ARM – strip to the load-bearing essence and let efficiency fall out for free. It is minimum worthy product at the level of a language runtime.³

Resist the feature you are being asked for until you find the mechanism underneath it. When users demanded objects, Lua gave them extensible semantics; when they demanded threads, it gave them coroutines. Each time, the team declined the specific policy and shipped the more general mechanism that let users build the policy themselves – and, crucially, did not change its mind years later.³ That is the evidence gate applied to feature requests: do not add the thing because it is asked for; find out what problem it solves and whether a mechanism you already have can solve it.

Generalize, do not accumulate. The metatable did not arrive whole – it grew from fallbacks to tag methods to metamethods, and each step replaced the previous mechanism with a more general one rather than bolting a new feature beside it.³ The lesson is to evolve by unification, not by addition, so the language gets more capable while staying the same size – the same economy of means Thompson and Ritchie used in building Unix from small composable parts.

Let the constraint design the tool. Lua exists because Brazil’s trade barriers forced Tecgraf to build its own software, and its portability exists because the lab’s clients ran “a very diverse collection of computer platforms.”³ Rather than treat those constraints as handicaps, Ierusalimschy let them drive the design toward something smaller, cleaner, and more portable than a well-resourced team would likely have built – the lesson that scarcity, taken seriously, is a design tool and not an apology.³

Influence Chain

Who Shaped Him

Scheme and the Lisp tradition. The designers are explicit that “the influence of Scheme on Lua has gradually increased,” becoming “a source of inspiration, especially with the introduction of anonymous functions and full lexical scoping.”³ Like Scheme, Lua is dynamically typed, treats functions as ordinary first-class values, and keeps the core small – the conviction that a language can be powerful by being minimal rather than large. (Formative influence)

DEL and SOL, the two little languages. Lua did not spring from theory; it grew out of two domain-specific languages built for Petrobras. SOL contributed the table-constructor syntax for describing data, and the experience of both taught the team that “large parts of complex applications could be written using embeddable scripting languages” – the realization that the birth of Lua, in their words, rested on.³ (Direct influence)

Brazil’s market reserve. The trade barriers that ran from 1977 to 1992 are an unlikely but genuine influence: they are why Tecgraf built its own tools at all, and the diversity of its clients’ platforms is why portability became a first-order design goal. Policy made the language. (Formative influence)

Who He Shaped

The game industry’s scripting layer. From Grim Fandango forward, Lua became a near-default for embedding game logic, and the pattern it popularized – fast engine in C++, editable behavior in an embedded script – is now standard practice. Roblox’s Luau has taught a generation of children to program in a Lua dialect. (Field-defining influence)

Embedded and systems software. Redis, nginx/OpenResty, Wireshark, Neovim, and countless devices adopted Lua as the scripting layer precisely because it asks for so little. Few languages reach from a database to a network analyzer to a robot running on bare metal.

Language designers who prize smallness. Lua stands as the working proof that a tiny, paradigm-agnostic core can outcompete large, opinionated languages in the embedding niche – an argument that echoes through every minimal-runtime and “mechanism over framework” design since.

The Throughline

Ierusalimschy sits at one pole of this series’ long argument about how much a tool should decide for you. Guido van Rossum built Python on “there should be one obvious way to do it” and shipped batteries included – the language has opinions, and following them is the path of least resistance. Bjarne Stroustrup built C++ rich enough to express almost any paradigm, paying for that richness in size and complexity. Ierusalimschy went the opposite way from both: ship almost no policy, almost no features, just a few general mechanisms and a 17,000-line runtime, and let the user build the rest. He is the software mirror of Sophie Wilson, whose ARM won by being stripped to fewer than 25,000 transistors – Lua is the same ruthless smallness in C, and like ARM’s accidental low power, its smallness turned out to be the very thing that let it conquer a domain (embedding) nobody designed it for. Where van Rossum says here is the obvious way and Stroustrup says here is every way, Ierusalimschy says: here are the levers – you decide what to build, and I will keep the whole thing small enough to carry anywhere. (Series bridge)

What I Take From This

The lesson I keep from Ierusalimschy is that the strongest thing you can hand someone is a mechanism, not a policy. It is tempting, when you build a tool, to bake in your opinion about how it should be used – to ship the class system, the framework, the one blessed workflow. Lua’s whole career is an argument that the opposite ages better. By refusing to fix an object model and shipping the metatable instead, the language let users build inheritance schemes its designers never imagined, in games and databases and editors they never anticipated. When I build something now, the question I borrow from Lua is whether I am shipping a decision or a capability – because the decision serves the cases I can see today, and the capability serves the ones I cannot.

The second lesson is that smallness is not a constraint you tolerate – it is a feature you protect. It would have been easy, across thirty years of user pressure, to let Lua grow into a large language with a class keyword and a thread library and a standard framework for everything. The team refused, and the refusal is why Lua fits on a floppy, compiles everywhere, and embeds into a robot’s bare-metal brain. The discipline of staying small – of generalizing rather than accumulating, of declining the feature until you find the mechanism underneath it – is harder than the discipline of adding, and far more valuable. It is quality is the only variable read as restraint: the right small thing, defended for decades, becomes infrastructure that everything else can stand on.

FAQ

Who is Roberto Ierusalimschy and what did he create?

Roberto Ierusalimschy is a Brazilian computer scientist, born in 1960 in Rio de Janeiro and a full professor of informatics at PUC-Rio. He is the lead designer of Lua, the small, fast, embeddable scripting language he created in 1993 at PUC-Rio’s Tecgraf lab with Luiz Henrique de Figueiredo and Waldemar Celes. He is also the author of the book Programming in Lua and the creator of LPeg, a pattern-matching library, and co-authored the primary history of the language, “The Evolution of Lua.”³⁵⁶

What does “mechanisms, not policy” mean in Lua?

It means Lua gives you a few powerful, general mechanisms rather than imposing fixed decisions. The clearest example is object orientation: Lua has no built-in class system. Instead it offers tables (which can hold both data and methods) and metatables (which let you customize how a table behaves), and you build inheritance, classes, or any other object model yourself. The designers wrote that “Lua does not force any object or class model onto the programmer” and chose to “provide flexible mechanisms” instead – a stance they have kept since 1993.³

Why is Lua so widely used in games and embedded systems?

Because it was designed from the start to be small, fast, portable, and easy to embed. The reference implementation is around 17,000 lines of clean ANSI C that compiles almost anywhere, the built interpreter is roughly 143 KB, and a well-defined C API lets a host program fully control it. That profile is exactly what a game engine or an embedded device needs – heavy work in C/C++, editable logic in small scripts – which is why it scripts World of Warcraft, Roblox (via Luau), Redis, nginx/OpenResty, Adobe Lightroom, and devices down to bare-metal robots.¹³⁷

Where did the name “Lua” come from?

Lua means “moon” in Portuguese. It was named as a successor to an earlier Tecgraf language called SOL – “Simple Object Language,” and also “sun” in Portuguese. A colleague at Tecgraf, Carlos Henrique Levy, suggested the name “Lua” for the new language, completing the sun-to-moon progression. The whole project grew out of two little languages, DEL and SOL, built for the Brazilian oil company Petrobras.³

Sources