Creator of Lua: Scripting, Programming Languages, Predictions | Roberto Ierusalimschy

Roberto Ierusalimschy is the creator of the Lua programming language. I interviewed him about Lua's unique strengths, programming language design and predictions for how AI will impact programming languages. • My ergonomic keyboard project I mentioned, you can follow along here: https://read.compose.llc/ • The Kickstarter page for it: https://www.kickstarter.com/projects/ryanlpeterman/compose-simple-ergonomics-beautifully-done Podcast links: • YouTube: https://youtu.be/jCZnFKk6M9A • Apple: https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835 • Transcript: https://www.developing.dev/p/creator-of-lua-scripting-programming Thank you to this episode's sponsor for supporting my work: • WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at https://workos.com/ Timestamps: (00:00) Intro (00:43) What sets Lua apart (08:35) Comparing Lua with Python (13:04) Top book recommendation on language design (14:20) How JIT works and why it is hard (23:21) Compiling Python and interpreting C (30:31) How cross language calls work (36:58) Lua unique design decisions (51:17) Predictions for AIs impact on languages (01:00:10) Top 3 languages to learn to become a better engineer (01:03:21) Advice for his younger self (01:04:19) Outro Where to find Roberto: • Website: https://www.inf.puc-rio.br/~roberto/ • Wikipedia: https://en.wikipedia.org/wiki/Roberto_Ierusalimschy Where to find Ryan: • Newsletter: https://www.developing.dev/ • X/Twitter: https://x.com/ryanlpeterman • LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.com/@ryanlpeterman • Instagram: https://www.instagram.com/ryanlpeterman • TikTok: https://www.tiktok.com/@ryanlpeterman Referenced in this episode: • The Evolution of Lua: https://www.lua.org/doc/hopl.pdf • LuaJIT: https://luajit.org/ • How much does it cost: https://www.youtube.com/watch?v=EUvgoxBm7uc • JavaScript: The Good Parts (not an affiliate link): https://www.amazon.com/dp/0596517742

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  It's completely feasible that you won't have programming languages.

• 0:04Ryan Peterman?

  This is Roberto, the creator of the Lua programming language, and I asked him all about programming language design.

• 0:11Speaker 00

  C++ I think is a good example of a language that it's really, really complex. JavaScript, I think, is even worse. I always joke that JavaScript, the good part, a very themed book, comparative official JavaScript book.

• 0:28Ryan Peterman?

  Given how much AI has been progressing, would you still recommend people learn computer science today?

• 0:34Speaker 00

  If you really think about that, it's really difficult to recommend people learning anything.

• 0:41Ryan Peterman?

  Here's the full episode.

• 0:46Ryan Peterman?

  In 2023, Lua was the second highest programming language by growth, according to contributors on GitHub. And I saw that it was also used in famous games like World of Warcraft and Roblox. And so I wanted to ask you, what kind of programming language is Lua and what sets it apart?

• 1:07Speaker 00

  Lua is a language that usually you use together, combined with another language like C or C++. And then you have an architecture where Lua takes care of the more dynamic part of your program, things that change more frequently, things that are not so resource intensive, the hard parts you have written in C or C++. So it's typically what is called a scripting language. There is some confusion, I think, between scripting languages and dynamic languages. And people just, I think, consider a dynamic language to be more or less the same thing as a scripting language.

• 1:53Speaker 00

  And they are not exactly the same thing. So for instance, a big difference between Lua and several other scripting languages is that for scripting, you have two typical uses. You can have the ad that I call "who has the main loop." So you can have the program written in C and calling Lua, or you have your program written in Lua calling C.

• 2:23Speaker 00

  And for several called scripting languages are actually, you don't have to, but it's much more easy to use if you have your program written in the scripting language and C languages only for your libraries. And Lua is very good fit when you want the reverse. You want the program written in C and then you have, it calls Lua from time to time. So the point is that Lua is very good at this, that you have the main loop, the program written in C,

• 3:02Speaker 00

  and then it calls Lua for some tasks or for whatever you want to do. And for instance, in games, this is very important to keep the frame ratio of the game. So for instance, you have the loop. The loop keeps the rhythm of the game and keeps everything. And then at every frame, it calls Lua. Lua's updates all characters, all images, everything in the game. And then it returns to C to do the renderization, et cetera. So it is a very good fit. But the main point is that the people sometimes call this the embedding versus extending.

• 3:45Speaker 00

  So you can extend the scripting language with C or you can embed the scripting language into C. And so several languages are very good only for extending, while Lua is really good for both embedding and extending.

• 4:05Ryan Peterman?

  Why is Lua good for embedding? And Python, it's almost the opposite.

• 4:10Speaker 00

  Because Lua, since the beginning, Lua, we thought about Lua as a library. Since the beginning, Lua was written as a library. So I think that's the main difference. Lua has a standalone program that I mean, you can call Lua in your console, in your command line. But that program is just a client of the, official client of the library, following the same API that any other program can use. So this idea of language as a library, I think it's not very common. It's something that is very particular in Lua.

• 4:49Ryan Peterman?

  When you design a language as a library, what are the unique, I guess, design decisions?

• 4:56Speaker 00

  I think that goes in a lot of small and big details. For instance, your idea of what is your global space or about scopes of variables, about the exception handling, for instance, it's very important. And it's very common in Lua that you raise an exception in Lua, but you catch the exception in C. So all these things about how you do exception handling in the language. Another, it's not a big deal, but it's, for instance, most dynamic languages, that's almost a definition of a dynamic language. They have an eval function that you can give a piece of code

• 5:41Speaker 00

  and then it executes that code. In Lua, we don't, instead of eval, we have a function that we call load that you give a piece of code and it returns a function, an internal function, like it was a Lua function, that when you call that function, then you execute the associated code. It doesn't execute immediately. So you have this clear separation between

• 6:13Speaker 00

  compiling like the Lua code that you have. And you can do that in C. So in C, you can get a piece of Lua code. You can compile it, check if it has errors, et cetera. Then you call that for, for instance, a different piece. Or you can even call several times. For instance, you can load functions from Lua into C. You keep them, I mean, in the Lua space. And then you can call that same function again and again. It's not a big difference, of course, because if you have eval, you can evaluate a function declaration and then returns that function. So you can, if you have eval, you can do load.

• 6:57Speaker 00

  If you have load, you can do eval. But I think load, it's simpler to use for that kind of thing that is when you think about libraries, for instance. In Lua, it doesn't have a global state. I think that's, I forgot that, that's a very important difference. When C starts, the first thing it has to do is to call "create a new Lua state." And then everything you do, you do on that state. And that state is completely

• 7:34Speaker 00

  independent of everything else. So C can, for instance, create another Lua state and both states are completely independent, completely. There is no communication between them. And so this again shows that,

• 7:51Speaker 00

  and so for instance, C can use a state, do a lot of stuff, and then it can close the state. And all memory used by Lua is released. Everything that Lua was using is released. And for instance, if C doesn't need to use Lua anymore for a program, you release all resources used by Lua and your program in C continues. And then later it can again create another state, et cetera. So there's, as I said, there is several small or not so small decisions in the language. But all the time we think about the languages. Is that good for embedding? Is that possible to do embedding and things like that?

• 8:35Ryan Peterman?

  When you think of the programming community generally, everyone is quite familiar with Python, but not as familiar with Lua. I thought it might be interesting to compare the two languages. So if you compared Lua to Python, what are the pros and cons of each language design?

• 8:54Speaker 00

  Lua is a language that is intended to be used in this idea of scripting architecture. So Lua, for instance, it doesn't thrive having a lot of different libraries. If you have something that, oh, I want to write a quick program for something, that Python is much better. It has all the libraries you can dream about. It has a lot of libraries built in already into the language. So the language is huge. I mean, the installation is a huge.

• 9:32Speaker 00

  Download etc. But it has exactly, oh, I need that. Oh, it's there. Yeah, I need that. It's there. And Lua is almost the opposite. Some very minimalistic language. Because they did that in that Lua into your program. It doesn't use almost any resources. Most of the libraries, the important libraries that you you will use will be provided by the program itself. Will be the comments like move a character or do some speech or things like that from the engine of of the game. For for instance, if you think about games, but whatever it is. So Lua, I think that's the the main big difference. It's that they have very different goals.

• 10:16Ryan Peterman?

  I saw some benchmarks and I saw that Lua is much faster than Python. Why is that?

• 10:22Speaker 00

  There, there. Those benchmarks are are not exactly. But I think that the main point is exactly. One thinks that Lua does have this focus on on performance. Again, in the realm of scripting languages, doesn't want to compete with C or C++. But in the real of dynamic, mostly now it's dynamic language, not scripting languages. We have some focus on performance. So I think this is a first difference. Python exactly is much more, I think, the decision that they make. Performance not that important. It's more important to be flexible, to be easy to do whatever you want to do.

• 11:05Speaker 00

  Then in Lua, sometimes we do not put some features because we think that there is no way to implement that efficiently. But also, I think some part of that performance difference comes exactly because of the the size of Lua. So most of the virtual machine fits in your cache, for instance. I think there is this two big things. One is that Lua doesn't have so many features. It's not so dynamic as Python. So in Python, there is a lot of interactions because everything can mean something else. In Lua, we are a little more conservative on that side. And but I think also this thing of being small

• 11:49Speaker 00

  also makes it naturally faster.

• 11:52Ryan Peterman?

  So on the distinction between scripting languages and dynamic, or I guess it seems like dynamic language is a superset. Scripting language is a is a subset of that. Am I understanding that JavaScript is a dynamic language, not a scripting language from your perspective?

• 12:10Speaker 00

  Yes, exactly. Yes, exactly. Because it's scripting, it canes. The the the original scripting language was bash or the shells from Unix. Of this idea that there is a language that coordinates other stuff. So for instance, it can be extending. Again, you can use. But this idea that you have two different languages. For the shell, it's only useful because you have a lot of programs written in C that are controlled by shell. So scripting language has this very strong idea that you have this idea of a dual language architecture. So switching is like, it's the name scripting.

• 12:53Speaker 00

  It means you it's like the coordinator. You you give a script to be executed by those other other things.

• 13:04Ryan Peterman?

  You gave a talk a while ago and someone asked you a question of, you know, what books do you recommend for, you know, studying programming languages? And you said, actually, that you enjoyed studying the language design of other programming languages.

• 13:18Speaker 00

  I like reading books that describe the design of of the languages. I I think the best books are those written by the author of a language about the design of that language.

• 13:32Ryan Peterman?

  What book recommendation do you think is best on language design?

• 13:37Speaker 00

  JavaScript, The Good Parts, for instance.

• 13:41Speaker 00

  It's kind of old now, but I think that I think it's a very interesting book. Although I always joke that JavaScript, The Good Part, a very thin book comparative of official JavaScript. It's like one ten of the languages, The Good Parts. But but I think that book is really interesting. Like, because exactly it it discussed the language. It discusses even the bad parts and it focuses on the good parts, but then explains why it's there, why it it was made that way, etc. That is a book that I like.

• 14:20Ryan Peterman?

  When we were talking about Lua, it sounds like one of the things that sets Lua apart is the performance and how minimal it is. And when I was reading about Lua, I saw that there's Lua Jit. How does the Lua Jit work?

• 14:34Speaker 00

  Lua Jit, the first thing, it's completely different project. It doesn't have anything to do with us. But it's an incredible piece of of software that is is a just-in-time compiler for Lua. That's and I think exactly one of the reasons it works so well on top of Lua is because of the simplicity of Lua. It's a very regular language. I mean, it has a very, as I said, it doesn't have many exceptions or too many interactions or things that. So it's not that dynamic. I mean, everything can mean something completely different.

• 15:16Speaker 00

  So that I think that gives a very good language for Jit. But the the the Mike Paul is the name of the the guy that made the. I think he's still working on that on the first Lua Jit. He's it's unbelievable, his work.

• 15:33Ryan Peterman?

  What makes writing a Jit difficult?

• 15:36Speaker 00

  The first thing that for me, I don't want to get involved with Jit is because it's machine dependent. It's not very productive. I mean, you you do a lot of work and it only works on that architecture. And then, oh, I want to run in another architecture. But Mike Paul, he created a kind of a pseudo assembler that he writes in this assembly. And then he translates that assembler to real machine code of the different machines. So trying to unify the different architectures. So there is a lot of, but I I don't like. I I think architecture, I I like to study,

• 16:19Speaker 00

  but I don't like to to to to work with because I think it's very unstable. Each new version, they change that or they change that. The I mean, they they change the ADI for something. And then now the stack has to be aligned in some various particular way. And so and of course, also to to get that performance that he gets. He made what's called the trace compiler. The idea of a trace compiler that instead of getting a function and compiling a function, it goes, it it works like any Jit that it tries to detect things that are executing frequently.

• 17:03Speaker 00

  And so it starts what's called the trace. It it gets recording everything that the code is doing, including function calls, etc., until it closes the loop. And then it compiles that loop, including function calls, etc., everything in line. It compiles that for that specific, for instance. So that number happened to be an integer. So it compiles if the number will be an integer again. And there is a lot of checks, just check if everything is as assumed. And then it executes the loop. And then it's very, very, very fast. But anything that is different, for instance,

• 17:48Speaker 00

  you call again that, you call it frequently with integers. Suddenly, you call to with a float. Then at some part of the code, it's it is, it breaks the the the condition and you have to to return to the interpreter part. And I think that's one of the worst parts is that you have to translate the state that it's all compressed into register, etc. For instance, you don't even have a call stack because you didn't did the call, you didn't do the calls. You just inline it. But then, oh, something went wrong. Now you have to continue interpreting. So you have to recreate the stack that you didn't create originally, etc.

• 18:33Speaker 00

  So I mean, even even to think about that, I have headaches.

• 18:40Ryan Peterman?

  Standard Lua is portable, but to execute on a machine, it eventually gets converted into machine instructions somewhere. Where in the stack is it eventually translated to machine instructions?

• 18:52Speaker 00

  Lua is written in C. The interpreter is written in C. And then you so you you compile that into machine code, the interpreter, the Lua code. Then the point when you get some some, I mean, the Lua code, the Lua interpreter code. When you get some Lua code, you do what is we call a pre-compilation, that is, we we translate to an internal language. And then the interpreter is just a big loop. It's a loop with a switch. I mean, that's a very big simplification, but in in general terms, a loop with a switch that get instruction, does a switch and see, oh, this instruction is.

• 19:36Speaker 00

  The instructions are quite similar to a CPU. Move that, but then instead of creating it, executes that instruction. Move move A to B. So it it does a move A to B and executes that. And again, repeats, execute the next instruction. So this is how interpreter works. And basically, so we we pre-compile Lua. There is a compilation, but we compile it for this virtual machine. And then you have this main interpreter loop that people call that just fetch it instruction. So a jump is just a jump.

• 20:18Speaker 00

  You have an array of of byte codes, a jump, or just go to that. You have a counter that tells where you are in this array. A jump, you just update that counter. It goes to another position of that array where you're going to. So it's like you you emulate the CPU in in software. It's written in C, the the interpreter. This main loop is written in C. So if you compile it in Linux, it will run in Linux or in a x86 architecture. It will run in that architecture. If you compile that in the Mac, it will run in the Mac. It's a C program.

• 21:00Ryan Peterman?

  Got it. Okay. So and that's, that's the part that's not portable and the C compiler handles that.

• 21:05Speaker 00

  Yes, yes, yes. All portability of Lua comes on top of portability of C.

• 21:12Ryan Peterman?

  How does JIT compared to ahead of time compilation in terms of performance?

• 21:17Speaker 00

  Both ahead of time, any kind of compilation is easily, not easily, but it can be 10 times faster than interpreting, or even 100 times faster than interpreting, depending what you are doing. But 10 times is a very good figure. Between ahead of time and trace compilation, then depends a lot of what you are doing. After trace compilation is particularly good for benchmarks.

• 21:53Speaker 00

  Because you're repeating it more or less, they are very uniform. You're doing exactly the same thing again and again and again. So then trace compilers shine. They, I mean, this is the best they can do. In real programs, that depends a lot, but, but, but you, I wouldn't say there is a clear winner between the two. I think depends a lot of the kind of program.

• 22:20Ryan Peterman?

  Is it possible to write an ahead of time compiler for Lua?

• 22:24Speaker 00

  Yes, there are, there are several. None, I mean, I, I don't, I'm not sure if there is anyone on production quality, but for research, et cetera, there are several. I, I have a student who won't run like a master thesis. Ridiculous, simple Lua compiler, ahead of time Lua compiler, or something like that exactly. Because it was just, it gets this upcodes and expands into, into C code. And then you send that through, through a C compiler. And then you have a head of time, head of time compiler for Lua.

• 23:07Speaker 00

  And it gave like three, five times boosting performance. It's a very, very, as the title says, like ridiculous, simple compiler.

• 23:21Ryan Peterman?

  I always hear there's, there's compiled languages and there's dynamic or interpreted languages, I guess. But really that distinction is in the tool chain, not necessarily in the way that the symbols are laid out on the source code. Like I could write a compiler or a program that takes in Python code and then converts it into machine code and then I would have compiled Python.

• 23:46Speaker 00

  And you can interpret C code too. You can write an interpreter for C. Yes. But the, the main difference is exactly what it's easy to, for instance, as I said, one of their hallmarks of interpreted languages, the eval. So if you want to compile the language and keep eval, you have to have a compiler as a library of your, of your runtime. Because you may want to compile things during execution. This is the hallmark of a dynamic language. That's all. You can create code while running code.

• 24:25Speaker 00

  So that part is, that, that's why more, much more often than not,

• 24:35Speaker 00

  dynamic languages are interpreted. But you can compile, but then sometimes for some compilers do not handle eval at all. They say, oh, you can compile as long as your program doesn't have evals. So there is some restrictions. And as I said, you can interpret C code, I mean, but you be extremely slowly with, it doesn't, but.

• 25:02Ryan Peterman?

  I think one big difference, and when I look at statically, or you know, static languages or compiled languages, they, they seem to have type systems in them or the type annotations. What is the role of a type system in the compilation process?

• 25:18Speaker 00

  Depends a lot of the, on the type system. Several type systems, like in C, for instance, are written to be a very important part of the compilation process. So if you have the right type system, it's much, much easier to write a compiler. A trivial example is one, the space for variables. Because if you know, oh, this is an integer, this is a float, this is a double, you know exactly how many bytes of memory you need to that. Otherwise it's a mess. More often than not, you have to keep everything in the heap dynamically allocated.

• 25:59Speaker 00

  And so huge penalty in performance. And for instance, when you see, as I said, a trivial, you have an addition.

• 26:10Speaker 00

  A plus B. If you know the type of A, A plus B, you have the type of A, the type of B. You have a compile time, you know, oh, this plus is a, I'm adding two integers. I just generated the machine code through add integers and there everything is fine. In a dynamic language, I see A plus, I don't, I, I, I compile to a, in the virtual language, it's just a piece of plus. But then how do I, at runtime, you have to check what is A. Oh, A is an integer, B is a float. Oh, I have to convert or B is a string or depending on the language. You're, if you're not doing addition, it can be doing concatenation or you can just calling some of,

• 26:54Speaker 00

  and you have to draw that at runtime. So types can be very, very important to compile efficiently. But of course you have to have a type system that, that there are several languages now like TypeScript, that the types are a kind of, you do not guarantee that everything has the type you said they have. So then it's impossible to use them to compile because oh, probably A will be an integer. But if it's not, I mean, it's, if it, I have an integer register to boot, it must be a register or things do not work.

• 27:39Speaker 00

  So, but if you have the right type system, they are essential for a good compilation.

• 27:46Ryan Peterman?

  I know some programming languages have type inference. What if you did, you ran type inference and you got a unambiguous set of types? And then you use that in compilation, like, could you do that for Lua?

• 28:00Speaker 00

  No.

• 28:03Speaker 00

  I mean, that's not computable, but a lot of people try to, to do in typing inference for dynamic languages. And it's really hard problem and it's very difficult to do anything useful in terms of performance. What you sometimes you get, but you have a very strict, if you write your program in that specific way, you follow. So it's like you don't have the type, but you write the program thinking about type. And then if the program is that very particular format, then you can do type inference and everything goes well.

• 28:48Speaker 00

  Otherwise either type inference doesn't work or, I mean, it works, but it actually it infers very generic types for everything. And so you cannot take advantage of, of the types. Because exactly the dynamic nature of the language, this, this also happens with Lua JIT, for instance. You can get much, much better performance if you have a kind of a type system in your, in your mind. Usually we do that and you, and you follow that type rules even without, I mean, the compiler, the language does not impose them on you, but you assume, oh, I'm going to follow those some time discipline.

• 29:33Speaker 00

  I'm not going to, to, to use the same variable to store integers and strings, et cetera. And then you can have much better results.

• 29:43Ryan Peterman?

  OpenAI, Anthropic, Cursor and Vercel all use this product to make their lives better. And the problem it solves is when you're building SaaS or an AI product and you want to sell to other companies, there's all these requirements you need to meet. There's SSO, there's SCIM, there's RBAC, there's audit logs. These are all things that take time to integrate, but aren't the main focus of your app. WorkOS is an API layer that lets you meet all of these requirements in just a few lines of code. So let's say you have a new SaaS product and you want to sell to other companies. WorkOS will solve all of these critical feature gaps for you. You can check them out at workos.com to learn more and get started.

• 30:25Ryan Peterman?

  And I appreciate them for supporting my work and sponsoring this podcast. Earlier you mentioned that Lua can call C and C could call Lua. And you mentioned, we, we talked about the, the compiler and the interpreter. And how do these pieces work together in the case where you're chaining different programming languages?

• 30:47Speaker 00

  Yeah, the, the main trick, I mean, it's not a trick, a technique for Lua calling C is C pointers.

• 30:57Speaker 00

  Function pointers, there is a pointer to a function. This is part of the official C language. So when you start Lua, suppose you are in C, as I said, you create a library.

• 31:14Speaker 00

  You create a state, a Lua state, and then you can register, you send to Lua C pointers, function pointers, I mean, pointers to functions in your C library associated with names. Lua stores that in some data structure.

• 31:32Speaker 00

  Okay, so it says, oh, the function sign is associated with that pointer, etc. So when it's doing the interpretation, oh, this instruction is called. Instruction called, oh, let's see what it's calling. Oh, it's calling A. What is the value of A? Oh, it's a pointer to, and then it calls that pointer. And then we did call the C function to do that. And when C wants to call Lua, I mean, a Lua function is just a data structure from the point of view of C, it's just an array of byte codes, of upcodes.

• 32:14Speaker 00

  And then it calls the Lua interpreter function. Do please interpret that function for me. So C can call Lua to interpret that function. And that function is running and then can call a C function using a pointer. And you can have that in the stack at several levels. So we are running a Lua function that calls C and C calls Lua again. And Lua calls C. You can have recursive stuff in that, etc. And everything works. It just works.

• 32:48Ryan Peterman?

  In one of your talks on Lua, you mentioned that there's security benefits to using a scripting language. What are those benefits and how does it protect the hardware?

• 32:58Speaker 00

  It's not only hardware. Once I gave a talk here in Brazil, I was called to give a talk in a Py conference. A PyCon, they called it, a Python conference in Brazil. They called me for a talk. At the end of the talk, I said, oh, Lua, we use it as a scripting language. As I said, emphasizing that thing that you have this dual language architecture. And I know of case of Lua being used in C, with C++. We fortran with several different languages. And then someone in the audience says, oh, we also use Lua for scripting Python programs. And what was the case?

• 33:42Speaker 00

  They have a huge Python program for financial stuff that has do a lot of financial transactions, etc. And they wanted to do script, I mean, to have like a common line where you could write instructions to be executed by the, at runtime, for instance, for debugging or for inspecting, for whatever you need, some kind of end user programming. But they said exactly what I was talking about spaces. In Python, basically, if you have a common line and you are going to run Python,

• 34:22Speaker 00

  that Python can do whatever it wants to do in your program. There is no way to protect it. So if you gave that to the user, the user could do whatever it wanted to do. I mean, for the program. So the program would break a lot of invariance of a lot of important stuff in the files it kept, etc. And so what they did, they gave the thing in Lua, because as I said, as Lua, you create a state. For instance, as I just mentioned, you can only call C functions. That is true in Python again, but in that particular case. You can only call C functions if you give the C pointer to Lua.

• 35:07Speaker 00

  So have a very strict, and there is very, as I said, there is a library. When you create a new state, it has no functions at all. There is nothing, I mean, you cannot open files. Everything there are, we call standard libraries. Usually you open a state and you register those standard libraries in Lua. So you have the minimum, like you have mathematical functions, etc. But it can open a state and has no functions at all in Lua. It can only do things calling those specific functions you gave. So they use Lua to have this kind of control.

• 35:49Speaker 00

  Oh, you can write Lua code here, but that Lua code can only do very specific things in the Python program. It cannot call any Python function or, I mean, build any kind of Python data structure, etc. So was this a nice example? In the case of hardware is the same thing. You cannot just go in, for instance, there is a port, a hardware port that controls the speed of the fun that keeps the temperature of the CPU. And if you put that very low, you can really burn the CPU. I mean, because the CPU gets very hot. And so you have a C, you cannot call C directly.

• 36:33Speaker 00

  You must call Lua and only Lua has access to that. So if you can only program in Lua, it's, oh, Lua, then you check whether the numbers you are giving are precise or whatever it has to check. And then it calls.

• 36:51Ryan Peterman?

  It's kind of like a sandbox environment.

• 36:53Speaker 00

  Yes, exactly, yes. Sandbox is the exact word for that.

• 36:58Ryan Peterman?

  I saw there's this, I guess, paper, or maybe it was an article you wrote on the history of Lua with several other people. I thought there were some interesting quotes in there I kind of wanted to ask you about. So one of them, it says that there's this old joke that says that a camel is a horse designed by a committee.

• 37:20Speaker 00

  Yes, that's not mine. That's a real old joke.

• 37:25Ryan Peterman?

  Does that mean that you think the best programming languages are designed by as few people as possible?

• 37:33Speaker 00

  Yes, I do think, yes. Because one thing that it's easy to observe is this. If you have a committee writing a language, everyone wants to put something from themselves into the language. So you have that, your favorite mechanism. And you will fight whatever it takes to put your favorite mechanism into the language. And very few people will fight against putting anything in the language. I mean, some people say, oh, no, this is too much, this is too complicated.

• 38:15Speaker 00

  But people fight much more fiercely for to put something they want in the language than against putting something in the language. So when you have a committee, the tendency, so let's keep adding stuff, let's keep adding stuff. And people sometimes even do not understand, I mean, even not sure if everybody there is really know the language well, or I'm not putting that. But that fits with other parts of, oh, I didn't even know the language has this other part. I mean, so things sometimes do not fit together very well, etc. So first you have what's called the conceptual integrity.

• 39:00Speaker 00

  It's a name that gives that everything fits together, everything, it's designed with everything else in mind, etc. It's much easier to, I'm not saying, I mean, Lua has several wrong stuff regarding, because with time, etc., there you make mistakes. But it's much easier to get things right if you have a small group of people that everybody knows what everybody else is thinking. I mean, you are deciding whether to put something in the language or not. It's much easier to change your mind if you do not put something. And then later you decide to add it to the language.

• 39:45Speaker 00

  Then to add something and then later you decide, oh, I shouldn't have. But that was not a good idea. So when in doubt, or the fault is always, don't put it. If you're not very sure, don't put it. We can always add that later. And so keep the door open to change your mind.

• 40:08Ryan Peterman?

  I saw in the original Lua programming language that there was no Boolean type. And I've never seen that before. Why was there no Boolean in the original Lua?

• 40:19Speaker 00

  Well, C doesn't have Booleans. I mean, the original C and C90, up to C99, they use integers. If it's zero is false. If it's different from zero is true. And people lived quite well with that Lisp. And there are several languages that don't have Booleans. And actually, we only put Booleans in Lua because we wanted false. True is completely useless in Lua. Nobody use true, I mean, nobody is a joke, but it's too strong. But it's not very useful. You can use almost any other value for true.

• 41:04Speaker 00

  But the problem is that in Lua, the nil, that special value, nil, is in a table, it is equivalent to the key not being present.

• 41:20Speaker 00

  You always think whether that was a good decision, but it's very embedded in the design of the language. And it has this strong concept that a table, a key that is not present in a table, there is an associative array, it has a nil value. It's completely indistinguishable whether it's absent. I mean, absent means it has a nil value. Nil val means is absent. And so sometimes you want to have a false value, but you want to know it is there in the table. And so we needed a false to have a false. You can put in the table and it's completely different from being absent.

• 42:04Speaker 00

  You know, there is a key and the key has a false value. So we needed a false value. And if you're going to have a false, then we added true to it. It would make sense to have false without true. But with true, it's almost useless.

• 42:22Ryan Peterman?

  Why not use zero as false if you're okay with one as true?

• 42:27Speaker 00

  It could, we could have used, but that, among other things, that would be a big change because exactly it didn't was that way. So we added that later in the language. So changing zero to false would be a very big incompatibility. But it could be, for instance, in Python, I think a lot of stuff are false. I mean, zero is false, empty list is false. And in JavaScript, I think it's even worse. I don't recall exactly, but I mean, this is kind of arbitrary. I mean, you could have, for instance,

• 43:10Speaker 00

  nil, false, zero, empty string. I mean, it just depends the kind of test that you use. It's not, in dynamic languages, it's very easy.

• 43:22Ryan Peterman?

  Python has the, like you're describing, the truthy values and the falsy values. I guess they can be interpreted as false. And, but it's, it's more implicit, less explicit. And I know JavaScript is even further on that spectrum where you can do some really weird stuff that implicitly has some behavior. Do you think that design direction is good or bad?

• 43:48Speaker 00

  It's like, it's more compact. It's more easy to write stuff. And, but you always have this balance in any languages, almost anything. The more flexible you, the more flexibility you have, the less protection you have. In C, you have something like that. People do not notice, but because C is typed. But you can check whether an integer is true or false. You can check whether a float is true or false directly because again, it checks whether the float is zero or different from zero. You can check whether a pointer is nil

• 44:32Speaker 00

  or different from null because in C, null is a magic zero. So it's kind of, if you do not write any test, it has an implicit test like different from zero. And this zero can be an integer, can be a float, can be a pointer. So in C also, you have this kind of flexibility. It's just that you have to be more explicit usually. This avoids errors. But so this, you have always this balance between easy to write and easy to make mistakes.

• 45:10Ryan Peterman?

  I saw that Lua is one indexed instead of zero indexed. And I, I had never seen a programming language like that in my experience.

• 45:20Speaker 00

  There was a lot of programming languages like that.

• 45:23Ryan Peterman?

  So yeah, why, why is it one indexed?

• 45:26Speaker 00

  Because everything in the real world are one indexed. If you have a book, you have the chapter one, chapter two. Nobody numbered chapters as zero, one, two, three. Only programmers are the only, even mathematicians. If you got a mathematic book, a book of mathematics, any sequence, it's a1 and a2, a3. If you have a matrix, the first element is a1, 1, a1, 2, and then a, everything is written with one. Only in programming language, that is this idea of zero. And the funniest part is that, for instance, Fortran, that now it's, it's very old language, but indexed from one.

• 46:12Speaker 00

  In Pascal, you can choose. I mean, you write an array. You can say this array is indexed from minus five to five. And so it's, it's indexed from whatever value you want to, whatever value you want. Zero became extremely popular because of C. C uses zero and a lot of languages copied, are kind of inspired by C. They have the same operators, the same syntax for expressions, the Boolean operators, for instance, that is not standard mathematics. Almost all languages chose the same operators

• 46:57Speaker 00

  that they are written in C. And so a lot, a lot of languages copied C and then zero indexed became very popular. And what is funny is that in C, there is no indexing. In C, indexing is just an illusion because what you have is pointer arithmetic. And C, when you write a indexed by i, actually what you are saying, get the contents of a plus y. And so because in C, you don't have indexing, you have this displacements or deltas. I don't know how offsets.

• 47:40Speaker 00

  Then it not having indexed by zero because of the, because, then the first element is the element that is at the original address. So C doesn't have indexing. So when you say is indexed by zero, it doesn't index by zero because it doesn't index by anything. But it, it have this illusion of indexing and then it's easy to syn that in. And then a lot of language that do not use pointer arithmetic, do not have this restriction, do not have this semantics, copied C and kept the zero indexing as this thing. If you get a 12-year-old and try to explain to them zero indexing,

• 48:25Speaker 00

  I assure it's much, much easier for them to write, oh, I have a list of the first element. I always joke that the first element is zero. And you write first, you for one, but the first element, one, is not one, is zero. So it has advantages zero. For some specific operators mathematically, for instance, you want to do a circular buffer, zero is better. There are some small advantages, but it's much, much more confusing. And as Lua has this idea of end user programming,

• 49:07Speaker 00

  we always joke, it's much easier to make life easier for the non-programmers. And I am sure that programmers can program whatever index they have to do because they are supposedly, they are professional. They can learn that, oh, indexing from, then to put on the end user the burden of using something completely different from them indexing by zero. What does it mean the element index zero? I never saw, oh, the chapters in the book. Yes, the first chapter is at zero. The second chapter is at one. No, I'm not joking. When you try to explain that to non-programmers,

• 49:50Speaker 00

  even don't, then they need to be 12-year-olds. I mean, just get anyone that is not. And then programmers think, oh, I have the absolute. You are grown up. You are, I mean, okay, you are a wisdom. You are, if zero, I'm sure you can learn to program if one or minus one or whatever it is, the base you have to use, I'm sure.

• 50:16Ryan Peterman?

  But do you think you see a lot of bugs? Because maybe someone thinks it's zero.

• 50:22Speaker 00

  Unfortunately, I see some bugs. But as I always say, that are the kind of bugs that just shows that you didn't do minimum testing. Because that kind of bug is not a kind of, that kind of bug that, oh, if you tried, anything you try to do in an array, if you start from zero or start from one, you have a bug. So the most simple test that you can imagine to test anything related to an array, to a list, etc. If you mistake zero to one, you detect that.

• 51:08Speaker 00

  So if you have that kind of bug, it just shows that you didn't. Task that called arrow.

• 51:17Ryan Peterman?

  There was this talk that you gave on the cost of adding language features to Lua and how there's a lot of hidden costs. And I think today implementation costs of software is going down due to, you know, AI code generation or L L Ms. And I was wondering if that changes your thinking on, I guess, the cost of adding features to a programming language.

• 51:43Speaker 00

  AI is something that we don't really know what is going to happen. If you go to an extreme,

• 51:53Speaker 00

  it's completely feasible that we we won't have programming languages. And I mean, because if the AI is writing all your code and is checking all your code and doing everything in a few years, maybe we don't need programming. AI can write machine code directly. It doesn't need programming languages.

• 52:17Speaker 00

  It's easier for them to compile or even generate the code directly. I mean, I don't know what's going to happen in a few years. So I think it's very hard for me to talk anything about AI because I have, and I think nobody have a clear idea what, I mean, people have a maybe a clear idea what it happens in one year or two years. But in five years, I, I mean, anyone that says, oh, that's going to happen in five years. It's just, I mean, just guess. So I, I think it's hard to, to say anything. This is all because of AI.

• 53:02Speaker 00

  So keeping the minimum thing, I mean, that still have, for instance, they're all, why you still use programming languages? Because you want the user, or that's some human to be able to check the result of what the AI is doing, et cetera. So I still think that most of the things about programming language still hold. For instance, the, the, the cost of complexity of you understanding. I mean, AI create a code for you and then you really understanding what that code does. I mean, it's even worse. I mean, it's much more important that the language be clear

• 53:43Speaker 00

  and, and it has a, not no hidden mechanisms. Because the AI may use a hidden mechanism. It doesn't have the concept, oh, that will be difficult for a human to understand that what is really happening here is, is something, et cetera. Something that, for instance, oh, I can use that, but I'm for sure it's going to put a comment here. Because I'm sure that someone that reads that in one month, it's not going to understand. EA doesn't have that kind of, of, of thinking. And so we just use that, that trick or that thing. And it's so, I think the AI, if you think about this idea of AI generating code,

• 54:27Speaker 00

  I think it's even more important for the language to be simple, to be understandable, for you to be able to really understand that the code that you are seeing does what you think it should, it should do. It really understand what the code is doing. So this thing about simplicity, I think it's, it's very important. And I, I think the other parts from the need, maybe AI may facilitate documentation. I'm not sure if, I mean, this thing about conceptual integrity, for instance, to keep things, oh, that makes sense, et cetera. I really think the, one of the main costs is that it's the, the, the burden

• 55:11Speaker 00

  you put on the user to learn one more thing about your language. So there's the other cost of it. I have said that implementation is the, that is the, the part that AI can really help you. It's not a really, a really important cost.

• 55:32Ryan Peterman?

  If you think about like a spectrum of simple to complex, what programming languages are, you know, the most simple ones that you think of? The easy to understand, less confusing side effects? And what programming languages are the most complex and have the most foot guns?

• 55:50Speaker 00

  This, this famous quote also of, I don't know from whom, that the simplest possible, but not simpler than that. Because if you go to the extreme of simplicity, you could get, for instance, Lambda Calculus or Turing Machines and said, oh, that's really simple. I mean, this is really simple, but it's completely impossible to, to write any program. And that, I mean, if you have really simple stuff, I think the extremes will be like that, but you don't want to be there. But to the other side, I think C++ I think is a good example of a language that I think it's really, really complex.

• 56:33Ryan Peterman?

  A question that comes up a lot is, given how much AI has been progressing, you know, would you still recommend people learn computer science today?

• 56:43Speaker 00

  If you really think about that, it's really difficult to recommend people learning anything for a profession. And we have no idea what AI will do in five years. If someone is entering university now, they're going to graduate in four years, five years, or at minimum three, three and a half years or. And nobody have any idea what it's, what the, your profession will be like in, in four years from now. So it's really hard to, I mean, to say, oh, yes, you can, you still going to, because now people say, oh, no.

• 57:24Speaker 00

  The, the, the manual tasks, the AI is very good, but it's you need the, the whole architecture. You needed a, like a software engineer to do, to see the big picture, et cetera. That it's now, but you have no idea that, that will be true in four years or five years. So I think, and I like, I enjoy programming. I, I could do, I mean, some people say, oh, use AI for the AI program because I like that. But exactly, but so if you choose something that you like, but really for if you're really thinking, how am I going to live with that? I have no idea. It's really, I think it's a really

• 58:08Speaker 00

  hard time to, to, to be choosing the profession.

• 58:13Ryan Peterman?

  I mean, you've worked on Lua for such a long time. When you look back on it, what went well and what didn't go well?

• 58:22Speaker 00

  We have this privilege of not having to satisfy clients. So we do not have, as I said, for instance, you can choose to add some feature to the language because you do not have a pressure, oh, we need that feature, that feature, whatever it takes or et cetera. So we have this privilege of, oh, we are not sure whether to put that. We don't put that, you can wait one year or. So I think that it's, it's much easier to do a, a good project, a beautiful project. So I'm not, I'm not sure this is a recommendation. Try to work without much pressure. People usually do not have this choice.

• 59:07Ryan Peterman?

  What was your measure of success if you're working on a programming language? Like, you know, how did you know it was good?

• 59:14Speaker 00

  It's more important to, sometimes that good people that I recognize as like the, the result than a lot of people that I have no idea what's the, who they are, et cetera. Like, so I, I, I think this metric of quantity that is the standard metric nowadays in, in the web, it's got much worse. And everything is just the number of followers that me doesn't care who is following you, just as, as many people as possible. So sometimes for me, it's much more important if someone that I really admire of thing of this, that say something good about Lua, then, oh, we have that many.

• 1:00:00Speaker 00

  But of course, it's good also to have some number of users and to be recognized. But I think it's a balance between all of this.

• 1:00:10Ryan Peterman?

  Do you recommend people study other programming languages to get better at programming? And so question is, you know, what are the top three programming languages that you think every engineer should learn in 2026 to kind of become better at programming?

• 1:00:27Speaker 00

  Haskell, I think is a, is incredible language. It has everything you need to really learn about functional programming. I think one of the main benefits is much, there is an old joke seen in the Haskell community that

• 1:00:50Speaker 00

  if you write a program in Haskell and in C,

• 1:00:56Speaker 00

  in C, really spend one week to make it efficient. And then you spend one year to make it correct.

• 1:01:07Speaker 00

  In Haskell you spend one week to make it correct, and then you may spend one year to make it efficient. Again, that's not my joke, but I it has some truths not always true, etc., but I think it gives the the idea. I think this is maybe the the the main, the most important lesson of Haskell. But Haskell has many other, this thing about type inference, for instance, that I mean, the entire language is, is, types are optional everywhere, and yet it can do type inference for everything. It can infer the types correctly, etc.

• 1:01:51Speaker 00

  C or some other low language. I mean, you can also have to learn some assembler or I mean, to to see you. But assemblers now are becoming too much complex. It would be to learn like the the eighty eighty assembler, very old assembler of various. But to have this exactly this idea of what a machine does, how it does stuff at exactly the basic level, to have this understanding. SCIM is a language that I I like very much because of this exactly, this economy of of ideas. There are very few concepts and you can do some amazing things with very, with very few concepts.

• 1:02:36Speaker 00

  One language that this is very, very, very old, but I still think it is Snowball. I think it was the first languages to have pattern matching and this idea of doing, I mean, it's really strong patterns, etc. And I think it's in, sometimes it's interesting to see old languages because exactly nowadays, a lot of languages tend to, like I said, there's zero indexing that people, they copy a lot. They they tend to be true, uniform in some aspects and so on. It's interesting to see some older languages that have some ideas that may maybe not even good ideas, but it's interesting.

• 1:03:21Ryan Peterman?

  Last question for you is, you know, knowing everything you know now, if you could go back to when you had just started your career and give yourself some advice, what would you say?

• 1:03:34Speaker 00

  To know a lot of stuff, you really have to study a lot of stuff. And it takes time. It's, I I also joke about that. People say, oh, learn Lua in thirty minutes or learn Python in five minutes. Or and I always says that I wanted to be, learn programming in five years.

• 1:03:57Speaker 00

  That's really the take our time, you have to learn that and that. That is a lot of stuff, stuff to learn. There is no magic there, it's no, you really have to learn, I mean, a lot of different things.

• 1:04:12Ryan Peterman?

  Thank you so much for your time, professor. I really appreciate it. It was a lot of fun.

• 1:04:16Speaker 00

  Thank you. It's my pleasure.

• 1:04:19Ryan Peterman?

  Hey, thank you for watching this podcast. If you liked it and you want to see the show grow, please support with a comment or a like. Also, if you have any recommendations for people you want me to bring on, please drop a comment. Guests like Barbara Liskov, Mike Stonebreaker, Mark Brooker. These were all people that I brought on because someone left a comment. On another note, aside from the podcast, I'm working on building the ergonomic keyboard that I wish existed. Here's a glance at the prototype. It's a split keyboard, so there's two sides. This is in the case. But yeah, we launched on Kickstarter and we hit our goal within eight hours of launching. I really appreciate it if you were one of the people who grabbed one of the early units. We're now working on the long journey of building the tooling now.

• 1:05:03Ryan Peterman?

  And so if you still want to pick one up, I've left the late pledges open on Kickstarter, so you can grab one there. I'll put a link in the description. Thank you again for watching the podcast and I'll see you in the next episode.