JavaScript可以从Ruby中学到什么？

ECMAScript工作组已经开始编写该语言的下一个版本。他们能从Ruby中学到什么？

有一个听起来像宝石的名字比一个听起来像皮肤病的名字要好得多

---

但是不要用今天最热门的东西来命名你的新语言（这就是为什么我们一开始就陷入“Java”脚本混乱的原因……）

这实际上是一个比最初看起来更具挑战性的问题

这样做的主要原因是，在没有很好的理由的情况下，通过规范的方式强迫浏览器供应商实现语言爱好者、用户、其他供应商或学者最喜欢的功能是非常困难的。这就是为什么我们最终的ES4规范在桌面上几乎是死气沉沉的，这产生了一个不那么雄心勃勃（尽管仍然非常棒）的ES和谐。像JavaScript这样的语言有着极其棘手的政治部署和实现问题，根本不可能成为Ruby在其生命中大部分时间里所拥有的那种令人敬畏的实验平台。任何关注过es讨论（ECMAScript语言开发邮件列表）的人现在可能已经注意到，仅仅清楚地表达并同意共同的语言特性（例如，在最近的内存中，运算符重载或缩写lambda表示法）需要花费数月的讨论和实验

也许要求任何一个工作组制定一个针对地球上每一台设备的规范都太过分了？从表面上看，这似乎是一个非常狭窄的课程范围，甚至是社交课程，可以很容易地从Ruby转移到JavaScript

为此，为了减轻Brendan Eich及其团队的负担：

从Ruby（或LISP）启发的角度来看，给语言带来的最迫切有用的“教训”之一是语言可塑性。引入新特性、语法破解和领域特定语言的能力（并非源自规范编写者的内部阴谋集团）将具有难以置信的价值。允许该语言成为一个良好的地方，用于对将要制作的语言进行模块化扩展，并使这些扩展自托管，从而最大限度地降低碎片化风险，并允许这些更改渗透和混合，等等

这种可塑性将允许整个社区应用来自各个方向的课程，并允许互联网随着时间的推移决定哪些课程值得从哪种语言学习，等等。我们已经在这个三明治的另一端（即浏览器本身）进行了高频率的迭代和进化（例如：HTML5），在js库中。如果这种情况能够在语言级别更密切地发生，我们可以看到一些非常有趣的事情很快发生

[附录/编辑]：

---

语言必须能够显著变形，因为一小群人根本无法预测它将用于的所有事情。es讨论中经常出现的一个主题是设计“未来10-15年的语言”的潜在趋势.IMHO，这是一个难以置信的不切实际的目标。如果你不构建它，系统将在规范的预期生命周期之前很久发展出一个替代方案。随着最近javascript引擎/JIT技术的巨大加速，我们已经看到了这种情况发生的早期迹象，即新的语言被编写在规范之上JavaScript或正在被动态交叉编译成JavaScript。是的，甚至Ruby:

拥抱函数编程，不要试图将其隐藏在静态语言结构中

我看不出它能从Ruby学到多少东西。标准组已经给了该语言一个重新发送消息或向原型发送消息的方法Method_missing功能实现起来可能很酷，但它没有更好的参考功能那么必要。

围绕闭包的大量使用构建一个标准库，用于集合迭代和获取资源/产出资源/处置资源模式。这是ruby最大的成功之一，依我看。当然，这是这是一个明智的决定，为每个方法提供一个“免费”闭包参数，并提供语法支持，因此在javascript中可能看起来不太好。不过，这些技术仍然很有用。

什么是javascript？这不是JQeury运行的VM吗？一个模糊的问题，我不确定为什么它以Ruby为中心。（JavaScript可以从许多语言中学习，为什么特别是Ruby？）这是一个毫无意义的问题。他们为什么要从Ruby中学习任何东西？为什么不从C#或SQL中学习？这两种语言在完全不同的问题域中。“这两种语言在完全不同的问题域中。”我不太明白这一点。每个人都有自己的兴趣。对Javascript与其他语言的关系感兴趣的人当然可以自由询问。HotRuby在V8和JIT Javascript之前就已经存在了。但是你说得很好。JS作为web的汇编语言没有什么错。不过，它在应该是这样。谢谢。我想我想说的是，有一些无形的趋势正在以各种方式表现出来，不一定是以任何协调的方式或顺序：）我同意汇编语言部分的观点。速度越来越快。这是一个多么轻率的回答！我很高兴有更多严肃的回答出现。但仍然是真的。当他们谈论ECMAscript时，我们有多少次看到标记为“Java”的问题？+1以一种可以真正理解的方式解释ruby的这一部分，而不是说“积木很酷”。