为什么 C# 和 ECMAScript 规范的可读性存在很大差异？
我一直在研究 ECMAScript 规范，发现它非常难以阅读和理解。我必须不断地回溯以将概念保留在脑海中。在阅读 C# 规范时，我能够研究该语言的组件，而无需不断浏览文档。
I have been studying the ECMAScript specification and have found that it is extremely hard to read and understand. I constantly have to backtrack to keep concepts in my head. When reading the C# specification I am able to study components of the language without constantly moving around the document.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
由于我是唯一一个定期在 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# 规范中试图避免的那种“高等数学”。如果您想要极其精确和准确，那么这是一种很棒的规范方法，但对于编写语言用户可以学习的文档来说，这是一种糟糕的方法。
这能回答你的问题吗？
As I am the only person regularly posting on SO who has been a member of both the C# language design committee and the ECMAScript technical committee, I can probably offer a few insights.
First off, thanks for your kind words about the C# specification. We've worked very hard to keep it readable and it is good to know that we've succeeded.
Second, I note that the C# specification was not always that way. The C# 2.0 specification was written as an addendum to the C# 1.0 specification. Generics, iterator blocks and anonymous methods had widespread impacts on many sections of the specification. It was a real pain reading the 2.0 spec and having to jump around between two chapters to understand the real overload resolution algorithm. Mads did a huge amount of editing work in C# 3.0 to first integrate all the C# 2.0 changes into a reasonable place in the spec so that you would not have to jump around all over the place.
Third, a big part of what you're describing is a result of differences in both goal and style of the principal architects of the two specifications. Imagine a spectrum of "technical-ness" with papers about formal correctness written largely in Greek letters at one end, and magazine articles for beginners on the other. We design the C# specification to fall at a particular place on that spectrum. We do not want it to be a beginner programmer tutorial, but do want it to be a reasonable document for beginner C# programmers to consult. Anders specifically wished to avoid what he calls "the higher math of the specification".
This is a reasonable set of goals given our target audience for the spec: professional programmers, some of whom want to learn C#, and some of whom want to look up precisely how something works. The spec has vague tutorial aspects and precise semantic description aspects in order to serve those two constituencies.
Waldemar Horwat, the principal author of the ECMAScript 3 spec, had rather different goals for the E3 spec -- not worse goals, but different goals. The goal of the E3 spec was to be far more towards the mathematically precise end of the spectrum. You'll note how practically every section of the specification consists of essentially pseudocode algorithms that describe in rather math-heavy prose precisely what the effect of each operation is on the system.
You'll notice for example that the E3 specification talks about the difference between "mathematical" numbers and their binary representations. One draft of the E4 spec even went so far as to note that there are set-theoretic problems with a naive definition of "type" as a set of values if types are also values. This sort of thing would be completely out of place in the C# spec; it does not seek to have a strong theoretical mathematical underpinning to ensure its correctness. You'll note that the C# spec nowhere even defines "type" -- it was written with the assumption that the readers will be pro devs who (1) already know what types are for practical purposes, and (2) neither know nor care what set theory or category theory has to say about the mathematical well-foundedness of any definition of "type".
The goal of the ECMAScript process was for multiple vendors of highly similar languages to come together and agree on a precise description of what was in the common ground amongst all those implementations. The E3 spec was never intended to be a tutorial of any kind, and is primarily aimed at language and tool implementors, rather than language users.
Waldemar's E4 spec went even further. If I recall correctly, he began by specifying a very precise, simple "spec language" with clear semantics. Then he wrote an interpreter for that language in Common Lisp. Then he wrote the E4 spec in his spec language. The result was that he could compile the specification itself into a working ECMAScript interpreter. That is exactly the sort of "higher math" that we are trying to avoid in the C# specification. This is an awesome approach to specification if you want to be incredibly precise and accurate, but it is a terrible way to write a document that language users can learn from.
Does that answer your question?
您可能会遇到两种语言规范的可读性差异，因为它们是由不同的人群编写的，并且讨论采用不同对象范例的语言。
JavaScript 规范是在该语言经过几年的有机发展后由一个委员会编写的。 C# 规范是由一小群企业工程师编写的，同时该语言以受控的方式发展。
C# 是以类为中心的 OOP，而 JavaScript 是以原型为中心的。如果您对其中一个不如对另一个熟悉，那么某些材料一开始可能很难理解，尤其是当它涉及实现细节时。这并不一定表明规范的清晰度和可读性存在问题。
You are probably experiencing a difference between the readability of the specifications of the two languages because they were written by different groups of people, and discuss languages which employ different object paradigms.
The JavaScript specification was written by a committee after the language had evolved organically after several years. The C# specification was written by a small group of corporate engineers while the language was growing in a controlled manner.
C# is class-centric OOP and JavaScript is prototype-centric. It is possible that if you are not as familiar with one as you are with the other, then some material may be difficult to understand at first, especially when it gets into implementation details. That doesn't necessarily indicate a problem with the clarity and readability of a specification.
相对于传统语言JavaScript 是非常奇怪的。事实上，像 JavaScript 这样基于原型的流行语言并不多。 JavaScript 完全基于对象，所有对象本质上都是关联数组，函数也是一等对象。这通常不是您期望从语言中看到的情况，但是随着 Ajax 和浏览器端编程的流行，JavaScript 已成为 Web 语言。虽然这些奇怪的规范本可以避免，但我相信 JavaScript 可以带来一些有趣且富有创意的编码。例如，闭包是大多数新开发人员难以理解的事情，但根据我的经验，它们非常有用。该语言的语义有时会让开发人员误以为 JavaScript 是 C 的一种风格，但很快他们就意识到事实并非如此。
对我来说，C# 是编程语言的顶峰。这是正确的，符合学术期望。遗憾的是，微软是这种语言的主要驱动者。像我一样，我确信还有很多人会喜欢在非 Windows 系统上正确实现支持 C# 的平台（Mono 是朝着正确方向迈出的一步）。
如果您热衷于学习 JavaScript 而不是 JavaScript 框架，那么我强烈建议您继续阅读直接讨论 JavaScript 的书籍。但是，如果您打算入门并且不太关心 JavaScript 的细节，@bwawok 建议的书籍是正确的选择。
Relative to conventional languages JavaScript is very strange. In fact there aren't too many popular languages that like JavaScript are prototype based. JavaScript is completely object based, and all objects are essentially associative arrays with functions too being first-class object. This isn't typically what you'd expect to see from a language however with popularity of Ajax and browser side programming JavaScript has become the language of the web. While these strange specs could have been avoided, I believe JavaScript can lead to some interesting and creative coding. Closures for example are the thing that most new developers struggle to understand but in my experience they are very useful. The semantic of the language at times fools developers to think JavaScript is a flavor of C but soon they realize this to be not true.
To me C# is the pinnacle of programming languages. It is correct and inline with academic expectations. Its a shame that MS is the primary driver of this language. Like myself I'm sure there are many others who would enjoy a proper implementation of a platform with support for C# on none Windows based system (Mono is a move in the right direction).
If you are keen to learn JavaScript and not a JavaScript Framework, then I really suggest to stick with books that directly discuss JavaScript. However if you are intending to get started and don't care much about the ins and outs of JavaScript @bwawok suggestion of books is the right way to go.
嗯，你是我认识的第一个尝试根据 ECMA 文档学习语言的人。无论如何，我想说，差异主要是由于编写规范的人的技能造成的。 C# 显然更容易指定（由于动态性较差 - 正如已经指出的），但最后......
...IIRC JavaScript 是由委员会设计的（很多人也在规范上编写），而 C# 最终由 Microsoft 一个人完成，可能一路上有 1-2 位作者和一些帮助者，但最终它是 Anders Hejlsberg（希望我拼写正确）。由委员会设计并必须对事物进行投票有时可能会导致文件的“设计”不太理想。
所以，最后我认为这与编写不同规范的人的技能有关，其中一个规范比另一个规范更难阅读。
Well, you are the first person I know of trying to learn a language based on the ECMA documents. Anyhow, I would say the difference is mostly due to the skill of the people writing the specs. C# is obviously a little easier to specify (due to the less dynamic nature - as already pointed out), but at the end...
...IIRC JavaScript is design by committee (many people writing also on the spec), while C# was done by Microsoft by ONE person at the end, maybe with 1-2 authors along the way and some helpers, but at the end it is Anders Hejlsberg (hope I spelled that right). Design by committee and having to vote on things may sometimes lead to less optimal "design" of a document.
So, at the end I think it is about the skill of the people writing the different specifications that one is harder to read than the other.
部分原因是您链接到的标准实际上是 ECMAScript。 JavaScript、JScript 和 ActionScript 都是 ECMAScript 的实现，而 ECMAScript 的编写是为了包含每个脚本的公共部分。相比之下，C# 主要由 Microsoft 的三个人设计（根据 ECMA-334 标准）。
除此之外，您必须接受 编写 ECMAScript 标准的委员会。
Part of the reason is that the standard you link to is actually ECMAScript. JavaScript, JScript and ActionScript are all implementations of ECMAScript, and ECMAScript was written to encompass the common parts of each. In contrast, C# was designed primarily by three people (according to the ECMA-334 standard) at Microsoft.
Other than that, you'd have to take it up with the committee that wrote the ECMAScript Standards.
简而言之，这可能是因为它们是由不同的作者写的。 C# 规范是由微软编写的，微软对使其变得更好（以便它被接受）有着既得利益，而 ECMAScript 规范是在该语言已经使用后由一个委员会编写的。
Put simply, it's probably because they were written by different authors. The C# spec was written by Microsoft who had a vested interest in making it good (so that it would be accepted) whereas the ECMAScript spec was written by a committee after the language was already in use.
最好的部分是，C# 可以从一台计算机运行到另一台相同的计算机（是的，.net 版本中可能存在细微差别，但通常会表现良好）。 Javascript 在 Internet Explorer、FireFox 和 Chrome 之间的运行方式非常不同。
例如，您有一个带有元素的网页
，并且您运行 JavaScript
Internet Explorer 将获取该元素（即使这是错误的行为，没有 ID 为 fred 的元素），但 Firefox 会给您一个 null。
这很可能是因为语言的发展方式所致。 C# 由 1 家公司开发，开发人员被迫遵循标准，否则他们的代码将无法运行。 JavaScript 在许多不同的浏览器中以不同的方式实现，人们可以自由地添加、删除或更改他们认为合适的功能。
总而言之，由于 JavaScript 的历史，它比其他语言需要更多的学习时间。研究一下像 JQuery 这样的优秀库来抽象出浏览器差异，您应该足够快地掌握它的窍门。从文档中学习只是学习语言的一小部分......做一些编码并了解它是如何工作的，它就会有意义。
Well the best part is, C# will run from one computer to another the same (yes maybe minor differences in .net versions, but stuff will generally behave). Javascript will run very different between internet explorer vs firefox vs chrome.
For example you have a webpage with an element
And you run the JavaScript
Internet explorer will get you the element (even though this is wrong behavior, there is no element with an ID of fred), but firefox will give you a null.
More likely than not, this is because of how the languages grew. C# was made by 1 company and developers were forced to follow the standards, or their code would not work. JavaScript was implemented in many different browsers in different ways, and people were free to add or remove or change functions as they saw fit.
In summary, JavaScript takes more work to learn than other languages because of it's history. Look into a good library like JQuery to abstract away the browser differences, and you should get the hang of it quick enough. Learning from a document is only a small part of learning a language... do some coding and learn how it works, and it will make sense.