Осборн: Как много людей было вовлечено в разработку C#?


Хейлсберг: Группа разработки языка состояла из четырех человек, компилятора — из пяти.


Петруша: А всей платформы .NET?


Хейлсберг: Очень много. Вся компания этим занималась.


Гудхью: Во время разработки Visual Studio и платформы .NET, этим занимался легион примерно из тысячи человек. Туда входили программные менеджеры, разработчики и тестеры всех разделов продукта — окружений, сред разработки и выполнения, моделей программирования ASP и т.д.. Затем, такие люди как я, управляли всем этим.


Хейлсберг: В отношении настроек, о которых вы спрашивали — Я определенно думаю, что это очень полезная концепция. Нужно отметить что все исследования настроек происходили в академии и индустрии. Шаблоны — решение для этой проблемы. Во время наших внутренних обсуждений мы решили, что хотели бы включить это в нашу новую платформу. Чего мы действительно хотим — чтобы среда выполнения понимала настройки. Это отличается от того, как некоторые прототипы настроек были построены. Возьмите понятие стирания (erasure) в Java, в действительности у системы нет никаких представлений о настройках. Имея понимание концепции настроек, как в CLR, множество языков могут добиться большей функциональности. Вы можете писать на C# настраиваемый класс, а другой человек в другом месте будет работать с ним, используя другой язык.

Добавление настроек в среду выполнения, позволит вам делать некоторые вещи намного эффективнее. Установку настроек лучше всего производить во время выполнения. В C++, установка шаблонов происходила во время компиляции, а далее у вас было два варианта: или оставить свой код раздутым, или попытаться избавиться от раздутости во время компоновки. Но если у вас есть несколько приложений, вы можете забыть об этом. У вас просто будет раздутый код.

Добавив понятие настроек в общую среду выполнения, она стала понимать, что когда приложение или компонент запрашивают у нее список всех "Foo", оно задает себе вопрос "Имею ли я на данный момент реализацию (код, создающийся при вызове настраиваемой функции, в зависимости от параметров) списка Foo?". Если это так, использует его. Так, если Foo тип, передаваемый по ссылке, то реализация может быть одна для всех ссылочных типов. Если же тип, передаваемый по значению (вроде int или float) — то для каждого типа будет своя реализация. Но только тогда, когда приложение запрашивает ее. Мы проделали всю основную работу, необходимую для добавления распознавания настроек в среду выполнения.

Интересна связь между IL и распознаванием настроек. Если инструкции в IL содержат информацию о типах, например, если сложение это не сложение, а сложение int, сложение float или сложение double — у вас нет возможности настроек в таком случае. Наш формат IL вправду нейтрален к типам. И по причине нейтральности к типам, мы можем добавить возможность настроек позже, без каких-либо для нас проблем. Это одна из причин, почему наш IL выглядит иначе, нежели Java байткод. Он у нас нейтрален к типам. И инструкция сложение — это сложение двух элементов, находящихся вверху стэка. Это может быть преобразовано в иной код, когда настройки будут реализовываться.