Lua 的创作者：脚本、编程语言、预测 | Roberto Ierusalimschy

我们完全有可能不再需要编程语言。

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

这位是Roberto，Lua编程语言的创造者，我向他请教了关于编程语言设计的一切。

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

C++就是一个很好的例子，它真的非常非常复杂。

C plus plus a good example of a language that is really, really complex.

JavaScript，我觉得，甚至更糟糕。

JavaScript, I think, is even worse.

我经常开玩笑说，JavaScript的精髓部分，和官方文档比起来，就是一本很薄的小册子。

I always joke that the JavaScript, the good part, a very thin book compared with the official JavaScript brief.

考虑到人工智能发展得这么快，你现在还会推荐人们学习计算机科学吗？

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

如果你仔细想想，其实很难推荐人们去学任何东西。

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

这是完整的一期节目。

Here's the full episode.

2023年，根据GitHub贡献者的数据，Lua是增长第二快的编程语言。

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.

所以我想问您，Lua是一种什么样的编程语言，它有什么独特之处？

And so I wanted to ask you, what kind of programming language is Lua and what sets it apart?

Lua通常与其他语言配合使用，比如C或C++，这样架构上Lua负责程序中更动态的部分——那些变化频繁、对资源要求不高的部分。

Lua is a language that usually is used together, combine it with another language, like C or C plus plus 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.

而繁重的部分则用C或C++来编写。

The hard parts you have written in C or C plus plus 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.

但它们其实并不完全相同。

And they are not exactly the same thing.

举个例子，Lua和其他几种脚本语言的一个很大区别在于，脚本语言通常有两种典型用法。

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 the ad that I call who has the main loop.

也就是说，你可以用C语言编写程序，然后调用Lua；或者用Lua编写程序，然后调用C语言。

So you you can have the program written in C and calling Lua, or you have your program written in Lua calling C.

对于很多所谓的脚本语言来说，你并不一定非要这样，但如果你用脚本语言编写程序，而C语言只用于库函数，那用起来会方便得多。

And for several called scripting languages, you don't have to, but it's much more easy to use if you have your program written in the scripting language, and the C languages only for your libraries.

而LuaJIT非常适合相反的情况。

And LuaJIT's very good fit when you want the reverse.

你想用C语言编写程序，然后时不时地调用Lua。

You want the the the the program written in c, and then you you have it calls Lua from time to time.

关键在于，Lua在这方面非常擅长——主循环用C语言编写，然后它调用Lua来处理某些任务或你想做的任何事情。

So the point is that Lua, it's very good at this, that you have the main loop, the program written in C, 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.

比如说，游戏里有一个主循环，这个循环控制着游戏的节奏，维持一切运行。然后在每一帧，它会调用Lua，Lua更新所有角色、所有图像、游戏里的所有内容，然后返回给C去做随机化处理等等。

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 updates all characters, all images, everything in the game, and then it returns to C to do the randomization, etcetera.

所以它非常合适。

So it is a very good fit.

但关键点是，人们有时把这种情况称为嵌入与扩展。

But the main point is that people sometimes call this the embedding versus extending.

也就是说，你可以用C来扩展脚本语言，也可以把脚本语言嵌入到C中。

So you can extend the scripting language with C, or you can embed the scripting language into C.

因此，有些语言只擅长扩展，而Lua在嵌入和扩展两方面都做得很好。

And so, several languages are very good only for extending, while Lua is really good for both embedding and extending.

为什么Lua适合嵌入呢？

Why is Lua good for embedding?

而Python几乎正好相反。

And Python, it's almost the opposite.

因为从一开始，Lua就被设计成一个库。

Because Lua, since the beginning, Lua, we thought about Lua as a library.

从一开始，Lua 就是作为库来编写的。

Since the beginning, Lua was written as a library.

所以我觉得这就是主要的区别。

So I think that's the the main difference.

Druid 有一个独立的程序，也就是说，你可以在控制台或命令行里调用 Lua。

Druid has a standalone program that, I mean, you can call Lua in your console, in your command line.

但那个程序只是库的官方客户端的一个外壳，它遵循的是和其他任何程序都能用的同一套 API。

But that program is just a client of the official client of the library following the the same API that any other program can use.

所以这种把语言当作库的理念，我觉得并不常见。

So this idea of language as a library, I think it's not very common.

这是 Lua 非常独特的一点。

It's something that is very particular in Lua.

当你把语言设计成库的时候，有哪些独特的设计决策需要考虑？

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

我觉得这体现在很多大大小小的细节上。

I think that goes in a lot of small small and big details.

比如，关于全局空间、变量作用域、异常处理这些概念，在 Lua 里很常见的一个情况是，你在 Lua 中抛出异常，却在 C 语言中捕获它。

For instance, your your idea of what is your global space or your about scopes of variables, about exception handling, for instance, it's very important that it's very common in Lua that you raise an exception in Lua, but you catch the exception in C.

所以，语言中异常处理的方式就变得很重要。

So the all the 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.

它们都有一个 eval 函数，你可以给它一段代码，然后它就会执行那段代码。

They have an eval function that you can give a piece of code, and then it executes that to code.

在 Lua 中，我们没有 eval，而是用一个叫 load 的函数，你给它一段代码，它会返回一个函数，一个内部函数，就像 Lua 函数一样，当你调用那个函数时，才会执行相关的代码。

In Lua, we 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 the associated code.

它不会立即执行。

It doesn't doesn't execute immediately.

所以，你有一个清晰的分离，就是编译 Lua 代码和用 C 语言处理它之间的分离。

So you have this sep this clear separation between compiling, like, the the the Lua code that you have, and then you can do that in C.

因此，在 C 语言中，你可以获取一段 Lua 代码。

So in C, you can get a piece of Lua code.

你可以编译它，检查有没有错误等等。

You can compile it, check if it has errors, etcetera.

然后你调用那个函数，这是另一回事，或者你甚至可以多次调用。

Then you call that for in for this is a different piece, or you can even call several times.

比如，你可以从Lua中加载函数到C语言里。

For instance, you can load functions from Lua into c.

你可以把它们保留在Lua的空间里，然后反复调用同一个函数。

You keep them, I mean, in the Lua space, and then you can call that same function again and again.

当然，这差别不大，因为如果你有eval，你可以执行一个函数声明，然后返回那个函数。

It's not a big difference, of course, because if you have a val, you can evaluate a function declaration and then returns that function.

所以，如果你有eval，你就可以实现load的功能。

So you you can if you have a val, you can do load.

如果你有load，你也可以实现eval的功能。

If you have load, you can do eval.

但我认为，对于那种情况，比如考虑库的时候，load用起来更简单。

But I think load, it's it's simpler to use for that kind of thing that is when you think about libraries, for instance.

在 Lua 里，它没有全局状态。

In Lua, you it doesn't have a global state.

我觉得我忘了说，这是一个非常重要的区别。

I think that's I forgot that that that's a very important difference.

当 C 启动时，第一件事就是调用函数创建一个新的 Lua 状态。

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 independent of everything else.

所以 C 可以创建另一个 Lua 状态，两个状态完全独立，互不干扰。

So c can, for instance, create another Lua state, and both states are completely independent, complete.

它们之间没有任何通信。

There is no communication between them.

这也再次说明，你可以用一个状态做很多事情，然后关闭这个状态，Lua 占用的所有内存都会被释放。

And so this, again, shows that if and so far, it says he can use a state to do a lot of stuff, and then he can close the state, and all memory used by Lua is released.

Lua 使用的所有东西都会被释放。

Everything that Lua was using is released.

比如，如果C语言不再需要用Lua来解决某个问题，就可以释放Lua占用的所有资源，然后继续C语言的编程，之后还可以再创建另一个状态，等等。

For instance, if C doesn't need to use Lua anymore for a problem, you release all resources used by Lua and your programming C continues, then later it can again create another state, etcetera.

所以，就像我说的，语言中有几个或大或小的决策。

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 language as, is that good for embedding?

是否能够实现嵌入之类的功能？

Is that possible to do embedding and things like that?

说到编程社区，大家普遍对Python很熟悉，但对Lua就没那么熟悉了。

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.

如果把Lua和Python相比，两种语言设计各有什么优缺点呢？

So if you compared Lua to Python, what are the pros and cons of each language design?

Lua是一种旨在用于脚本架构的语言。

Lua is a language that is intended to be used in in this idea of of scripting architecture.

所以，比如 Lua，它并不追求拥有大量不同的库。

So the the Lua, for instance, it doesn't drive having a lot of different libraries.

如果你想要快速写个小程序，那 Python 就好得多。

If you have something that, oh, I want to write a 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 the the installation, it's it's a huge download, etcetera.

但它就是，哦，我需要这个。

But it has exactly, oh, I need that.

哦，它就在那儿。

Oh, it's there.

我需要那个，它也在那儿。

I need that, it's there.

而Lua则几乎完全相反。

And Lua is almost the opposite.

它是一种非常精简的语言，因为设计初衷是嵌入到你的程序里，几乎不占用什么资源。

It's a very minimalistic language, because they did that in embed 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.

所以我认为，这就是Lua和Python之间最主要的区别。

So Lua, I think that's the the main big difference.

它们的目标完全不同。

It's they they have very different goals.

我看到一些基准测试，发现Lua比Python快得多。

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

这是为什么呢？

Why is that?

那些基准测试不一定完全准确，但我觉得关键点在于，Lua确实注重性能——当然，是在脚本语言的范畴内，它并不想跟C或C++竞争，但在动态语言（现在更多叫动态语言，而不是脚本语言）的领域里，它确实对性能有所侧重。

Those benchmarks are not exactly but I think that the main point is exactly one thing is that Lua does have this focus on performance, again, in the realm of scripting language, it doesn't want to compete with C or C plus plus 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呢，我觉得更多是他们的一个设计选择。

Python exactly is much more, I think, it's a decision that they make.

性能没那么重要，更重要的是灵活性，让你能轻松做你想做的事。

Performance is not that important, it's more important to be flexible, to be easy to do whatever you want to do.

在Lua里，有时候我们会放弃某些特性，因为觉得没法高效实现它们。

In Lua sometimes we do not put some features because we think that there is no way to implement that efficiently.

不过，我觉得性能差异的一部分也恰恰来自Lua的体积小。

But also, I think some part of the performance difference comes exactly because of the size of Lua.

比如，它的整个虚拟机几乎都能放进缓存里。

So most of the virtual machine fits in your cache, for instance.

我觉得主要就是这两点。

I think there is these two big things.

一方面，Lua 的功能没有那么多。

One is that Lua doesn't have so many features.

它不像 Python 那样动态。

It's not so dynamic as Python.

所以在 Python 里有很多间接调用，因为任何东西都可能代表别的含义，而我们在这一点上更保守一些。

So in Python there is a lot of indirections because everything can mean something else, and we are a little more conservative on that side.

但我觉得，体积小本身也让它自然更快。

But I think also this thing of being small also makes it naturally faster.

所以关于脚本语言和动态语言的区别，我猜动态语言是更大的范畴，脚本语言是它的子集。

So on the distinction between scripting languages and dynamic, or I guess it seems like dynamic language is a superset, scripting language is a subset of that.

按你的说法，JavaScript 是动态语言，而不是脚本语言，我理解得对吗？

Am I understanding that JavaScript is a dynamic language, not a scripting language from your perspective.

对，没错。

Yes, exactly.

对，就是这样。

Yes, exactly.

因为脚本语言这个概念，最早是从Bash或者Unix的Shell来的，核心思想就是有一种语言用来协调其他东西。

Because the scripting, it came, the original scripting language was Bash or the shells from Unix, of this idea that there is a language that coordinates other stuff.

比如说，它可以用来扩展，但关键是你有两种不同的语言——就像Shell之所以有用，是因为有很多用C写的程序由Shell来控制。

So for instance, it can be extending, again, can use, but this idea that you have two different language, for instance, the shell is only useful because you have a lot of problems written in C that are controlled by shell.

所以脚本语言有一个非常强的概念，就是双语言架构。

So the scripting language have this very strong idea that you have this idea of a dual language architecture.

所以“脚本”这个名字本身就意味着，你是在协调或者给那些东西提供一个脚本去执行。

So sweetness is like, it's the name scripting, it means you, it's like the, you coordinate or you give a script to be executed by those things.

你之前

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.

我喜欢读那些描述语言设计思路的书。

I like reading books that describe the design of the languages.

我觉得最好的书就是语言作者自己写的那本，讲的是这门语言的设计。

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

那你觉得哪本书在语言设计方面最值得推荐？

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

比如《JavaScript语言精粹》。

JavaScript, The Good Parts, for instance.

虽然现在有点老了，但我还是觉得它是一本很有意思的书。

It's kind of old now, but I think that's I think it's a very interesting book.

不过我总开玩笑说，《JavaScript语言精粹》这本书很薄，跟官方JavaScript书比起来，大概只有十分之一的内容是精华部分。

Although I always joke that the JavaScript, the good part, very thin book comparative the official JavaScript books, like, one tenth of the language is the good parts.

但我觉得那本书真的很有意思，因为它正好讨论了这门语言，连不好的部分也讲了，然后重点放在好的部分，还解释了为什么会有那些设计、为什么那样做等等。

But but I I think that book is really interesting, like, because exactly it it discusses the language, discusses even the bad parts, and it focuses on the good parts, but then explains why it's there, why it was made that way, etc.

那是我喜欢的一本书。

That is a book that I like.

刚才聊到Lua的时候，感觉Lua的一个特点就是性能好，而且非常精简。

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.

我在看Lua的资料时，看到了LuaJIT。

And when I was reading about Lua, I saw that there's LuaJIT.

LuaJIT是怎么工作的？

How does the LuaJIT work?

LuaJIT首先是一个完全不同的项目。

LuaJIT is the first thing that's completely different project.

它和我们没什么关系，但它是一个非常了不起的软件，是Lua的一个即时编译器。

It doesn't have anything to do with us, but it's an incredible piece of software that is a just in time compiler for Lua.

我觉得它能在Lua上运行得这么好，其中一个原因就是Lua本身很简单。

And I think exactly one of the reasons it works so well on top of Lua is because of the simplicity of Lua.

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 indirections or things that, so it's not that dynamic.

意思是，它可能代表完全不同的东西。

Mean, can mean something completely different.

所以我认为这对JIT来说是一个非常合适的语言。

So I think that gives a very good language for a JIT.

不过，那个Mike Paul就是开发第一个JIT编译器的人，我觉得他到现在还在继续做这个项目。

But the the the the the Mike Paul is the name of the the the guy that made the the I think he's still working on that, on the first JIT.

他的工作真是令人难以置信。

He's it's unbelievable, his work.

编写JIT编译器难在哪里？

What makes writing a JIT difficult?

对我来说，不想碰JIT的首要原因就是它依赖于特定的机器架构。

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 do a lot of work on those, only work on that architecture.

然后，哎呀，我又想换到另一种架构上运行。

And then, oh, I want to run-in another architecture.

但Mike Paul发明了一种伪汇编语言，他用这种汇编语言写代码，然后再把它翻译成不同机器的真实机器码，这样就能统一不同的架构了。

But might Paul, he created a kind of a pseudo assembler that he writes in this assembly, and then he translates that assembler through real machine code of the different machines, so trying to unify the different architectures.

所以工作量很大，但我不喜欢。

So there is a lot of work, but I don't like it.

我觉得架构，我喜欢研究，但不喜欢做实际工作，因为我觉得它很不稳定。

I think architecture, I like to study, but I don't like to work with, because I think it's very unstable.

每个新版本，他们改这个，改那个，比如改个ABI，然后栈又得按某种特定方式对齐。

Each new version, they change that, or they change that, I mean, they change the ADI for something, and then now the stack has to be aligned in some very particular way.

当然，为了达到他那样的性能，他做了一个叫追踪编译器的东西。

And so And of course, also to get that performance that he gets, he made what's called a trace compiler.

追踪编译器的思路是，不是拿到一个函数就去编译它，而是像其他JIT一样，先检测哪些代码执行得频繁。

The idea of a trace compiler that instead of getting a function and compiling a function, it go it it works like any JIT that it tries to detect things that are executing frequently.

然后它就开始所谓的追踪。

And so it starts what is called a trace.

它会记录代码所做的一切，包括函数调用等等，直到形成一个循环。

It gets recording everything that the code is doing, including function calls, etcetera, until it closes the loop.

然后它编译那个循环，包括函数调用等等，全部内联进去。

And then it compiles that loop, including function calls, etcetera, everything in line.

它针对那种特定情况编译，比如那个数恰好是整数，所以它编译f时，会假设这个数还是整数。

It compiles that for that specific, for instance, so that number happens to be an integer, so it compiles f, 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, you call again that, but you call it frequently with integers, and suddenly you call through with a float, then at some part of the code it breaks the condition, and you have to return to the interpreter part.

我觉得最麻烦的地方之一就是，你得把压缩在寄存器里的状态全部还原出来。

And I think that's one of the worst parts, that you have to translate the state that it's all compressed into registers, etcetera.

比如说，你连调用栈都没有，因为你根本没做函数调用，直接内联了。

For instance, you don't even have a call stack because you didn't do the calls, you just inlined it.

但突然，哎呀，出问题了。

But then, oops, something went wrong.

现在你得继续解释执行，所以必须重新创建那个你原本没创建的栈，等等。

Now you have to continue interpreting, so you have to recreate the stack that you didn't create originally, etc.

光是想想这个，我就头疼。

So even to think about that, I have headaches.

标准 Lua 是可移植的，但要在机器上执行，它最终总得在某个环节转换成机器指令。

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?

Lua 是用 C 写的，解释器也是用 C 写的，然后你把解释器和 Lua 代码一起编译成机器码。

Lua is written in C, the interpreter is written in C, and then so you compile that into machine code, the interpreter, the Lua code.

然后当你拿到一些 Lua 代码时，我的意思是，Lua 解释器代码。

Then the point when you get some some some I mean, the Lua code, the Lua interpreter code.

当你拿到一些 Lua 代码时，我们会做一个所谓的预编译，就是把它翻译成一种内部语言，然后解释器就是一个大循环。

When you get some Lua code, you do what is we call a precompilation that is we we translate to an internal language, and then the interpreter is just a big loop.

就是一个带 switch 的循环。

It's a loop with a switch.

当然，这是个非常简化的说法，但大致上就是一个带 switch 的循环，它拿到指令，然后通过 switch 判断，哦，这个指令——这些指令跟 CPU 的指令挺像的。

I mean, that's a very big simplification, but in general terms, a loop with a switch that get instruction does a switch and see, oh, this instruction is the instructions are quite similar to a CPU.

执行那个操作，但不会创建新内容，而是直接执行那条指令。

Move that, but then instead of creating, it executes that instruction.

把a移动到b。

Move move a to b.

所以它执行a到b的移动，然后重复，继续执行下一条指令。

So it it does a move a to b and executes that, and again repeats, execute the next instruction.

这就是解释器的工作原理，基本上我们会对Lua进行预编译。

So this is how an interpreter works and basically so we we precompile Lua.

确实有编译这一步，但我们是针对这个虚拟机进行编译，然后有一个主解释循环，大家称之为取指令循环。

There is a compilation, but we compile it for this virtual machine, And then we have this main interpreter loop that people call that just fetch it instruction.

所以跳转就是单纯的跳转。

So a jump is just a jump.

你有一个字节码数组。

You have an array of byte codes.

跳转指令就直接跳到那个位置。

A jump will just go to that.

你有一个计数器，用来记录你在数组中的位置。

You have a counter that tells where you are in this array.

执行跳转时，你只需要更新这个计数器。

A jump, you just update that counter.

它会跳到数组的另一个位置，然后继续执行。这就像在软件中模拟CPU一样。

It goes to another position of that array where you're going to So it's like emulate the CPU in software.

这个解释器是用C语言写的。

It's written in C, the the interpreter.

这个主循环是用C语言写的。

This main loop is written in C.

所以如果你在Linux上编译它，它就会在Linux上运行；如果在x86架构上编译，它就会在那个架构上运行。

So if you compile it in Linux, it will run-in Linux or in a x86 architecture, it will run-in that architecture.

如果你在Mac上编译它，它就会在Mac上运行。

If you compile that in the Mac, it will run-in the Mac.

它就是一个C程序。

It's a C program.

明白了。

Got it.

好的。

Okay.

所以这部分就是不可移植的，而C编译器会处理它。

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

对，对，对。

Yes, yes, yes.

Lua的所有可移植性都建立在C的可移植性之上。

All portability of Lua comes on top of portability of C.

在性能方面，JIT和提前编译相比怎么样？

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

提前编译，或者说任何形式的编译，虽然不容易，但可以比解释执行快10倍，甚至100倍，具体取决于你在做什么。

Both ahead of time, any kind of compilation is easily, not easily, but can be 10 times faster than interpreting, or even 100 times faster than interpreting, depending what you are doing.

但10倍已经是一个非常不错的数字了。

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, it's particularly good for benchmarks.

因为基准测试基本上是在重复执行，模式非常一致，你一遍又一遍地做完全相同的事情。

Because you're repeating it more or less, they are very uniform, you are doing exactly the same thing again and again and again.

所以这时候追踪编译器就大放异彩了，这是它们最擅长的场景。

So then trace compilers shine, mean, this is the best they can do.

在实际问题中，情况就复杂多了，我觉得两者之间没有明显的赢家。

In real problems, that depends a lot, but I wouldn't say there is a clear winner between the two.

我认为这很大程度上取决于具体的问题类型。

I think depends a lot of the kind of problem.

有没有可能为 Lua 写一个提前编译器？

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

可以。

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, etcetera, there are several.

我有个学生写过，是他的硕士论文。

I I have a student who wrote one, like, a master thesis.

一个特别简单的 Lua 编译器，提前编译的那种。

A ridiculous simple Lua compiler, ahead of time Lua compiler, something like that.

对。

Exactly.

它就是把那些操作码提取出来，展开成 C 代码，然后交给 C 编译器去编译，这样就做出了一个 Lua 的提前编译器，性能提升了大概三到五倍。

It was just it gets these opcodes and expands into into C code, and then you send that through to a c compiler, and then you have a head of time comp head of time compiler for Lua, and it gave, like, three, five times boost in performance.

就像标题说的，这真是个极其简单的编译器。

It's very, very, as the title said, it's like a ridiculous, simple compiler.

我总听人说有编译型语言，还有动态或解释型语言，大概是这样吧。

I always hear 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.

比如，我可以写一个编译器或程序，把Python代码转换成机器码，这样就有了编译后的Python。

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.

C语言也可以解释执行。

And you can interpret C code too.

你可以为C语言写一个解释器。

You can write an interpreter for C.

是的。

Yes.

但主要的区别恰恰在于哪些功能容易实现。

But the main difference is exactly what it's easy to do.

比如，我刚才提到，解释型语言的一个标志性特性就是eval。

For instance, as I said, one of the hallmarks of interpreted languages is eval.

所以，如果你想编译语言并保留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.

你可以在运行代码的同时创建代码。

You can create code while running code.

所以正因如此，大多数情况下语言都是解释型的。

So that part is that's why much more often than not, languages are interpreted.

但也可以编译，不过有些编译器根本不处理 eval。

But you can compile, but then sometimes for some compilers do not handle eval at all.

他们会说，只要你的程序里没有 eval，就可以编译。

They say, oh, you can compile as long as your program doesn't have evals.

所以还是有一些限制的。

So there is some restrictions.

而且就像我说的，你可以解释执行 C 代码，但速度会非常慢，不过……

And as I said, you can interpret C code, you'll be extremely slowly, doesn't but.

我觉得一个很大的区别是，当我看到静态语言或编译型语言时，它们似乎都有类型系统或类型注解。

I think one big difference, when I look at statically, or static languages or compiled languages, they seem to have type systems in them, or the type annotations.

类型系统在编译过程中扮演什么角色？

What is the role of a type system in the compilation process?

这很大程度上取决于类型系统本身。

Depends a lot on the type system.

有些类型系统，比如C语言中的，就是编译过程中非常重要的一部分。

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 unique to that.

否则，就会变得非常复杂。

Otherwise, it's a massive.

大多数情况下，你不得不把所有东西都动态分配到堆上，这会导致巨大的性能损失。

More often than not, you have to keep everything in the heap dynamically allocated, and so huge penalty in performance.

再比如，就像我刚才说的，一个简单的加法运算。

And for instance, when you see, as I said, a trivial, you have an addition.

比如 r 加 b。

The r plus b.

如果你知道 a 的类型，a 加 b，你知道 a 的类型和 b 的类型，在编译时就能确定，哦，这个加法是两个整数相加，我直接生成整数相加的机器码就行了，一切都很顺利。

If you know the type of a, the a plus b, you have the type of a, the type of b, you have a compile time, you know, all these plus is adding two integers, I just generate the machine code to add integers, and there everything is fine.

在动态语言里，我看到一个加法，我……我编译成虚拟语言，它只是一个加法操作，但运行时怎么处理呢？你得检查 a 是什么，哦，a 是整数，b 是浮点数，那我得转换，或者 b 是字符串，根据语言不同，可能根本不是在做加法。

In a dynamic language, I see a plus, I don't I I I compile to a the virtual language, it's just 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 not doing addition.

它可能是拼接，或者调用某个方法，所有这些都得在运行时处理。

It can be doing concatenation, or you can just call in some and you have to do all that at run time.

所以类型对于高效编译非常重要，当然，前提是你得有一个合适的类型系统。现在有些语言，比如 TypeScript，它的类型并不能保证所有东西都符合你声明的类型。

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 language now like TypeScript, that types are kind of you do not guarantee that everything has the types you said they have.

这样的话，就不可能用它们来编译了，因为，哦，a 可能是个整数，但如果不是，那就麻烦了——如果我给整数分配了寄存器，那 a 必须是整数，否则就行不通。

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 I have an an integer register to boot for anything, a must be a register or things will not work.

所以，如果你有正确的类型系统，它们对于好的编译来说是必不可少的。

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

我知道有些编程语言，它们有类型推断。

I know some programming, then you just have type inference.

那如果你先做类型推断，得到一组明确的类型，然后再用这些类型去编译呢？

What if you did, you ran type inference and you got an unambiguous set of types, and then you used that in compilation?

比如说，能不能对 Lua 这么做？

Like, could you do that for Lua?

不行。

No.

我是说，这其实不可计算，但很多人尝试给动态语言做类型推断，这是个非常难的问题，而且很难在性能上做出什么有用的成果。

I mean, that's not computable, but a lot of people try to do 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 restrict if you write your program in that specific way, you fall So it's like you don't have the type, but you write the program thinking about types, and then if the program is that very particular format, then you can do type inference and everything goes well.

否则的话，要么类型推断不工作，要么它虽然工作，但推断出来的都是非常泛化的类型，这样你就没法利用类型优势了。

Otherwise, either time inference doesn't work, or, I mean, it works, but it actually infers very generic types for everything, and so you cannot take advantage of the types.

因为语言的动态特性，这种情况在即时编译中也会出现。

Because exactly the dynamic nature of the language, This also happens through a JIT, for instance.

如果你脑子里有一个类型系统，那性能就能提升很多。

You can get much, much better performance if you have a kind of a type system in your mind.

我们通常都会这么做，即使没有编译器或语言强制要求，你也会自觉遵循那些类型规则。你会告诉自己，我要遵守这些规则，保持一定的纪律性。

Usually we do that, 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, discipline.

我不会用同一个变量来存整数和字符串之类的，这样就能获得更好的效果。

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

OpenAI、Anthropic、Cursor 和 Vercel 都在用这个产品来提升工作效率。

OpenAI, Anthropic, Cursor, and Vercel all use this product to make their lives better.

它解决的问题是，当你开发 SaaS 或 AI 产品，并想卖给其他公司时，你需要满足一大堆要求。

And the problem it solves is when you're building SaaS or an AI product and you wanna 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 是一个 API 层，让你只需几行代码就能满足所有这些要求。

WorkOS is an API layer that lets you meet all of these requirements in just a few lines of code.

假设你有一个新的 SaaS 产品，想卖给其他公司，WorkOS 会帮你解决所有这些关键的功能缺口。

So let's say you have a new SaaS product and you wanna sell to other companies, WorkOS will solve all of these critical feature gaps for you.

你可以去 workos.com 看看，了解更多并开始使用。

You can check them out at workos.com to learn more and get started.

我很感谢他们支持我的工作，并赞助了这个播客。

And I appreciate them for supporting my work and sponsoring this podcast.

之前你提到 Lua 可以调用 C，C 也可以调用 Lua。

Earlier, you mentioned that Lua can call C and C could call Lua.

你还提到我们聊了编译器和解释器。

And you mentioned we talked about the compiler and the interpreter.

那在串联不同编程语言的情况下，这些部分是如何协同工作的呢？

And how do these pieces work together in the case where you're chaining different programming languages?

对，主要技巧——其实也不算技巧——Lua 调用 C 的方法就是 C 指针，函数指针。

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

就是有一个指向函数的指针。

There is a pointer to a function.

这是 C 语言官方标准的一部分。

This is part of the official c language.

所以当你启动 Lua 时，假设你在 C 语言里，就像我说的，你创建一个库。

So when you start Lua, suppose you are in c, as I said, you create a library.

你创建一个状态，一个 Lua 状态，然后你可以注册，把 C 指针、函数指针以及指向你 C 库中函数的指针连同名字一起发送给 Lua，它会把这些存储在某些数据结构里。

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

明白吗？

Okay?

所以它就会说，哦，这个函数名对应那个指针，等等。

So it says, oh, the function sign is associated with that pointer, etcetera.

所以在解释执行时，哦，这条指令被调用了，指令被调用了。

So when it's doing the interpretation, oh, this instruction is called, instruction called.

看看它调用的是什么。

Let's see what it's calling.

哦，它调用的是 a。

Oh, it's calling a.

a 的值是什么？

What is the value of a?

哦，那是一个指针，然后它就会调用那个指针。

Oh, it's a pointer to and then it it calls that pointer.

然后我们就调用了那个C函数来做这件事。

And then we did call the the c function to do that.

当C想要调用Lua时，我的意思是，从C的角度来看，Lua函数只是一个数据结构。

And when when c wants to call Lua, I I mean, a Lua function is just a data structure from the point of view of c.

它只是一串字节码和操作码的数组，然后它会调用Lua解释器函数，说‘请帮我解释这个函数’。

It's just an array of byte codes of opcodes, and then it calls the Lua interpreter function of do please interpret that function for me.

所以C可以调用Lua来解释那个函数，那个函数运行起来后，又可以通过指针调用一个C函数。

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.

所以我们正在运行一个Lua函数，它调用C，C又调用Lua，Lua再调用C，这样就会形成递归，等等，一切都能正常工作。

So we are running a Lua function that calls c and c calls Lua again, and Lua calls C, and you have recursive stuff in that, etcetera, and everything works.

它就是能正常工作。

It just works.

你在一次关于 Lua 的演讲中提到，使用脚本语言有安全方面的好处。

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?

其实不只是硬件。

It's not only hardware.

有一次我在巴西做演讲，被邀请去一个 Python 大会——他们叫它 PyCon，就是巴西的 Python 会议。

Once I gave a talk here in in Brazil, I was called to to give a talk in a py conference, a pycon, they they call it the Python conference in Brazil.

他们请我去做了一场演讲。

They called me for a talk.

演讲结束后，有人说，哦，Lua，我们把它当脚本语言用。

At the end of the talk, said, oh, Lua, we use it as a scripting language.

就像我说的，重点在于这种双语言架构。

As I said, emphasizing that thing that you have this dual language architecture.

据我所知，Lua 被用于和 C、C++、Fortran 以及好几种其他语言配合使用。

And I know of cases of Lua being used with C, with C plus plus with Fortran, with several different languages.

然后观众里有人说，哦，我们也用Lua来给Python程序写脚本。

And then someone in the audience says, oh, we also use Lua for scripting Python programs.

那是什么情况呢？

And what's the case?

他们有一个很大的Python金融程序，要处理大量金融交易等等，他们想弄一个命令行，可以在运行时输入指令让程序执行，比如用来调试、检查，或者做任何需要的事情，算是某种终端用户编程。

They have a huge Python program for financial stuff that has a do a lot of financial transactions, etcetera, and they wanted to do I mean, to have a, like, a common line where you could write instructions to be executed by the at run time, 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.

在Python里，如果你有一个命令行，然后你运行Python代码，那这个Python代码可以对你的程序为所欲为。

In Python, basically, if you have a common line and you are going to run Python, 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.

这样一来，程序里很多重要的东西，比如它维护的文件里的各种不变量，都会被破坏掉。

And so the program would break a lot of invariants of a lot of important stuff in the files it kept, etcetera.

所以他们是怎么做的呢？他们想到了 Lua，因为就像我说的，Lua 可以创建一个状态。

And so what they did, they gave the thinking Lua, because as I said, Lua, you create a state.

比如，我刚才提到，你只能调用 C 函数。

For instance, as I just mentioned, you can only call c functions.

这在 Python 里其实也一样，不过在那个具体场景下。

That is true in Python again, but in that particular thing.

你只有把 C 指针传给 Lua，才能调用那些 C 函数。

You can only call c functions if you give the c pointer to Lua.

所以它的限制非常严格，而且就像我说的，它有一个库。

So have a very strict and there is very as I said, there is a library.

当你创建一个 Lua 状态时，它里面什么函数都没有。

When create a Lua state, it has no functions at all.

什么都没有，也就是说，你连文件都打不开，所有功能都靠我们所说的标准库。

There is nothing, I mean, you cannot open files, everything there are what we call standard libraries.

通常你会创建一个状态，然后注册那些标准库，在 Lua 里，你只有最基本的东西，比如数学函数之类的。

Usually you open a state and you register those standard libraries in Lua, you have the the minimum, you have mathematical functions, etcetera.

但你可以创建一个状态，而Lua里完全没有函数。

But it can open a state and has no functions at all in Lua.

它只能调用你指定的那些函数来做事情。

It can only do things calling those specific functions you you gave.

所以他们用Lua来实现这种控制，或者你可以在里面写Lua代码，但这些代码在Python程序里只能做非常特定的事情。

So they they use Lua to have this kind of control, or you can write Lua code here, but that Lua code can only do very specific things in the Python program.

它不能调用任何Python函数，也不能构建任何Python数据结构之类的。

It cannot call any Python function or, I mean, build any kind of Python data structure, etcetera.

所以这是个很好的例子。

So was this a nice example.

在硬件方面也是同样的道理。

In the case of hardware, it's the same thing.

你不能随便操作，比如有一个硬件端口，它控制着风扇转速，用来维持CPU温度。

You cannot just go in the for instance, there is a port, a hardware port, that controls the speed of the fan that keeps the temperature of the CPU.

如果你把转速调得很低，真的会把CPU烧坏，因为CPU会变得非常热。

And if you put that very low, you can really burn the CPU, I mean, because the CPU gets very hot.

所以我们不能直接调用C语言。

And so we've you have a c you cannot call c directly.

必须通过Lua来调用，只有Lua才有权限访问那个接口。

You must call Lua, and only Lua has access to that.

所以如果你只能用Lua编程，Lua会先检查你给的数值是否精确，或者需要检查的其他东西，然后才会去调用。

So if you can only program in Lua, it says, oh, Lua, then you check whether the numbers you are giving are precise or whatever it has to check, and then it calls

这有点像沙盒环境。

It's kind of like a sandbox environment.

对，没错。

Yes, exactly.

是的，沙盒这个词用得很准确。

Yes, sandbox is the exact word for that.

我看到你好像和几个人一起写过一篇关于Lua历史的文章或者论文，里面有些挺有意思的引用，我想问问你。

I saw there was this, I guess, paper, or maybe it was an article you wrote on the history of Lua with several other people, and 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.

是的。

Yes.

那不是我的原创。

That's not mine.

那是个老掉牙的笑话了。

That's a real old joke.

那是不是意味着，你认为最好的编程语言应该由尽可能少的人来设计？

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

是的。

Yes.

我确实这么认为。

I do think.

对。

Yes.

因为有一点很容易观察到，那就是——

Because one thing that that it's easy to to observe is is is this.