В июле, редактор O`Reilly Джон Осборн посетил конференцию профессиональных разработчиков Microsoft, где взял интервью у Андерса Хейлсберга, выдающегося специалиста и ведущего разработчика C#, о платформе Microsoft .NET и языке программирования C#. Андерс Хейлсберг известен как человек, который разрабатывал Turbo Pascal, один из первых языков доступных на PC. Андерс лицензировал Turbo Pascal корпорации Borland и впоследствии возглавил команду, создавшую Delphi, действительно удачное визуальное средство разработки клиент-серверных приложений. Также в интервью принимали участие Тони Гудхью (Tony Goodhew) - Microsoft менеджер C#, и редактор раздела Windows в O`Reilly - Рон Петруша (Ron Petrusha).

Осборн: Я уже читал статьи в прессе о C# [произносится C sharp] и отметил, что многие из них поддерживают предположение (или гипотезу), о том, что C# является клоном или замещением Java от Microsoft. Если вы бы писали заголовки, что бы вы сказали людям об этом языке?

Хейлсберг: Во-первых, C# это не клон Java. Во время разработки C# мы смотрели на множество языков. Мы смотрели на C++, смотрели на Java, на Modula 2, C и SmallTalk. Существует много языков, имеющие основные идеи, такие же, как и те, которые использовали мы - например, полная объектная ориентированность, объектная простота и прочее.

Одно из ключевых отличий С# от других языков, в частности Java, в том, что мы пытались как можно больше приблизиться к C++. C# наследует большинство операторов, ключевых слов и выражений напрямую из С++. Мы также включили несколько особенностей этого языка, которые были забыты в Java. К примеру, почему в Java нет перечислений (enums)? Я имею ввиду, в чем смысл их исключения? Перечисление - здоровая и имеющая смысл концепция в С++. Мы оставили перечисления и сделали их также защищенным типом. В C# перечисления не просто целые. Теперь это в действительности мощный тип, который наследуется от System.Enum в библиотеке базовых классов платформы .NET. Перечисление типа "foo" не может быть неявно преобразовано в перечисление типа "bar". Мне кажется это важное отличие. Мы также оставили оператор перегрузки и преобразования типов. Вся наша структура пространств имен очень близка к C++.

Но в отличие от большинства традиционных языков, одним из наших ключевых достижений в разработке C# является его компонентная ориентированность, добавление в структуру языка всех концепций, которые могут понадобиться для написания компонентов. Такие концепции как опции (properties), методы, события, атрибуты, и документация являются конструкциями первого уровня в языке C#. Работа, которую мы проделали над атрибутами, особенностью используемой для добавления типизированных метаданных к любому объекту, является абсолютно новаторской. Я не видел подобного ни в каком другом языке. Также C# - первый язык работающий с XML тэгами комментариев, что может использоваться компилятором для создания документации прямо из исходного кода.

Еще одна важная концепция, то что я называю "все покупки на одной остановке". Когда вы пишете программу на C#, вы пишете все в одном месте. Не требуется файлов заголовков, IDL (Interface Definition Language) файлов, GUID и запутанных интерфейсов. И как только вы напишете приложение, которое будет само себя описывать, вы сразу можете начать его внедрять, так как оно является самодостаточным блоком. Вы можете связать его с ASP и расположить в любом из окружений, даже там, где ранее это было невозможно.

Вернемся к теме концепции компонентов. Было много споров о том, должны ли языки поддерживаться опции (properties) или события. Конечно, мы можем заменить эти концепции методами. Мы можем именовать паттерны как "get" и "set" блоки, которые заменяют использование опций. Мы можем использовать интерфейсы и адаптеры, которые реализуют интерфейс и обращаются к объекту. Мы можем это делать, также как мы можем писать объектно ориентированный код на C. Просто это сложнее и тут больше пыльной работы, а от этого в результате можно растерять все свои изначальные идеи. Просто мы думаем, что пришло время для языка, который позволяет легко создавать компоненты. Сегодня разработчики разрабатывают компонентное программное обеспечение. Они не пишут программы-монолиты или монолитные библиотеки классов. Каждый строит компонент, который наследован от другого базового компонента, поставляющегося некоторым окружением. Эти компоненты перекрывают некоторые методы и опции, реагируют на определенные события. Просто необходимо чтобы эти концепции входили уже в первые классы.

Осборн: Вы не давно написали вступление к C#, и в первом же заголовке говорили: "Первый компонентно ориентированный язык в семействе C/С++."

Хейлсберг: Да, это одно из моих главных достижений. Мы думали о том, как все что угодно превратить в объекты, и это имеет очень большое значение. В языках вроде SmallTalk и Lisp это было сделано и ранее, но тому была слишком большая цена. На мой взгляд в C# содержится ряд очень интересных новаций для облегчения разработки компонентов, например, понятие boxing и unboxing. Boxing позволяет значение простого типа преобразовывать в объект, в то время, как unboxing позволяет значению объекта быть представленным в виде значения простого типа. Не то чтобы это нигде раньше не встречалось, просто способ реализации этого в языке действительно новый и красивый.

Проектируя C# и .NET framework, мы пытались не ставить себе недостижимых целей. Мы не можем позволить себе переписать все наши программы. Индустрия не может этого позволить, особенно сейчас, когда мы входим в эпоху Internet. Уже достигнуто многое, и очень важно обеспечить взаимодействие программ между собой. Мы обратили сильное внимание на предоставление программистам всех действительно хороших возможностей взаимодействия с Internet стандартами, такими как HTTP, HTML, XML, и с существующими Microsoft технологиями, так что сильно не удивляйтесь когда обнаружите нечто, не реализованное в новой платформе .NET, или когда поймете, что хотите опереться на какой-либо существующий API или компонент. Вы увидите, что все возможные взаимодействия с COM были встроены в язык и платформу. Вы увидите как просто вы можете импортировать существующие DLL, используя атрибут DllImport. В увидите, даже если никогда не будете это использовать, что мы определили понятие небезопасного (unsafe) кода. Небезопасный код позволяет вам писать встроенные C программы, использовать указатели, небезопасные приведения типов и распределение памяти, которое не приведет сбою при сборке мусора.

Было много обсуждений по поводу небезопасного кода, многие считали нас наркоманами или что-то в этом духе. Я думаю, что это просто непонимание. То, что код помечен как небезопасный вовсе не означает, что его ничто не контролирует. Естественно мы не просто добавили небезопасные указатели и тем самым подставили людей, которые скачивают небезопасный код из Internet. Небезопасный код сильно связан с системой защиты. Мы даем вам возможность писать проверяемые блоки кода, а не сходить с ума в поисках другого языка программирования или системы программирования для native кода. А ограничивая небезопасный код блоками, мы можем добиться большей защищенности программ, так как система будет понимать, что именно происходит. Тот факт, что вы пишите небезопасный код вовсе не значит, что вы выходите из пространства проверок. Просто ваш небезопасный код становится более эффективным.

Осборн: Расскажите поподробнее о том, как взаимодействует управляющая среда и небезопасный код.

Хейлсберг: Одним из свойств, характеризующих окружения, управляющие выполнением, как в SmallTalk, Java, и .NET CLR (общая среда выполнения), является то что они обеспечивают сбор мусора. А чтобы обеспечить сбор мусора, а особенно с современными сборщиками мусора, вам необходимо знать о выполняемом коде больше, чем вы знали о традиционном неконтролируемом коде. Для того чтобы находить мертвые объекты методом исключения, вам необходимо прогуливаться по стэку, опускаться до самых корней, и выяснять какие объекты живут и какие больше не используются. Несмотря на то, делать это возможно, требуется более близкая связь между кодом, который вы выполняете. Код должен описывать многое. Нужно чтобы он говорил, как он расположен в стеке, где его локальные переменные и так далее.

Когда вы пишете программу на C#, вы имеете возможность делать не типозащищенные операции, например, работа с указателями. Код, естественно, маркируется как небезопасный, но это не значит, что он будет запускаться в недоверяющей среде. Чтобы запустить код, вы должны заслужить доверия, если вы этого не сделаете - код запущен не будет. В этом отношении он не отличается от других примеров native кода. Настоящее различие заключается в том, что он все же выполняется в контролируемом пространстве. Методы, которые вы пишете, будут иметь таблицы описаний, они скажут вам какие объекты живы, и не придется пересекать границу порядка при переходе к этому коду. В отличие от этого, когда вы переходите к неописанному, неуправляемому коду (как например, в Java Native Interface), вам необходимо использовать специальные метки или воздвигать барьер в стэке. Вам нужно пересортировывать все аргументы, которые располагаются вне блока. Используя объект вам нужно быть предельно осторожным, так как СМ [Сборщик мусора], все еще работает в другом потоке (thread). Он может удалить объект, если вы не закрепили его надежно, использованием некоторого скрытого метода, делающего объект закрытым. Если же вы забудите сделать это - полагайтесь только на свою удачу.

Мы применяем другой подход. Мы говорим: "Давайте обеспечим взаимодействие с языком. Давайте предложим фиксированные операторы, которые позволят вам закреплять объект, совместно с СМ". Путь по которому мы идем, позволяет оставить работать весь существующий код, вместо того чтобы просто его выкидывать. Это совершенно иной подход.

Осборн: Так память, с которой мы работаем в небезопасных блоках, на самом деле просматривается сборщиком мусора?

Хейлсберг: Да это так, но все это небезопасно. Вы можете получить указатель и сделать что-либо плохое. Но вы также можете сделать это в native коде.

Осборн: Еще одна тема, требующая разъяснений: где кончается C# и начинается CLR (общая среда выполнения). Где проходит граница между нововведения C# и тем, что просто взято из CLR (общей среды выполнения) библиотеки.

Хейлсберг: Я думаю этот вопрос имеет корни в том, что когда люди говорят о Java, никто себе полностью не представляет где там язык, а где среда выполнения. Что хотят сказать люди, говоря Java? Они имеют ввиду язык Java, синтаксис Java, или платформу Java. Люди сливают эти разные вещи в одно целое. Мы выбрали подход, который говорит о том, что мы желаем иметь многоязыковую платформу. Мы действительно разрабатываем платформу, которая позволит вам использовать множество языков, которые будут иметь одинаковый набор API. Давайте возьмем пример. Некоторым людям нравится программировать на COBOL, некоторым нравится на Basic, кто-то любит C++, и кто-то полюбит C#, я надеюсь. Мы не просим вас забыть о том, что вы делали раньше. Мы не говорим, что будет развиваться один язык, а с остальными ничего нового не произойдет. Мы говорим, что наша индустрия хороша своей гибкостью. Что произошло с Java? Это произошло потому, что были языки программирования до Java, будут и после нее. Мы хотим создать платформу, где вы будете выбирать, каким языком пользоваться, на основе своих собственных предпочтений. Мы хотим создать платформу, в которой это действительно будет новацией. Кто помогает COBOL программистам сегодня? Кто приглашает их в Web? Только на платформе .NET вы можете использовать Fujitsu COBOL для создания ASP страницы. На мой взгляд это действительно революционно.

Осборн: Предоставляя возможность использовать множество языков на своей новой .NET платформе, почему вы выбрали именно C#, а не Visual Basic, С++ или даже COBOL? Что делает С# таким привлекательным?

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

Языки - забавная штука. Это дело вкуса. Язык это почти религиозная вещь, и выбор стиля жизни для программистов. Я хочу сказать, что мы не в праве выйти и сказать: "Вот платформа, на которой вы имеете один базовый язык". Даже если вы можете сделать все что угодно на этой платформе, пользуясь этим одним языком, некоторым людям может не нравиться его синтаксис, им могут нравиться фигурные скобки или что-то другое в качестве разделителей блоков. Это то, к чему они привыкли. Это то, что позволяет им чувствовать себя как дома, и их продуктивность увеличивается. Наш подход к C# - быть альтернативой для программистов на C++, которые находят этот язык слишком сложным, и для программистов на Java, которые не довольны потерей некоторых особенностей C/C++ при переходе. Мы искали пути упрощения С++ и представили результат на многоязыковой платформе, которая предоставляет возможность более тесного межвзаимодействия и имеет все компонентные концепции.

Гудхью: Проанализировав ситуацию, мы отметили один очень интересный факт - 60% разработчиков на профессиональном рынке используют два или более языков программирования для создания своих приложений. Мы поняли, особенно узнавая, какие именно средства разработки используются, что невозможно создать один объектно-ориентированный язык, который во всем устроит каждого. Как ранее заметил Андерс, люди используют разный синтаксис в соответствии с их собственными чувствами. Это личный выбор. И это то, для чего вся платформа .NET, дающая разработчикам право выбора - на каком языке писать. Мне кажется что бы сделали просто замечательную работу. Вы можете просто делать одни и те же вещи на Visual Basic, .NET, или C#. Visual Basic до сих пор видится, как наиболее доступный для программистов. C# дает больше свободы и мощности, чем VB.

Осборн: Вы имеете ввиду, что в C# можно сделать больше с помощью меньшего количества операторов?

Хейлсберг: Я имею ввиду, что вы имеете больше мощности благодаря предоставлению возможности писать небезопасный код.

Осборн: А в VB нельзя писать небезопасный код?

Хейлсберг: Нет, нельзя.

Гудхью: Но на самом деле оба языка делают практически одно и то же. Есть значительные отличия от того, что было раньше, в Visual Studio 6. Используя Visual Studio 6.0, вы не могли написать многопоточный MTS объект на VB. Вам нужно было использовать С++. Теперь, на платформе .NET, вы можете использовать тот язык, который хотите.

Хейлсберг: Это то, о чем я рассказывал в основное время этой конференции - унификация программных моделей, которую предлагает .NET. Развитие языков и платформ, мы всегда мечтали прекратить тесную связь между языком и конкретным API или конкретной формой программирования. VB был для быстрой разработки приложений, MFC были чем-то вроде подклассов, а ASP служили для выкладывания чего-либо на Web. К каждом случае, выбираемая вами модель программирования диктовала вам язык программирования и доступные API. Это добавляло в процесс ваших разработок головную боль от изучения новых языков и API, каждый раз когда вы перевыбирали платформу. Мы действительно попытались навести порядок. Мы предлагаем один API, одно средство визуальной разработки и право выбирать с каким языком работать.

Осборн: Очень интересно что будет с скриптовыми языками, такими как JScript и VBScript?

Хейлсберг: Одной из замечательных вещей, произошедшей со скриптами в .NET, является то, что они стали компилируемыми. Взгляните на ASP+. Теперь, вы в действительности запускаете откомпилированный код на своих страницах. Разработчики ASP+ могут использовать всю мощь VB.NET, вместо VBScript. Первое время, они имеют возможность использовать Perl и Python, или другие популярные языки, если захотят.

Петруша: Server-side JavaScript будет компилироваться?

Хейлсберг: Да, это так.

Гудхью: Платформа .NET позволяет использовать скриптовые языки также, как и полноценные языки, так как они имеют доступ к действительной среде программирования и таким же API базовых классов. Вы должны увидеть что сделали парни, которые занимались реализацией JScript. За небольшими маловажными исключениями (для обратной совместимости), JScript - полная реализация ECMA стандарта. Таким образом, платформа .NET предоставляет межъязыковую среду, которая является большим прорывом для разработчиков скриптов.

Осборн: Мы уже говорили о Java, C++ и скриптах. Здесь я слышал от многих людей, что в действительности нет разницы между .NET IL (IL это промежуточный язык Microsoft, который должны производить все компиляторы, для запуска на платформе .NET) и Java байт-кодом, который воспринимается виртуальной машиной Java (JVM). Из ваших слов понятно, что вы с этим не согласны. Не могли бы вы указать основные различия?

Хейлсберг: Конечно. Во-первых, идея IL - очень старая идея. Вы можете найти ее в концепции UCSD Pascal p-машины (ранняя реализация Pascal для персональных компьютеров) или в SmallTalk p-коде, и использование в Basic и VB. Части Word, внутренне используют механизм p-кода, так как он более компактен. Так что p-код вовсе не нов.

Я думаю, что подход, который мы применили в IL, интересен тем, что вы получаете дополнительные возможности контроля при преобразовании IL в native код. В С++ вы в действительности могли получать native код прямо из исходников. С++ может так же создавать IL, как и C# или VB. И когда вы устанавливаете код, мы даем вам возможность компилировать его на этом компьютере. Вы можете откомпилировать IL в native код определенного компьютера, и при запуске вы уже не будете иметь надстройки в виде JIT компиляции. Мы также предоставляем вам возможность запускать и компилировать код динамически - JIT компиляция. И конечно, присутствие IL добавляет возможностей, например, допустимость переноса на разные архитектуры процессора и предоставление проверки во время типовой защищенности, а далее построение системы безопасности поверх всего этого.

Я думаю, что одно из главных отличий между нашей реализацией IL и Java байткодом в том, что мы приняли решение не делать интерпретаторов. Код, который мы запускаем, всегда native. Даже когда вы создаете IL, он никогда не будет интерпретироваться. Мы имеем даже разные стили JIT компиляции. Для небольшой платформы у нас есть EconoJIT, мы назвали его так, потому что это очень простой JIT [Прим. ред.: .NET Compact - это подмножество среды .NET, созданная для переноса на другие устройства и платформы.]. Для desctop версии мы создали более полный JIT, и у нас есть даже JIT, который дает такие же результаты как наш C++ компилятор. Так как он требует больше времени, вы могли бы использовать его во время установки ПО.

Решение предпочесть запуск native кода интерпретации, оказало большое влияние на форму IL. Это поменяло набор включенных инструкций, и порядок их расположения. Если вы посмотрите на два IL, то сможете отметить, что они очень разные. Чувствуется, что наш IL нейтрален к типам. Нет информации в инструкциях, которая говорила бы о типах аргументов. Только подразумевается, что было положено в стэк. Этот подход делает IL более компактным. JIT компилятору в любом случае нужна эта информация, так что нет смысла хранить ее в инструкциях. Теперь вы знаете о некоторых разных решениях, которые позволяют проще переводить IL в native код.

Осборн: Какие различия между интерпретацией и вашим подходом вы можете отметить?

Хейлсберг: В основе интерпретации лежит цикл, берущий несколько байт из потока p-кода, и затем они отправляются к большому оператору переключения, который говорит: "это была операция сложения, теперь мы проходим через нее. Но этого не произошло" - и так далее.

Интерпретатор эмулирует процессор. Мы переворачиваем это сверху вниз и выполняем один проход - мы всегда выполняем один проход, когда переводим инструкции в машинный код. Это машинный код в случае EconoJIT, в действительности очень прост - это просто набор вызовов и push инструкций, и вызовов помощников из среды выполнения. Естественно даже такой код запускается во много раз быстрее.

Осборн: Так, давайте пройдем еще разок. Вы полностью компилируете код. Потом, когда вы закончите, будете иметь последовательность готовых к запуску битов. Однако в точке перевода IL в машинный код могут быть изменения.

Хейлсберг: Да. Но потом, если это среда построенная в памяти на небольшом устройстве, мы можем выкинуть код после использования.

Осборн: Возвращаясь назад к обсуждению синтаксиса языка: Меня интересует, включает ли C# встроенную поддержку регулярных выражений. Я не увидел ничего об этой поддержке в руководству по языку, но может быть она существует где-либо в другом месте.

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

Осборн: Кажется, существуют различия между тем, как нам следует смотреть на пространства имен в C# и Java. Концептуально это одно и тоже? Или они реализованы по разному?

Хейлсберг: Концептуально да, но их реализации вовсе не похожи. В Java имена пакетов имеют также и физический смысл, который указывает на структуру директорий ваших исходных файлов. В C# мы имеем полное разделение между физическим расположением и логическим именованием, так, если вы вызовете ваше пространство имен, то ничего не произойдет в реальном физическом хранилище вашего кода. Это дает вам свободу располагать модули вместе в физических пакетах, не принуждая вас иметь соответствие в директориях. В самом языке, конечно, тоже существуют отличия. Так как в Java пакеты имеют также и физическую структуру, исходный файл должен располагаться в верной директории и иметь только один public класс или public тип. В виду того, что в C# нет такой связи физического и логического расположения, вы можете именовать свои исходные файлы как захотите. В каждом файле может содержаться несколько пространств имен и несколько public классов. Таким образом вы можете записать весь ваш исходный код в один файл или расположить его в нескольких маленьких. Концептуально во время компиляции происходит следующее - вы передаете все исходные файлы вашего проекта компилятору, а он уже решает что с ними делать.

Осборн: У меня есть вопрос о настраиваемом программировании: Вы считаете, что это важная концепция и она должна быть частью объектно ориентированного языка. Если это так, то каковы ваши планы реализацию настраимового программирования, как части C#.

Гудхью: Кое-что из того, что мы собирались включить в первый релиз, было создано - вопреки тому, что все думают о Microsoft - у нас нет неограниченных ресурсов. Мы приняли несколько трудных решений о том, что действительно будет в первом релизе.

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

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

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

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

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

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

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

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

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

Осборн: Это доступно во всех языках платформы .NET?

Хейлсберг: Да. Исследовательский центр Microsoft Research в Кэмбридже создала версии общей среды выполнения и компилятора C#, допускающие настройки. Мы ищем путь внедрения этого. Похоже что этого не произойдет в первом релизе. Но мы сейчас работаем над тем, чтоб убедиться, что не делаем каких-либо вещей в первом релизе, которые не восприняли бы картины настроек.

Осборн: Когда вы планируете выпустить C#, платформу .NET и следующую версию Visual Studio?

Гудхью: Мы уже раздали здесь обзорную версию технологии 6500 посетителям конференции. Мы собираемся некоторое время (2000 год) использовать beta версию, а далее, когда все будет готово, сделаем релиз. Одна из вещей, которую мы действительно проделали - это подробный анализ, того, как прошел релиз Windows 2000, и путей вовлечения некоторых клиентов в процесс разработки и распространения. В случае платформы .NET и Visual Studio, мы будем вновь работать с клиентами, чтобы понять, когда все это действительно будет готово к релизу. Пусть они скажут нам, когда продукт готов. И по причине того, что в процесс вовлечены реальные клиенты, продукт обещает быть качественным. Другой стороной этого процесса является приобретение некой неопределенности. Мы ориентируемся на качество продукта, а не просто выбираем дату выпуска.

Осборн: Таким образом дату, когда будет написан весь код, вы заменяете датой, когда продукт будет готов работать?

Гудхью: Да это так. Я думаю, что разработчики узнают релиз Visual Studio .NET, как один из наиболее качественных релизов за всю историю Microsoft.

Осборн: Вы послали C# в ECMA. Является ли стандартизация действительно настолько важной? Хотите ли вы, чтобы C# был доступен на других платформах.

Хейлсберг: Очень важно. Мы действительно хотим представить C# в индустрии настолько стандартизированным, насколько это возможно, поэтому мы и послали запрос в ECMA. Мы также надеемся найти в ECMA поддержку, для процесса создания общей языковой инфраструктуры, для языков, имеющих схожую сущность. Под общей инфраструктурой я имею ввиду общую специфицированную библиотеку классов, которую разные компании использующие разные платформы будут реализовывать, для ипользования в своих программах на своих платформах.

Гудхью: Я хотел бы отметить, что мы используем подход действительно открытых стандартов, вместе с ECMA. Если ECMA стандартизует C# и CLI (Common Language Infrastructure - общая инфраструктура языков), результатом будет доступность в соответствии с лицензиями и копирайтами ECMA, которые действительно открыты. Любой человек мог бы лицензировать ECMA C# стандарт, его подмножество или надмножество, и не должен был бы платить за это деньги. Они могли бы взять это и реализовать на любой платформе или устройстве. Мы рассчитываем, что люди будут делать это. Это отличает нас от наших конкурентов, которые изучают стандарты, выглядывая тех, кто скопировал их собственные языки.

Джон: О каком переносе на платформу, в инфраструктуре которой нет поддержки COM объектов, может идти речь?

Хейлсберг: Это действительно возможно. COM вообще не нужен для стандартизации C# или CLI. C# имеет модель классов, которая богата сама по себе, а COM это всего лишь один из взглядов на то, как приложения могут взаимодействовать. Но ничего в основах C# или CLI не говорится о том, что это должен быть COM, GUID, HRESULT, Addref или Release. Ничего подобного. Общая среда выполнения .NET полностью исключает это. Но дает прекрасную возможность взаимодействия посредством COM, о котором я буду всегда думать как об очень важной особенности, по причинам ранее указанным. Но вовсе не необходимой.

Гудхью: Я думаю, что некоторые из предыдущих вопросов имеют своей причиной то, что мы выпустили начальную версию руководства по языку, которая свободно доступна. Microsoft создала ее на встречах, где мы думали в первую очередь в терминах платформы Microsoft .NET. В результате мы ссылались на такие вещи, как COM и DLL, когда, например DLL одно из решений более глобальной проблемы - использование native кода на заданной платформе. Одна из выгод работы с организацией по стандартизации и работы с такими людьми, как IBM, с которыми мы создавали SOAP спецификацию, это то, что мы не делаем таких ссылок, которые затем будут нас ограничивать как, например, платформа COM в будущих версиях спецификаций.

Как сказал Андерс, взаимодействие с COM и его поддержка очень важна для нас и для нынешних клиентов Microsoft. Я думаю, мы сделали полезную работу, включив поддержку COM в платформу .NET. Но люди из индустрии слышали много раз, как мы используем слова COM и DLL. Они заключили, что платформа .NET только для Windows, в чем они ошибаются.

Хейлсберг: И мне кажется, что раз COM взаимодействие очень важно для Microsoft и для людей, которые занимаются разработками на платформе Microsoft, стандартизация C# и CLI должна позволить в других реализациях придать большее значение взаимодействию с платформой, на которой реализуется язык.

Осборн: Вы не будете настаивать на понятиях "чистой C#" и "чистой .NET" реализации?

Хейлсберг: Что такое "чистый"? Как много "чистых" Java приложений существует? Я думаю очень и очень мало. Но это числа. Давайте возьмем пример. Люди хотят использовать существующий код. Нельзя требовать от компаний, отказываться от имеющихся вещей.

Гудхью: Был ли у вас шанс говорить с Роджером Сешионс (Roger Sessions) [прим.ред. Роджер Сешионс - президент ObjectWatch и автор COM+ and the Battle for the Middle Tier.] ?

Осборн: Нет не было.

Гудхью: Роджер занимался интересной частью спецификации EJB (Enterprise JavaBeans), которая говорила о допустимых для производителей расширениях. Расширения производителей содержат такие вещи, как управление транзакциями, которые очень важны в создании корпоративных систем, с точки зрения защиты, передачи сообщений и так далее. В статье Сешионс грубо перечисляет одиннадцать областей функциональности, которые допускаются в реализациях, зависимых от производителя. Если вы возьмете IBM Websphere, как свою EJB реализацию, код, EJB который вы будете писать, будет несомненно приковывать вас к Websphere. Так что разговоры о том, что Java "стопроцентно чиста" - не правда. Существует очень хорошее интервью с Джеймсом Гослингом (James Gosling) на сайте разработчиков IBM. Он говорит, что реальные "написал однажды - запускается везде", 100% "чистые" приложения - в действительности бестолковая идея, и вообще предмет маркетинга. Он сказал сгоряча: "Мы даже не думали, что у нас будет возможность переносить все это, и изначально ее не было". И это изобретатель языка говорит, что никакой "чистоты" при переносимости не существует.

Осборн: Не оставили ли мы без внимания какие-либо важные особенности и новации C#, о которых вы хотели бы сказать?

Хейлсберг: Есть одна вещь, касающаяся всей платформы .NET, и в частности C#. Это вопрос о создании распределенных приложений. Не так давно мы создавали связанные клинт-сервер приложения и объектные протоколы, такие как CORBA, IIOP, RMI, и пришедший позже DCOM. Такой тип программирования действительно подкрепляется EJB, реализующим основу для CORBA и RMI. Мы научились создавать эти хорошо связанные распределенные системы, но они не распространяемы. Они не распространяются по Web, так как они занимают свое место на сервере, и вы не можете просто переписать их на другой компьютер, положить их там и тем самым получить работающие копии.

Когда мы впервые засели за разработку платформы .NET, мы сделали шаг назад и посмотрели, что в действительности происходит с Web. Он становится распределенным миром с хорошим сообщением, мы попытались понять, что это может дать нашей модели программирования. И мы начали разработку с самого начала опираясь на то, что в распределенное приложение соответствует модным свойствам - имеет повсеместные связки и независимость от конкретного места, что дает вам возможность распространения. И как только мы приняли такое решение, все изменилось. Это изменяет способы создания простых сервисов, структуры сообщений для взаимодействия, и даже меняет оформление пользовательского интерфейса. Это новая модель программирования. Мы решили использовать XML и SOAP, чтобы сделать эту модель рабочей. Они сильно интегрированы с .NET, и эта интеграция в основе каждого нашего решения, которые мы делали, создавая платформу .NET. И это не то, мимо чего вы могли бы пройти, или вернуться позже.

Осборн: Не могли бы вы указать случай, где программист это будет использовать?

Хейлсберг: Один хороший пример - как XML интегрируется с C#. Мы имеем понятие атрибутов в C#, которые позволяют вам добавлять определенную информацию к типам и членам. Просто помимо того, чтобы сказать, является метод public или private, хочется еще сказать, позволяет ли он удаленный вызов, может ли он быть Web сервисом, или представляется ли он как XML. Мы добавили атрибуты для реализации механизма настроек, а потом мы применили их во всей инфраструктуре Web сервисов и XML. Мы также дали вам возможность добавлять атрибуты к классам, и к полям классов, говорящие: "Когда этот класс представляется в виде XML, он должен стать "этим" именем тэга, и должен поместиться в "это" пространство имен XML". Мы даем вам возможность указывать поля, которые в одном месте буду элементами, а в другом атрибутами. Мы даем вам возможность контролировать схему исходящего XML, контролировать это, когда вы даете определение класса так, что вся дополнительная определяемая информация будет доступной. Когда атрибуты используются для украшения вашего C# кода, система может просто превратить их в XML и переслать. Все это происходит в одном месте. Это отличается от файлов доопределений или разнообразных инфо и паттернов именований.

Я знаю, что немного отхожу от темы, но хочу сказать, что кое-что из поставляемой нами инфраструктуры - правда удивительные вещи. Например, имея эти атрибуты, вы можете запрашивать у нашей инфраструктуры вывода XML или Web сервисов представление любого заданного класса в виде XML. Когда вы это делаете, то получаете схему класса, XSD схему, мы создаем для вас специальный парсер, производный от нашего настраимового XML парсера (который является частью .NET классов), и переписываем методы и логику парсера специально для вашей схемы. Так мы реализовываем парсер, который со скоростью native кода будет разделывать XML. Если происходит ошибка мы выдаем вам красивое сообщение об ошибке, которое точно скажет вам, что именно не так. Затем мы кэшируем это в нашу инфрастуктуру кэширования кода, и это находится там до тех пор, пока в следующий раз не придет класс с такой же схемой и не скажет : "БАМ!".

Осборн: Как я вижу, тут скрываются очень интересные вещи.

Хейлсберг: Да, я думаю мы поведем поколение вперед, когда оно начнет думать об этом.

Осборн: Замечательно. Спасибо за уделенное время.

Хейлсберг: Всегда рады.