ECMAScript工作组已开始着手开发该语言的下一版本。他们可以从Ruby中学到什么?
最佳答案
实际上,这是一个比起初看起来更具挑战性的问题。
造成这种情况的主要原因是,事实证明,以规范的方式强制浏览器供应商在没有充分理由的情况下实现语言发烧友,用户,其他供应商或学者的宠爱或喜欢的功能非常困难。这就是我们最终将ES4规范抛在了桌上的原因,该规范产生的野心要小得多(尽管仍然非常出色),但ES Harmony却没有。像JavaScript这样的语言具有如此棘手的政治部署和实现问题,简直无法成为Ruby在其一生中一直以来令人敬畏的试验场。跟随es-discuss(ECMAScript语言开发邮件列表)的任何人现在可能已经注意到,要花很多时间进行辩论和实验才能清楚地表达并就通用语言功能达成共识,例如最近的记忆,运算符重载或简短。形式为lambda表示法。
要求任何工作组制定针对地球上所有设备的规范,也许要求太多了?从表面上看,这似乎是一个非常狭窄的类(class),甚至是社交类(class),可以很容易地从Ruby转移到JavaScript。
为此,并减轻Brendan Eich及其小组的负担:
从Ruby(或LISP)启发的 Angular 来看,最紧急的有用“教训”之一就是语言的可塑性。引入并非源自规范编写者内部的新功能,语法破解和特定 Realm 语言的能力将具有不可估量的值(value)。允许使用该语言作为进行该语言的模块化扩展以及将这些扩展扩展为自托管的好地方,以最大程度地减少碎片风险并允许这些更改渗透和融合等。
这种可延展性将使社区广泛地从各种方向上应用类(class),并允许Internet随着时间的推移决定哪些类(class)值得从哪种语言中获取值(value),等等。我们已经有了很高的迭代和发展速度该三明治的另一端,即在浏览器本身(例如HTML5)和js库中。如果能够在语言级别更紧密地发生这种情况,我们可以看到一些非常有趣的事情很快发生。
[附录/编辑]:
语言必须能够显着变形,因为一小群人根本无法预料将要使用的所有事物。 es-discuss上经常出现的一个主题是,设计“ future 10-15年的语言”的潜在潮流。恕我直言,这是一个非常不现实的目标。如果您不构建它,系统将在规范的预期寿命之前很久演化。随着最近javascript引擎/ JIT技术的飞速发展,我们已经看到了这种现象的早期迹象,形式是将新语言写在JavaScript 之上的或即时交叉编译到JavaScript中。是的,甚至是Ruby:http://hotruby.yukoba.jp/