Not so long ago the former British Prime Minister David Cameron was at the centre of a spying riddle amid claims that foreign intelligence agencies would be able to hear his every word and watch every gesture while playing Angry Birds, the game which involves catapulting wingless and legless birds to destroy green pigs trying to eat their eggs.

The disclosure came from Edward Snowden, the former agency worker at the US National Security Agency who suggested data, sounds and vision can be gleaned through mapping, gaming and social networking.

The programming language, now the industry-standard for gaming and used in a vast range of applications from embedded devices to smartphones to desktop computers, is Lua. It is certainly not something its principal architect Roberto Ierusalimschy foresaw as a danger.

Roberto is an Associate Professor in the Pontifical Catholic University of Rio de Janeiro’s Informatics Department where he undertakes research on programming languages, with particular focus on scripting and domain specific languages.

RM:

How did you get into programming? Who or what inspired you?

RI:

It was a long road. My first contact with programming was in an introductory course in computer science, in 1978. The course was taught in WATFIV (a variation of FORTRAN), and we used punched cards to do our assignments.

One year later, a friend of mine brought a Z80 box from Europe (there were very few microcomputers in Brazil at that time) and we started to program it.

That was in machine language: C3 for a jump, etc. After that, I read a book about Lisp 1.5 and I did two more advanced courses in computing; one on data structures and the other on computer organization.

I graduated in Electrical Engineering, and my first job after graduating was to write some statistical packages for the Brazilian Navy, in Fortran IV. At that time, I still did not think myself as a programmer.

For my master’s degree, I developed some hardware for a local-area network, and wrote its firmware. That was very low-level programming, in the border between software and hardware: each instruction was 40-bit wide, with each bit connected to some wire (such as a read/write bit). I also wrote some tools to help the development, in particular an assembler to code the firmware. Then was when I got a deeper interest in programming in general and in software tools in particular.

RM:

What was the rationale behind the name and why create the language? Did it start out as an academic language as so many do?

RI:

Before Lua, I had created a language that I called SOL, which stands for “Simple Object Language” but also means “Sun” in Portuguese. That language was replaced by Lua which was still nameless at that time. As we perceived Lua to be smaller than Sol, a friend suggested Lua, which means moon in Portuguese.

Lua was never an academic language, that is, we did not create Lua to do research or to write papers about it.

Back in 1993, Luiz Henrique Figueiredo and Waldemar Celes were working on some programs for the Brazilian Oil Company, and they needed a configuration language. At that time, the nearest thing we had was Tcl, but its syntax was considered too arcane for non-professional programmers, such as geologists, who would be the main users of the language.

Therefore, I joined them to develop a “generic configuration language” which could be used for their programs.

Since the beginning, Lua has had real uses and users. It took many years for me to focus my academic interests in issues related to Lua.

RM:

Were there any especially difficult problems you had to overcome in the development of the language?

RI:

Not really. The first implementation was simple, and it solved the problems at hand. Since then, we have had the luxury of avoiding hard/annoying problems. That is, there have been many problems along the way, but we never had to overcome them; we have always had the option to postpone a solution.

Some of them have waited several years before being solved. For instance, since Lua 2.2, released in 1995, we have wanted lexical scoping in Lua, but we didn’t know how to implement it efficiently within Lua’s constraints. Nobody did. Only with Lua 5.0, released in 2003 did we solve the problem, with a novel algorithm.

RM:

Lua has been a huge great success, but you didn’t implement lexical scooping until relatively recently. Why did that take you a long time? Was it a bug problem?

RI:

The usual implementations for lexical scooping demand some analysis by the compiler (such as escape analysis). Lua’s (pre)compiler must be very fast and small, so it cannot support that kind of analysis.

The other option, used by some scripting languages, is to allocate all local variables in the heap, but that is too inefficient. Only around 2001 to 2002 we came up with a novel implementation, which keeps all local variables in a regular stack and moves those accessed by closures to the heap on demand, with very little help from the compiler.

RM:

Why do you think that Lua has been such a popular toolkit for apps, video games and business middleware?

RI:

I am not sure the answer is the same for all of them. For games, I think part of the answer is more related to its implementation, not to its design: portability, small size, performance, and ’embeddability’.

Most other dynamic languages, such as Perl or Python, give much more emphasis on extending, as opposed to embedding. There is a famous white paper, in the Python community, arguing that “The only correct way to integrate Python with an application is to extend.”

And it may be right; in Python, this may be the only correct way. But not in Lua. In Lua, it is equally easy to embed and to extend; it is up to the developer to choose the best option for her project. And, in games, most developers choose embedding. Of course, those implementation features were only possible with an appropriate design. Embedding, in particular, demands that you should be able to pass all your language semantics through the eyes of a C API.

RM:

Where do you see Lua’s future lying, in scripting for example?

RI:

This one is difficult for me. I do not see big changes in the near future, and I do not believe in seeing the not-near future!

RM:

You’ve said that Scheme has been invaluable for you in the past and there’s some really good ideas with both Smalltalk and Scheme being factored into modern languages. Do you think we would be better off if we threw out everything we are working on now and began investigating how older technology could help modern technology?

RI:

I do not think we need to throw out what we are working on now, but certainly we should devote more time to studying old languages and the way of doing things.

It is amazing how often people reinvent the wheel, not in terms of implementation, but in terms of concepts. As a good example, currently we have several mechanisms that somehow substitute “closures”, such as blocks in Ruby or inner classes in Java. Many programmers never learned about the real stuff, first-class functions with lexical scoping.

RM:

What is programming to you? Do you think of yourself as a scientist or an engineer? Or something else entirely?

RI:

I do not see programming as a scientific activity, where, based on prior observation and experiments, we draw theories, and then try to refute them with further observation and experiments. There is scientific activity in a meta level, such as in software engineering that tries to figure out best practices for programming. Unfortunately, there seems to be too many theories and too few observation and experiments trying to refute those theories.

In programming proper, I see a continuous line from mathematicians to engineers to craftsmen to “builders” (someone whose main goal is to make his program work, for a very broad meaning of “work” ;). In this line, I guess I am mainly an engineer, with a deep interest in mathematics. Like a mathematician, I put great emphasis on beauty and elegance; but, more like an engineer, I put greater emphasis on simplicity and a good emphasis in pragmatism.

RM:

Are languages getting better? You designed a very successful one so you must think it is a worthwhile pursuit. Is it easier to write software because of the advances that we have made with technology?

RI:

I think, on average, languages are getting better, mostly because some not-so-new concepts are permeating more mainstream languages. However, that does not make it easier to write software, because software is becoming increasingly more complex.

RM:

What languages do you use most often?

RI:

C is by far the language I use most; that includes the implementation of Lua itself and of LPeg, a pattern-matching library I have been working on.

I also have been using Haskell for teaching language semantics. It seems an ideal language for writing “definitional interpreters”.

Of course, I also use Lua often, for all kinds of tasks, but mostly related to text processing. For instance, both the Lua reference manual and the book Programming in Lua were written in a format of our own, that is then translated to HTML or LaTeX by a formatter written in Lua.

RM:

Does every good programmer turn into a good architect? Or are there some people who are brilliant coders but only at a certain level and they should never be allowed to build a bigger design?

RI:

I would not say that someone who is a brilliant coder should not be allowed to build a bigger design; there is too much common ground. But a brilliant coder not necessarily will be a brilliant architect and vice-versa. For instance, architects do not need to be as crazy about performance as programmers are. But architects need to think about evolution in ways that programmers do not.

RM:

Can you build software that is large and works but is also a beautiful piece of code?

RI:

That is what we try hard. It is possible, but it demands lot of work, too often more than you can afford in a real project.

RM:

Is there an essential skill that’s needed to be a good programmer? Different domains obviously have different requirements but ultimately is there some commonality to writing code regardless of the domain?

RI:

I am sure there is a great commonality to writing good code regardless the domain or the programming language, but it is not easy to pin down what it is. If someone is a good programmer in one domain/language, he will be good in another. (If not, it is because he was not that good in the first field after all.

I do not know how to predict whether some student will be a good programmer. The best proxy I know is still her ability in mathematics and, of course, logic. I think ability for writing is also a useful proxy.

RM:

What books on programming do you read? What about The Art of Computer Programming? Do you read a book for a reference or do a search because it’s more convenient?

RI:

I love reading good books about programming languages, even when I do not like the language. I also like classics such as “Programming Pearls” (and “More Programming Pearls”), “The Practice of Programming”, “The Pragmatic Programmer”, “The Art of Unix Programming”. I found all these books very good reading, even when I do not agree with what they say.

The Art of Computer Programming is certainly a masterpiece, but I do not think it is a good book on programming in general. It is a must read any time you need to implement a good algorithm or data structure, but it will not help you to organize your code. (This is a good example of the difference between programmers and architects.

For references I use both books and searches. Of course searches are usually more practical, but sometimes we forget how many important texts are not in the Internet. As an astonishing example, get the C ISO specification. (I had to buy an electronic copy of it.)

RM:

Do you have any major projects lined up?

RI:

We are in the process of releasing more iterations of Lua. After that I hope I’ll have time to think about other projects.