interview
Lua
ROBERTO IERUSALIMSCHY
Roberto Ierusalimschy is one of the creators of the scripting language Lua, which
is used widely in game development and embedded systems applications. He is an
associate professor in the Department of Computer Science at Pontifícia Universi-
dade Católica do Rio de Janeiro in Brazil. (For more information about Lua, visit
http://www.lua.org.)How and where did you first become involved with
computing? Before I entered college in 1978, I had no
idea about computing. I remember that I tried to read
a book on programming in Fortran but did not pass the
initial chapter on definitions for variables and constants.
In my first year in college I took a Programming
101 course in Fortran. At that time we ran our pro-
gramming assignments in an IBM 370 mainframe. We
had to punch cards with our code, surround the deck
with some fixed JCL cards and give it to an operator.
Some time later (often a few hours) we got a listing with
the results, which frequently were only compiler errors.
Soon after that a friend of mine brought from
abroad a microcomputer, a Z80 CPU with 4K bytes of
memory. We started to do all kinds of programs for this
machine, all in assembly—or, more exactly, in machine
code, as it did not have an assembler. We wrote our
programs in assembly, then translated them by hand to
hexadecimal to enter them into memory to run.
Since then I was hooked.
There have been few successful programming
languages designed in academic environments in
the last 25 years. Although you are an academic,
Lua was designed for very practical applications.
Do you consider Lua an academic or an industrial
language? Lua is certainly an industrial language,
but with an academic “accent.” Lua was created for
two industrial applications, and it has been used in
industrial applications all its life. We tried to be very
pragmatic on its design. However, except for its first
version, we were never under the typical pressure from
an industrial environment. We always had the luxury of
choosing when to release a new version or of choosing
whether to accept user demands. That gave us some
latitude that other languages have not enjoyed.
More recently, we have done some academic
research with Lua. But it is a long process to merge
these academic results into the official distribution;
more often than not these results have little direct
impact on Lua. Nevertheless, there have been some nice
exceptions, such as the register-based virtual machine
and “ephemeron tables” (to appear in Lua 5.2).You have said Lua was raised, rather than
designed. Can you comment on what you meant
and what you think are the benefits of this
approach? We meant that most important pieces of
Lua were not present in its first version. The language
started as a very small and simple language and got
several of its relevant features as it evolved.
Before talking about the benefits (and the draw-
backs) of this approach, let me make it clear that we
did not choose that approach. We never thought, “let
us grow a new language.” It just happened.
I guess that a most difficult part when designing a
language is to foresee how different mechanisms will
interact in daily use. By raising a language—that is,
creating it piece by piece—you may avoid most of those
interaction problems, as you can think about each new
feature only after the rest of the language is in place
and has been tested by real users in real applications.
Of course, this approach has a major drawback, too:
You may arrive at a point where a most-needed new fea-
ture is incompatible with what you already have in place.Lua has changed in a variety of ways since it was
first released in 1994. You have said that there
have been times when you regretted not including
a Boolean type in Lua. Why didn’t you simply add
one? This may sound funny, but what we really missed
was the value “false”; we had no use for a “true” value.274