今天解释语言的速度有多快？

Question

• 今天解释性编程语言的（主要/唯一可行）实现的速度是一个标准吗？

• 速度和抽象之间的最佳平衡是什么？

• 脚本语言是否完全忽略了所有关于性能的想法，只是遵循快速开发，可读性等概念？

我问这个是因为我正在设计一些实验语言和口译员

Answer 1

速度很重要，是的，但通常脚本语言用于I / O成本超过执行速度的情况，因此它不是最终的全部。更重要的是语言结构和功能。首先处理这些问题，然后处理执行速度。

那就是说，我认为最终如果你想要构建一个新的通用语言，那么你将会走大部分的路线，这是预编译成字节码和执行期间的JIT编译。

Answer 2

我不明白为什么有人会这样写一个翻译。有两个出色的虚拟机，CLR（+ DLR）和JVM。为运行时编写编译器是微不足道的，然后您可以获得与大量现有代码的互操作性，以及出色的标准库，以及JIT编译器，这些编译器将使您的语言速度成为许多问题。案件（肯定比任何翻译都快。）

如果你想制作的语言不仅仅是对开发者的好奇心，那么这绝对是现在的发展方式。

Answer 3

开发人员需要的速度一样快。

没有规则，只需要提供。

Answer 4

这样的问题不仅有答案。没有一个答案可以适用于所有可能的目的和受众。

可能需要考虑的最大因素是您是否打算将该语言大部分独立，或与其他语言结合使用。如果你写一些像Lua这样的东西主要（或专门）与其他东西一起使用（在Lua的情况下为C）那么速度变得不那么相关和有趣。如果你写的主要是自己使用的东西，速度开始变得更重要。

Answer 5

1. 是
2. 这取决于您的语言的使用方式。
3. 否。没有理由不设计一种快速可读的语言，因此几乎不会成为忽视性能的借口。

您必须根据实验目标自行回答这些问题。

Answer 6

除非您的语言无用，否则速度始终是相关的。如果它有用的话，人们会试着用它来做一些繁重的工作，如果它们在尝试时不会掉到脸上，那总是更好。这并不意味着值得优化速度（取决于您的目标），也不会告诉您如何（例如快速编译到字节码与返工如何访问用C编写的高级库，以便解释器在调用它之前做的事情更少。）

速度和抽象之间的最佳平衡取决于要解决的问题类型。计算机时间通常不如人们的时间有价值，但两者都值得。完全忽略计算机时间，考虑工作和等待结果的人将花费多少时间总计仍然是有用的;当总编码+执行时间最小化时，语言的用户应该非常高兴。 （如果你想做一个最强大的商业案例，那么编码员与用户的工资比重。）

由于前两点，我认为解释语言完全忽略性能是一个坏主意。当然，如果该语言本身就是实验性的，那么您必须问自己，您希望花多少时间来处理性能而不是添加功能。如果初始实现将逐渐优化，因为它被更频繁地使用并且用于更苛刻的任务，那么它可能是非常慢的。 JavaScript就是一个很好的例子。

Answer 7

我个人会选择一款API很棒的语言。如果你看看Lua，人们编写的Lua C代码中有90％只是样板文件。如果一个较慢的语言，有更好的C ++ API出现，我会立即切换到它。

最终，“过早优化是所有邪恶的根源”，也就是说，你的语言需要一些很棒的功能，而且需要快速。如果它像汇编程序一样可用，并且用户必须实现操作系统，那么它是快速的。