Одной из самых модных тем, обсуждаемых сейчас разработчиками программного обеспечения, является, безусловно, платформа Microsoft .NET, .NET Framework, а также ожидаемое в ближайшем будущем средство разработки Visual Studio .NET. (Мы тоже неоднократно писали об этом в нашем журнале и еще не раз вернемся к данной теме.) Именно о платформе .NET, Visual Studio .NET и о новом языке программирования C#, вошедшем в состав Visual Studio .NET, пойдет речь в интервью с Андерсом Хейлсбергом - руководителем проекта создания и развития языка программирования C# и основным участником разработки Microsoft .NET Framework - которое он любезно согласился дать ответственному редактору КомпьютерПресс Наталии Елмановой.
КомпьютерПресс: Что вы можете рассказать о цели создания языка C#? Какова аудитория его пользователей?
Андерс Хейлсберг: Когда мы создавали язык C#, у нас было несколько целей. Прежде всего - создать первый компонентно-ориентированный язык из семейства C/С++. Если вспомнить, как производилась разработка приложений пять и даже десять лет назад, мы увидим, что многие разработчики уже тогда создавали специальное окружение для того, чтобы организовать запуск приложения по требованию, выполнение им определенной задачи и его остановку. С появлением феномена Web и архитектуры «клиент-сервер» природа приложений изменилась. Сейчас нередко создается набор компонентов, выполняющихся под управлением того или иного процесса, - бизнес-объектов для приложений среднего звена, хранимых процедур в серверах баз данных, и именно совокупность таких компонентов сейчас называется приложением.
Кроме того, мы имели в виду и то, каким образом разработчики сейчас проектируют и создают программное обеспечение. Современный подход к проектированию приложений (в том числе и HTML-страниц, и бизнес-объектов) обычно подразумевает использование концепции свойств, событий и методов компонентов или объектов, а также инспектора свойств для их изменения. Но если посмотреть на С++ и Java, то станет понятно, что они не полностью поддерживают ключевые концепции компонентов. Такие элементы, как свойства и события, не существуют в явном виде в этих двух языках. Вместо этого используются методы Get_…, Set_…, вызываемые для чтения свойств или их изменения. Нередко при применении этих языков для реализации той или иной функциональности приложения приходится создавать и использовать интерфейсы и другие сложные адаптеры. Отсюда следует, что для компонентно-ориентированного программирования и для всей индустрии в целом чрезвычайно важно встроить в языки программирования поддержку концепции компонента. Это и была одна из ключевых целей создания С#.
Нашей целью было также создание более продуктивной версии С++. Известно, что разработчики любят этот язык за его мощь и практически неограниченные возможности, но проблема применения С++ заключается в том, что его мощь используется в течение 1% времени, а 99% времени уходит на то, чтобы понять, какую конструкцию языка применить для решения той или иной задачи. Мы решили создать упрощенную версию С++, чтобы повысить производительность труда разработчиков. Поэтому язык C# содержит, в частности, средства сбора мусора, обработки исключений, что делает созданные с его помощью приложения более устойчивыми и надежными. Следует также отметить корректную работу с версиями, обусловленную самой платформой .NET, что избавляет разработчиков от проблем, связанных с существованием различных версий одной и той же DLL (DLL hell).
И еще одна особенность нового языка - его лучшая интероперабельность по сравнению с Java. Конечно, Java - прекрасный инструмент, но интероперабельный код, написанный на нем, оказывается весьма дорогостоящим, чего нельзя сказать о C#.
КП: Известно о стремлении Microsoft сделать C# и саму платформу .NET Framework индустриальным стандартом. Как в результате будет развиваться этот язык и каким образом в него будут вноситься изменения?
А.Х.: Мы уже передали на рассмотрение ECMA1 всю спецификацию C#, и если этот язык станет индустриальным стандартом, то внесение изменений в него будет производиться соответствующим комитетом по стандартизации с учетом предложений и мнений, поступающих от сообщества разработчиков (как это делается с С++). Мы готовы внести свой активный вклад в дальнейшее развитие С#.
КП: Вы отметили, что Java - отличный язык программирования. Но более важны не его особенности как языка, а то, что Java сейчас - это не просто язык, а платформа для разработки приложений, в том числе распределенных. Что вы думаете о том, как будет происходить конкуренция между платформами .NET и Java?
А.Х.: Если говорить о Java как о платформе для разработки приложений, то она ориентирована на один-единственный язык - Java. Что касается платформы .NET, мы изначально сделали ее многоязыковой. Создавая приложения для .NET, можно использовать C++, Visual Basic, JavaScript, Cobol, Fortran, другие языки программирования. Если рассматривать .NET с позиций интероперабельности и возвращения инвестиций в созданный код, явно видны ее преимущества - ведь на ней можно использовать ранее созданный код.
Еще одно преимущество .NET - это ориентация на XML Web-сервисы, то есть на ту архитектуру распределенных вычислений, которая представляется нам наиболее перспективной. Используя .NET, можно конвертировать объекты в XML и обратно с нулевыми трудозатратами. Поскольку Java как платформа появилась раньше, чем XML, то, естественно, можно использовать XML с Java, но такое использование не будет столь простым, как в случае .NET.
Наконец, я должен сказать, что у Microsoft и Sun разные подходы к стандартизации. Компания Sun дважды пыталась сделать стандартом Java, но ей не удалось убедить комитет по стандартизации принять все, что было ею сделано в этом языке. В данный момент Java не является стандартизованным языком. Мы же, со своей стороны, стремимся к тому, чтобы сделать C# таковым, равно как и саму платформу .NET.
КП: Если продолжить разговор о конкуренции .NET и Java, можно ли говорить о скором успехе платформы .NET на рынке корпоративных приложений? Следует ли ожидать появления C#-аналогов Java 2 Enterprise Edition, Enterprise Java Beans, поддержки .NET производителями серверов приложений?
А.Х.: Я совершенно уверен, что именно этого и следует ожидать. Мы соревнуемся с Java на рынке корпоративных приложений и можем противопоставить этой платформе такие технологии, как ASP .NET, корпоративные серверы для .NET (.NET Enterprise Servers).
КП: А что можно сказать о сторонних производителях серверов приложений - IBM, BEA, Oracle, других компаний? Ведь их продукты сейчас поддерживают Java и CORBA, а не .NET. Следует ли, на ваш взгляд, ожидать поддержки .NET в последующих версиях серверов приложений от этих фирм?
А.Х.: Это действительно так: производители серверов приложений сейчас поддерживают Java. Но нужно понимать, что это в определенной степени иллюзия. Если говорить о спецификации EJB, то это очень небольшой документ, описывающий минимум функциональности. И если объективно сравнить EJB для разных серверов приложений, например WebSphere и WebLogic, мы увидим, что их код не является стопроцентно переносимым между этими серверами - у каждого из этих серверов есть свои особенности.
Очевидно также, что трещина во взаимоотношениях IBM и Sun растет. IBM поддерживает множество технологий, включая Java. Я думаю, проблема заключается в том, что Sun, похоже, не стремится передавать спецификацию Java в организации, отвечающие за стандарты. Поэтому только Sun определяет правила, по которым развивается этот язык.
КП: Вернемся к Java как к языку программирования. Что вы можете сказать о поддержке Java в .NET? Означает ли стратегия JUMP to .NET2, объявленная Microsoft в начале этого года, что Microsoft таким образом стремится полностью избавиться от Java как от языка?
А.Х.: Нет, совсем не полностью! В действительности стратегия JUMP to .NET означает примерно то же, что и нынешнее наше обещание создать такой язык, как J#, - язык с синтаксисом Java для .NET. Сейчас нам также нужны все аналоги библиотек Java вплоть до версии 1.1.4 - это действительно необходимо для поддержки существующего Java-кода. Но полной реализации J2EE для .NET не будет, поскольку это явилось бы не более чем дублированием уже имеющейся функциональности.
КП: Что делает Microsoft для поддержки .NET в средствах разработки других производителей? В России, например, имеется немалое количество пользователей средств разработки Borland, и для них этот вопрос немаловажен. Я имею в виду не Pascal для Visual Studio .NET, а что-нибудь типа Delphi .NET c собственной средой разработки и, возможно, со своими библиотеками классов или компонентов, то есть что-то вроде .NET-версии Visual Component Library.
А.Х.: Я не берусь комментировать планы компании Borland относительно дальнейшего развития ее продуктов. Техническая возможность создания Delphi поверх .NET и CLR, безусловно, есть. Можно также портировать VCL в .NET. Но выбор остается за Borland.
КП: Наши читатели, особенно пользователи Delphi, были бы рады услышать от вас несколько слов о том, как создавался этот продукт, и узнать ваше мнение по поводу его влияния на дальнейшее развитие индустрии средств разработки.
А.Х.: Delphi был создан в феврале 1995 года. Если вспомнить о предыдущих продуктах Borland, нужно отметить, что Turbo Pascal был весьма успешен - продукты с интегрированными средами разработки существенно повышали производительность труда программистов. Однако первая версия Turbo Pascal для Windows все же не решала самые существенные проблемы, с которыми сталкивались разработчики Windows-приложений, и нам довольно быстро стало ясно, что именно мы должны сделать для решения этих проблем. Создание Windows-приложений должно было начинаться с проектирования пользовательского интерфейса, и это явилось ключевой идеей нового продукта.
Когда мы выпустили Delphi, он стал первым средством быстрой разработки приложений, основанным на компилируемом языке программирования, тогда как существовавший в то время Visual Basic мог лишь создавать p-код и был, по существу, основан на интерпретаторе. Я могу сказать, что именно создание Delphi стимулировало появление компилятора в машинный код в последующих версиях Visual Basic.
КП: Следует ли ожидать более тесной интеграции .NET с серверами приложений сторонних производителей, кроме Web-сервисов, например прямого доступа к EJB, поддержки CORBA?
А.Х.: Поддержка прямого доступа к EJB означает добавление Java поверх имеющихся библиотек, что мне не представляется целесообразным. Я думаю, что стратегия, связанная с развитием технологии XML Web-сервисов, наиболее подходит для поддержки интеграции с такими серверами приложений. Отметим, что IBM, как и другие крупные игроки рынка программного обеспечения, относятся к указанной стратегии более чем серьезно и поддерживают ее. Именно поэтому я считаю, что интеграция на основе этой технологии - вполне реальное явление.
Лично я полагаю, что технологии, подобные CORBA, нeдостаточно масштабируемы. В масштабе локальной сети эти технологии решают многие проблемы, но, как только мы начинаем работать в масштабе континента, применение таких технологий может создать целый ряд проблем. Главная из них в том, что целью данных технологий является полная изоляция программиста от передачи данных. Не получая отклика от объектов, к которым вы обращаетесь, вы не знаете, что именно происходит при передаче данных, и потому должны что-то изменять в объектах, вызывать их снова и снова, чтобы разобраться в происходящем.
Даже ограниченная скорость света является проблемой, если масштаб приложений таков, что вы охватываете и Европу, и США. Именно по этой причине стоит вернуться к технологиям распределенных вычислений, основанных на сообщениях, таких как применение Web-сервисов. Надежная передача сообщений дает шанс обеспечить большую масштабируемость, поэтому мы так глубоко верим в Web-сервисы.
КП: Большое спасибо за подробные и содержательные ответы. Мы ждем от вас новых идей и, конечно, новых продуктов.
Редакция КомпьютерПресс благодарит сотрудников российского представительства Microsoft за организацию данного интервью.