Cha*_*ion 13 javascript c# ecma262
我一直在研究ECMAScript规范,并发现它非常难以阅读和理解.我经常不得不回溯以保持头脑中的概念.在阅读C#规范时,我能够学习该语言的组件而无需不断地移动文档.
Eri*_*ert 61
由于我是唯一经常在SO上发帖的人,他是C#语言设计委员会和ECMAScript技术委员会的成员,我可能会提供一些见解.
首先,感谢你对C#规范的客气话.我们非常努力地保持它的可读性,很高兴知道我们已经成功了.
其次,我注意到C#规范并不总是这样.C#2.0规范是作为C#1.0规范的附录编写的.泛型,迭代器块和匿名方法对规范的许多部分产生了广泛的影响.阅读2.0规范真的很痛苦,不得不在两章之间跳过来理解真正的重载决策算法.Mads在C#3.0中进行了大量的编辑工作,首先将所有C#2.0更改集成到规范中的合理位置,这样您就不必在整个地方跳转.
第三,您所描述的很大一部分原因是两个规范的主要架构师的目标和风格不同.想象一下"技术性"的一系列关于形式正确性的论文,一方面用希腊字母写成,另一方面用于初学者的杂志文章.我们将C#规范设计为落在该频谱上的特定位置.我们不希望它成为初学者程序员教程,但确实希望它成为初学C#程序员咨询的合理文档.安德斯特别希望避免他所谓的"规范的更高数学".
这是一个合理的目标,因为我们的目标受众是规范:专业程序员,其中一些人想要学习C#,而其中一些人想要准确查看某些内容是如何工作的.该规范具有模糊的教程方面和精确的语义描述方面,以便为这两个选区服务.
作为ECMAScript 3规范的主要作者,Waldemar Horwat对E3规范有着相当不同的目标 - 不是更糟糕的目标,而是不同的目标.E3规范的目标是更加朝向数学上精确的频谱结束.您将注意到,实际上规范的每个部分实际上都包含伪代码算法,这些算法在相当重要的数学文章中描述了每个操作对系统的影响.
例如,你会注意到E3规范谈到了"数学"数字和它们的二进制表示之间的区别.E4规范的一个草案甚至指出,如果类型也是值,则存在集合理论问题,其中"类型"的天真定义为一组值.这种事情在C#规范中完全不合适; 它并不寻求有一个强大的理论数学基础来确保其正确性.你会注意到C#规范甚至没有定义"类型" - 它的编写假设读者将是专业人士(1)已经知道什么类型是出于实际目的,(2)既不知道也不关心关于"类型"的任何定义的数学基础,什么样的理论或范畴论都要说.
ECMAScript流程的目标是让多个高度相似的语言供应商聚集在一起,并就所有这些实现中的共同点的准确描述达成一致.E3规范从未打算成为任何类型的教程,主要针对语言和工具实现者,而不是语言用户.
Waldemar的E4规格更进一步.如果我没记错的话,他开始指定一个非常精确,简单的"规范语言",语义清晰.然后他在Common Lisp中为该语言编写了一个翻译.然后他用他的规范语言写了E4规范.结果是他可以将规范本身编译成工作的ECMAScript解释器.这正是我们在C#规范中试图避免的那种"更高的数学".如果您想要非常精确和准确,这是一种非常棒的规范方法,但这是编写语言用户可以学习的文档的一种可怕方式.
这是否回答你的问题？