Mac*_*iek 15
这实际上是一个比最初看起来更具挑战性的问题.
其主要原因在于,通过规范,强制浏览器供应商很难在没有充分理由的情况下实现语言爱好者,用户,其他供应商或学者的宠物或喜爱的功能.这就是我们最终将ES4规格放在桌面上的原因,它产生了一个不太雄心勃勃(虽然仍然非常棒)的ES Harmony.像JavaScript这样具有如此疯狂的政治部署和实现问题的语言根本无法成为Ruby在其生命的大部分时间内实现的那种令人敬畏的实验游戏.任何一直关注es-discuss(ECMAScript语言开发邮件列表)的人现在可能已经注意到,需要花费很多个月的辩论和实验才能明确地表达并达成共同的语言特征,例如,在最近的记忆中,运算符重载或简短形成lambda表示法.
也许要求任何工作组制定针对地球上每个设备的规范可能太过分了？从表面上看,它似乎是一个非常狭窄的课程,甚至是社交课程,可以很容易地从Ruby转移到JavaScript.
为此,并减轻Brendan Eich及其团队的负担:
从受Ruby(或LISP)启发的角度来看,为语言带来最迫切有用的"课程"之一就是语言可塑性.引入新功能,语法黑客和特定领域语言的能力不是源于规范编写者的内心,这将是非常有价值的.允许语言成为对语言进行模块化扩展的好地方,并使这些扩展能够自我托管,从而最大限度地减少碎片风险并允许这些更改渗透并被混淆等.
这种可塑性将允许整个社区从各种方向应用课程,并允许互联网随着时间的推移决定哪些课程值得使用哪种语言等.我们已经在另一方面进行了高速迭代和演变.这个三明治的结尾,即在浏览器本身(例如:HTML5)和js库中.如果能够在语言层面上更紧密地发生这种情况,我们可以看到一些非常有趣的事情很快发生.
[附录/编辑]:
语言必须能够显着变化,因为一小部分人根本无法预测它将被用于的所有事物.在es讨论中出现的一个主题往往是设计"未来10 - 15年的语言"的潜在潮流.恕我直言,这是一个令人难以置信的不切实际的目标.如果你不构建它,系统将在规范的预期生命周期之前发展一个替代方案.随着最近javascript引擎/ JIT技术的巨大加速,我们已经看到了这种情况的早期迹象,即新的语言是在JavaScript之上编写的,或者是即时交叉编译成JavaScript.是的,甚至Ruby:http://hotruby.yukoba.jp/