Cоздатель Си++, одного из наиболее популярных языков программирования, делится взглядами на дальнейшие пути развития своего «детища»

Бьорн Страуструп: «Всякий язык программирования общего назначения обязан поддерживать сразу множество парадигм, и каждая парадигма должна быть реализована хорошо»

Бьорн Страуструп — создатель Си++, одного из наиболее популярных языков, соответствующих концепции объектно-ориентированного программирования, автор книг The C++ Programming Language («Язык программирования Си++») и The Design and Evolution of C++ («Архитектура и эволюция Си++»). В настоящее время Страуструп возглавляет отдел программных исследований в лаборатории AT&T Labs. Область его научных интересов охватывает технологии распределенных систем, операционных систем, сферу имитационного моделирования, проектирования и программирования. Со Бьорном Страуструпом встретился корреспондент электронного журнала LinuxWorld Дэнни Калев.

Первые объектно-ориентированные языки появились еще в конце 60-х. Однако революция объектно-ориентированного программирования началась лишь два десятилетия спустя. Чем вы объясняете такую задержку?

Одна из причин заключается в том, что на изменение привычек и поведения людей всегда уходит гораздо больше времени, чем хотелось бы. Другая — это ожидание «революции» при отсутствии достаточных на то оснований. Мысль о существовании единственно правильного способа решения фактически любой задачи в корне неверна. Лично я горячий поклонник идеи объектно-ориентированного программирования, ее архитектурных концепций и поддерживающих ее технологий, ведущих свое происхождение от языка Simula 67. Однако это не просто эффективная технология. Хорошие программы можно создать и при помощи средств, которые не относятся к категории объектно-ориентированных. С другой стороны, если же постоянно расширять объектные механизмы с единственной целью, чтобы люди, занимающиеся проектированием и программированием, не испытывали никаких ограничений, мы в конце концов получим результат, лишенный всякого смысла. Все эти моменты я постарался отразить в книге Why C++ isn?t just an Object-Oriented Programming Language («Почему Си++ — не просто язык объектно-ориентированного программирования»).

Еще одна причина состоит в том, что люди считают «истинно объектно-ориентированными» или «чисто объектно-ориентированными» в основном те языки и системы программирования, которые по сравнению с кодом на Си и Си++ влекут за собой огромные накладные расходы при решении простейших задач.

Вывод, к которому я пришел (году приблизительно в 1980-м или около того), можно сформулировать так: всякий язык программирования общего назначения обязан поддерживать сразу множество парадигм, и каждая парадигма должна быть реализована хорошо, обеспечивая близкое к оптимальному время выполнения и распределение памяти. И я понял, что распространение новых идей сдерживается в основном консерватизмом, сопровождаемым мифами о сложности и высоких накладных расходах.

Наконец, многие (в том числе программисты, преподаватели и руководители) просто не хотят связываться со сложностями разработки программного обеспечения. Они мечтают о простых и понятных «серебряных пулях» и отвергают эффективные идеи, поскольку идеи эти не вполне совершенны и непривычны для новичков. А потому на практике большая часть работ выполняется с использованием устаревших языков, инструментальных средств и технологий, тогда как по-настоящему редкие и полезные ресурсы растрачиваются на реализацию экзотических проектов. Из-за недооценки этих важных моментов каждая новая «серебряная пуля» на поверку оказывается чересчур упрощенной. Все это приводит к тому, что отрасль разработки программного обеспечения оказывается не в состоянии выйти из оцепенения. А когда появляется что-то принципиально иное, приспособленное к решению реальных задач, оно тут же попадает под огонь критики (как справедливой, так и нет) и обвинений в чрезмерной сложности, исходящих от сторонников очередной «серебряной пули».

Но вернемся к технической стороне: я полагаю, что любой язык, претендующий на широкое распространение, должен обладать необходимой базой для поддержки самых разнообразных технологий, включая объектно-ориентированное (иерархия классов) и обычное (параметрические типы и алгоритмы) программирование. Особенно хотелось бы отметить важность компоновки программ из отдельных блоков (возможно, даже написанных на разных языках). Я думаю также, что исключения совершенно необходимы для управления сложным механизмом обработки ошибок. Язык, в котором отсутствуют подобные средства, заставляет разработчиков потратить массу сил на то, чтобы их имитировать.

Какие тенденции складываются в перспективных технологиях программирования? Какая роль будет отводиться функциональному программированию, программированию на базе правил, другим парадигмам в программном мире завтрашнего дня? Займут ли какие-то из этих направлений главенствующее положение или же область их применения ограничится академическими задачами?

Вряд ли из меня получится хороший предсказатель будущего, поэтому, на мой взгляд, не стоит и заниматься этим. Единственное, что следует отметить: все новое гораздо чаще, чем нам хотелось бы, напоминает хорошо забытое старое. Заметьте, Кобол, Фортран и Си по-прежнему остаются ведущими языками. Разработчики библиотеки Standard Template Library (STL) позаимствовали идеи у сообщества функционального программирования, но как элегантно и эффективно они реализовали их в контексте Си++. В истории программирования на базе правил были как успехи, так и провалы, но занять лидирующие позиции ему так и не удалось. Жаль, и все же я не хотел бы называть эти течения «академическими изысками». Многие из идей, реализованных сегодня в малораспространенных языках, впоследствии появляются в виде дополнительных функций и технологий расширения в языках, на которых пишет весь мир (например, в Си++). В будущем мы придем к программированию, воплощающему в себе множество парадигм, и к системам, написанным на нескольких различных языках.

После утверждения нового стандарта C99 понятие совместимости со спецификациями представляется еще менее четким, чем ранее. Является ли обратная совместимость со спецификациями Си одним из необходимых условий дальнейшего совершенствования Си++? Если да, то что нужно сделать для того, чтобы минимизировать растущий разрыв между двумя этими языками?

Язык C99 нацелен на расширение низкоуровневых функций Си в области численного программирования. Он игнорирует концепцию абстрагирования и ориентацию на решение задач общего назначения, характерную для Си++. Это обеспечивает более тесную совместимость с Си и интеграцию элементов специального назначения там, где Си++ использует встроенные библиотеки, включающие в себя конструкции языка общего назначения. В качестве примера можно привести массивы переменной длины C99, реализованные в Си++ в виде векторов. Координированное развитие двух языков помогло бы избежать подобных расхождений.

Идеальным вариантом мне по-прежнему представляется единый язык, в котором рационально сочетались бы конструкции Си++ и C99. Думаю, такой язык смог бы удовлетворить любым разумным техническим потребностям. Однако я не уверен, что у заинтересованных сторон окажется достаточно воли для принятия столь ответственного решения. Для начала это потребует объединения комитетов по стандартизации Си и Си++; ведь поддерживать параллельное развитие двух языков силами различных групп людей невозможно. Большинство представителей одного комитета не разделяет идеи другого и не желает искать компромисса. В то время как внутри каждого из комитетов царят взаимопонимание, доверие и готовность идти на уступки, сосуществование сразу двух органов приводит к обострению разногласий и жесткому противодействию неудобным взглядам и мнениям. Я полагаю, что комитетам следует совместными усилиями разработать соглашение об объединении, а затем выбрать удобное время, чтобы претворить это в жизнь до момента обновления комитета ISO по стандартизации Си++. Таким образом, мы получим более качественный язык и более сплоченное сообщество.

Хотите ли вы увидеть в Си++ отражение каких-либо функций или концепций других развивающихся языков, скажем, Python или Ada95? Нужны ли вообще Си++ какие-то дополнительные возможности или библиотеки?

Хотелось бы посмотреть на очередную версию стандарта языка Си++ и в особенности на его библиотеки. Работу над самим языком можно было бы свести к устранению ошибок, к тому, чтобы сделать язык более однородным, обеспечить поддержку популярных парадигм при помощи минимальных расширений, создать условия, необходимые для эффективного использования библиотек. К примеру, на мой взгляд, режим параллельного выполнения операций лучше поддерживать библиотечными функциями. Создать такую библиотеку можно без внесения принципиальных изменений в базовые конструкции языка. Но в то же время подобная библиотека должна обладать дополнительными стандартными средствами поддержки. Кроме того, мне бы все-таки хотелось объединения Си и Си++.

Заметьте, все эти расширения по большей части представляют собой дополнения Standard Library, и их реализация не окажет никакого воздействия на скорость выполнения программ и объем занимаемой ими памяти. Таким образом, мы не нарушаем принципа «нулевых накладных расходов». Помимо этого язык Си++ был и остается отличным средством программирования встроенных систем. Все дополнительные расширения необходимо интегрировать с элементами, поддерживаемыми Standard Library сегодня (в частности, с цепочками символов и контейнерами).

Я полагаю, что все перечисленные пункты (если не считать тех, которые связаны с графическим интерфейсом пользователя) без каких-либо противоречий можно реализовать к 2005 году, просто пересмотрев стандарт Си++. Конечно, такие планы весьма амбициозны, но отсутствие амбиций всегда оборачивается застоем. Надеюсь, что сообщество сторонников программ с открытым кодом возьмет на себя инициативу, поскольку ни одна из библиотек не будет утверждена в качестве стандарта до тех пор, пока не появится ее качественная реализация.

Создается впечатление, что Си++ проигрывает в одном очень важном компоненте: у этого языка нет сильных защитников. Многие по-прежнему считают, что Си++ гораздо медленнее Си, а специализированные издания зачастую не желают признавать его самым популярным языком программирования общего назначения, отдавая пальму первенства другим, более разрекламированным технологиям. В чем ошибка сторонников Си++, и что нужно сделать, чтобы исправить положение?

Си++ приобрел массу приверженцев там, где это было нужнее всего: миллионы программистов используют его в качестве своего основного инструмента. Удивительно, но этого удалось добиться, не имея «административного ресурса» и по существу без финансовых затрат. Однако, с другой стороны, сообщество сторонников Си++ оказалось разобщенным и крайне уязвимым для выпадов враждебной пропаганды. Мне кажется, все дело здесь в том, что хороший код часто остается незамеченным — даже его пользователями. Посмотрите на программы, написанные на Си++, например, на приложения Netscape или на Internet Explorer. Компании, разрабатывающие программы для решения реальных задач — в частности, для управления телекоммуникациями, контроля за различными механизмами и имитационного моделирования, — предпочитают не говорить, на каком языке написаны их приложения. К сожалению, это развязывает руки тем, кто пропагандирует альтернативные средства, а также любителям теоретических рассуждений.

Язык Си++ никогда не поддерживался каким-то одним лидером отрасли. Каждый крупный производитель дополняет (и так было всегда) стандарт Си++ своими собственными элементами. Си++ никогда не являлся предметом маркетинговой стратегии. Если какие-то маркетинговые мероприятия и проводились, то только организациями, продающими что-то другое (например, среду для разработки программного обеспечения), включающее в себя Си++ в качестве составляющего компонента. Сообщество Си++ скорее страдало от чрезмерной популярности этого языка: он постоянно становился «объектом нападок», ведь в современном мире, живущем по законам коммерции, честная борьба — большая редкость.

У сообщества Си++ никогда не было координирующего центра, финансовые возможности которого позволяли бы ему заниматься популяризацией языка. Кто и из каких соображений готов голосовать за Си++? И как довести эту информацию до программистов, преподавателей, менеджеров? Буквально на днях я слушал выступление профессора перед студентами, в котором он категорически отрицал существование стандарта Си++! Жаль, что даже спустя два года после ратификации этого стандарта сплошь и рядом возникают подобные недоразумения.

Итак, что же сообщество Си++ может сделать сейчас? Распространять информацию о достигнутых успехах и удачных технологиях. Возможными решениями здесь могли бы стать статьи и конференции, однако большая часть вечно занятых программистов скорее предпочла бы простое описание, размещенное на Web-сайте. Публикация качественных текстов программ в Web — наиболее эффективный способ продемонстрировать, что же в действительности представляет собой Си++ (хорошими примерами являются сайты SGI STL и Boost.org). Так или иначе, нам необходимо создать популярный портал, посвященный информации о Си++.

Коммерческие организации могли бы рассказывать об успехах своих клиентов, использующих C++, особенно если учесть, что публикуемые ими сведения, как правило, ограничиваются описанием индивидуальных особенностей программных продуктов. Наличие множества разработок, каждая из которых поддерживает стандарт Си++, — хороший аргумент для того, чтобы программисты остановили свой выбор на Си++.

Язык Си++ требует серьезного изучения. Центральное место здесь должно отводиться Standard Library и абстрактным конструкциям. Изучение Си++ как набора хитроумных расширений Си — пустая трата времени, которая не принесет желаемых результатов.

Комитет по стандартизации, со своей стороны, должен следить за соответствием имеющихся на рынке нестандартных библиотек утвержденным спецификациям. Добиться этого хотя и непросто, но вполне возможно.


Что дальше?

Вот что говорит Бьорн об «основных» особенностях Cи++, чаще всего становящихся предметом обсуждения разработчиков.

  • Параллелизм: я сторонник библиотечной реализации потоков и параллельного выполнения операций без разделения памяти.
  • Отображение типов: неплохо было бы обеспечить библиотечную организацию интерфейса с информацией расширенных типов.
  • Типизация: хотелось бы, чтобы в библиотеку Standard Library были включены функции поддержки расширенных типов, однако конкретных предложений у меня нет.
  • Хеш-таблицы: конечно, необходимо интегрировать некоторые варианты популярной схемы hash_map.
  • Ограничения для аргументов-шаблонов: все это просто, универсально и элегантно реализуется в рамках существующего стандарта Си++.
  • Операторы контроля: многие из наиболее важных операторов контроля — верификация кода и обработка ошибок — можно было бы реализовать в виде шаблонов. Некоторые из них следует включить в библиотеку Standard Library.
  • Сопоставление с регулярными выражениями: хотелось бы видеть в стандартном варианте языка библиотеку определения соответствия шаблонам.
  • Сборка мусора: в стандарте Си++ нужно явно определить технологию, позволяющую игнорировать «скрытые указатели», а также конкретизировать порядок обработки деструкторов.
  • Графический интерфейс пользователя: хорошо было бы иметь стандартные конструкции GUI, но не знаю, насколько это реально в сложившейся ситуации.
  • Независимость от платформы: хотелось бы, чтобы Standard Library поддерживала более широкий набор интерфейсов с общими системными ресурсами, например, с каталогами и сокетами.

Поделитесь материалом с коллегами и друзьями