ECMAScript 工作组已开始着手研究该语言的下一版本。他们可以从 Ruby 中学到什么？
【问题讨论】：
标签： javascript ruby
这实际上是一个比最初看起来更具挑战性的问题。
这样做的主要原因是，在没有充分理由的情况下，通过规范的方式强制浏览器供应商实现语言爱好者、用户、其他供应商或学者最喜欢或最喜欢的功能已被证明是非常困难的。这就是我们最终将 ES4 规范几乎死在桌面上的原因，它产生了一个不那么雄心勃勃（尽管仍然非常棒）的 ES Harmony。像 JavaScript 这样具有如此棘手的政治部署和实施问题的语言根本无法成为 Ruby 一生中大部分时间都在使用的那种很棒的实验性游乐场。任何关注 es-discuss（ECMAScript 语言开发邮件列表）的人现在可能已经注意到，仅仅阐明和同意共同的语言特性（例如最近记忆中的运算符重载或短）就需要数月的辩论和试验形成 lambda 符号。
也许要求任何工作组确定一个针对地球上所有设备的规范可能太过分了？从表面上看，它似乎是一个非常狭窄的课程范围，即使是社交课程，也可以很容易地从 Ruby 转移到 JavaScript。
为此，并减轻 Brendan Eich 及其团队的负担：
从受 Ruby（或 LISP）启发的角度为该语言带来的最迫切有用的“教训”之一是语言延展性。引入并非源自规范编写者内部阴谋的新功能、语法技巧和特定领域语言的能力将非常有价值。允许该语言成为对要进行的语言进行模块化扩展的好地方，并使这些扩展自托管，以最大程度地减少碎片风险并允许这些更改渗透并成为混搭等等。
这种延展性将允许整个社区应用来自各种方向的课程，并允许互联网随着时间的推移决定哪些课程值得从哪种语言学习，等等。我们已经有了一个在这个三明治的另一端发生高速迭代和进化，即在浏览器本身（例如：HTML5）和 js 库中。如果这能够在语言层面更紧密地发生，我们可以很快看到一些非常有趣的事情发生。
[附录/编辑]：
语言必须能够显着变化，因为一小部分人根本无法预料到它将用于的所有事情。 es-discuss 上经常出现的一个主题是设计“未来 10-15 年的语言”的潜在潮流。恕我直言，这是一个非常不切实际的目标。如果您不构建它，系统将在规范的预期生命周期之前很久就发展出替代方案。随着近来 javascript 引擎/JIT 技术的巨大加速，我们已经看到了以新语言的形式发生的早期迹象 在 JavaScript 之上 或在飞入 JavaScript。是的，甚至是 Ruby：http://hotruby.yukoba.jp/
【讨论】：
拥抱函数式编程，不要试图把它埋在静态语言结构中
【讨论】：
一个听起来像宝石的名字比一个听起来像皮肤病的名字要好得多。
但是不要用今天最热门的东西来命名你的新语言（这就是我们首先陷入这个“Java”脚本混乱的原因......）
【讨论】：
围绕大量使用闭包构建标准库，用于集合迭代和获取资源/收益资源/资源处置模式。这是 ruby 最大的胜利之一，imo。当然，实现这一点的部分原因是为每个方法提供了一个“免费”闭包参数，并提供语法支持，因此它在 javascript 中可能看起来不会那么好。不过，这些技术仍然有用。
【讨论】：
我看不出它可以从 Ruby 中学到多少东西。标准组已经为该语言提供了重新发送消息或向原型发送消息的方法。 method_missing 功能实现起来可能很酷，但它不像更好的反射工具那样必要。
【讨论】：