Поскольку я являюсь единственным человеком, регулярно публикующим сообщения в SO, который был членом комитета по разработке языков C # и технического комитета ECMAScript, я, вероятно, могу предложить несколько идей.
Прежде всего, спасибо за ваши добрые слова о спецификации C #. Мы очень усердно работали над тем, чтобы сделать его читабельным, и приятно знать, что у нас это получилось.
Во-вторых, я отмечаю, что спецификация C # не всегда была такой. Спецификация C # 2.0 была написана как приложение к спецификации C # 1.0. Обобщения, блоки итераторов и анонимные методы оказали широкое влияние на многие разделы спецификации. Было очень трудно читать спецификацию 2.0 и прыгать между двумя главами, чтобы понять алгоритм реального разрешения перегрузки. Мэдс проделал огромную работу по редактированию в C # 3.0, чтобы сначала интегрировать все изменения в C # 2.0 в разумное место в спецификации, чтобы вам не пришлось прыгать повсюду.
В-третьих, большая часть того, что вы описываете, является результатом различий как в цели, так и в стиле главных архитекторов двух спецификаций. Представьте себе спектр «технических знаний» с бумагами о формальной корректности, написанными в основном греческими буквами с одной стороны, и журнальными статьями для начинающих с другой. Мы разрабатываем спецификацию C #, чтобы попасть в определенное место в этом спектре. Мы не хотим, чтобы это было учебное пособие для начинающих программистов, но хотим, чтобы оно было разумным документом для начинающих программистов на C #. Андерс особенно хотел избежать того, что он называет «высшей математикой спецификации».
Это разумный набор целей, заданных нашей целевой аудиторией для спецификации: профессиональные программисты, некоторые из которых хотят изучать C #, а некоторые хотят посмотреть точно, как что-то работает. Спецификация имеет расплывчатые аспекты обучения и точные аспекты семантического описания для обслуживания этих двух групп.
У Вальдемара Хорвата, основного автора спецификации ECMAScript 3, были довольно разные цели для спецификации E3 - не худшие, но разные цели. Цель спецификации E3 состояла в том, чтобы быть намного ближе к математически точному концу спектра. Вы заметите, что практически каждый раздел спецификации состоит по существу из псевдокодовых алгоритмов, которые описывают в довольно математически сложной прозе именно то, как влияет каждая операция на систему.
Вы заметите, например, что спецификация E3 говорит о разнице между "математическими" числами и их двоичными представлениями. Один черновик спецификации E4 даже зашел так далеко, что заметил, что существуют теоретико-множественные проблемы с наивным определением «типа» как набора значений, если типы также являются значениями. Подобные вещи были бы совершенно неуместны в спецификации C #; он не стремится иметь сильную теоретическую математическую основу для обеспечения его правильности. Вы заметите, что спецификация C # нигде даже не определяет «тип» - он был написан с предположением, что читатели будут профессионалами, которые (1) уже знают, какие типы предназначены для практических целей, и (2) не знают и не заботятся что теория множеств или теория категорий должна сказать о математической обоснованности любого определения «типа».
Целью процесса ECMAScript было объединение нескольких поставщиков очень похожих языков и согласование точного описания того, что было общим для всех этих реализаций. Спецификация E3 никогда не предназначалась для обучения любого рода, и в первую очередь предназначена для языка и инструментов разработчиков , а не для языка пользователей .
Спецификация Вальдемара на Е4 пошла еще дальше. Если я правильно помню, он начал с определения очень точного, простого «языка спецификации» с четкой семантикой. Затем он написал переводчик для этого языка в Common Lisp. Затем он написал спецификацию E4 на своем языке спецификаций. В результате он мог скомпилировать саму спецификацию в работающий интерпретатор ECMAScript . Это именно та «высшая математика», которую мы пытаемся избежать в спецификации C #. Это замечательный подход к спецификации, если вы хотите быть невероятно точным и точным, но это ужасный способ написать документ, которому пользователей языка могут научиться.
Это отвечает на ваш вопрос?