解释性编程语言的（主要/唯一可行的）实现速度是今天的标准吗？
速度和抽象之间的最佳平衡是什么？
脚本语言是否应该完全忽略所有关于性能的想法，只遵循快速开发、可读性等概念？
我问这个是因为我目前正在设计一些实验性语言和解释器
问问题
1456 次
7 回答
2
速度很重要，是的，但通常在执行速度超过 I/O 成本的情况下使用脚本语言，所以这不是最终目的。更重要的是语言结构和特征。先处理这些，然后处理执行速度。
也就是说，我认为最终如果你想构建一种新的通用语言，你会走他们中大多数人正在走的路，即在执行期间预编译成字节码和 JIT 编译。
于 2010-05-17T15:38:03.787 回答
2
我不明白为什么现在有人会写解释器。有两个出色的虚拟机，CLR (+DLR) 和 JVM。为任一运行时编写编译器都很简单，然后您就可以获得与大量现有代码互操作性的优势，加上出色的标准库，以及 JIT 编译器，这将使您的语言的速度在许多方面都不是问题案例（肯定比任何解释器都快。）
如果您想制作一种对开发人员来说不仅仅是一种好奇心的语言，那么这绝对是这些天要走的路。
于 2010-05-17T18:48:51.807 回答
1
开发人员需要的速度。
没有规则，只需要喂。
于 2010-05-17T15:38:02.420 回答
0
除非您的语言没用，否则速度总是相关的。如果它有用，人们会尝试用它来做一些繁重的工作，如果他们尝试时它不会掉在脸上，那就更好了。这并不意味着值得优化速度（这取决于您的目标），也没有告诉您如何（例如，快速编译为字节码与重新设计访问用 C 编写的高级库的方式，以便解释器在调用它之前要做的更少）。
速度和抽象之间的最佳平衡取决于要解决的问题的类型。计算机时间通常不如人们的时间宝贵，但两者都值得。完全忽略计算机时间，考虑工作和等待结果的人总共花费多少时间仍然有用；当总编码+执行时间最小化时，该语言的用户应该会感到最大的快乐。（如果您想制作一个最强大的商业案例，则按编码员与用户的薪水来衡量。）
由于前两点，我认为解释语言完全忽略性能是一个坏主意。当然，如果语言本身是实验性的，你必须问问自己你想花多少时间在性能上而不是添加特性上。如果随着更频繁地使用和更苛刻的任务而逐渐优化初始实现，那么它可能会非常慢。JavaScript 就是一个很好的例子。
于 2010-05-17T18:33:08.280 回答
0
就个人而言，我会选择一种具有出色 API 的语言。如果你看一下 Lua，人们编写的 90% 的 Lua C 代码只是样板文件。如果出现一种更慢的语言，以及更好的 C++ API，我会立即切换到它。
归根结底，“过早的优化是万恶之源”，也就是说，你的语言需要一些很棒的特性，而且它需要快速。如果它像汇编程序一样可用，那么快速是不好的，因为用户必须实现操作系统。
于 2010-05-17T19:09:40.333 回答
0
像这样的问题没有唯一的答案。没有一个答案可以适用于所有可能的目的和受众。
可能要考虑的最大的一个因素是您是否打算让该语言主要是独立的，或者与其他东西结合使用。如果您编写类似 Lua 的东西主要（或专门）用于与其他东西（在 Lua 的情况下为 C）一起使用，那么速度就变得不那么相关和有趣了。如果你写的东西主要是自己使用的，那么速度就变得更加重要了。
于 2010-05-17T15:39:55.067 回答
0
- 是的
- 这取决于您的语言打算如何使用。
- 不，没有理由不能设计一种快速的可读语言，以至于几乎不会成为忽视性能的借口。
你真的必须根据你的实验目标自己回答这些问题。
于 2010-05-17T15:43:27.903 回答