Интервью со Страуструпом

Интервью со Страуструпом

Общие сведения

В этом интервью, Бьерн Страуструп, создатель C++, говорит об объектно-ориентированной революции, особенностях реальной разработки программного обеспечения, непрерывном развитиии C и C++, и некоторых добавлениях к стандарту C++, которые он хотел бы увидеть.

Бьерн Страуструп - создатель C++, одного из наиболее широко используемых языков, поддерживающего объектно-ориентированное программирование. Он также автор таких книг как "Язык программирования C++" [Страуструп] и "Дизайн и эволюция C++" [Страуструп2000]. Страуструп, в настоящее время возглавляет отдел программирования иследовательской лаборатории AT&T в штате Нью-Джерси. Его научные интересы включают распределенные системы, операционные системы, моделирование, проектирование программного обеспечения и программирование.

LinuxWorld.com: Объектно-ориентированные языки известны с конца 1960-ых. Однако, объектно-ориентированная революция произошла спустя два десятилетия. Как Вы объясняете эту задержку и какие выводы мы можем сделать из этого?

Бьерн Страуструп: Часть причин в том, что что изменения в сознании и поведении людей всегда занимают гораздо больше времени, мы думаем. Другая причина в том, что некоторые люди имели (и имеють) необоснованные ожидания относительно "революций". В корне неверной является идея, что имеется только один правильный способ, чтобы решить любую проблему для любого пользователя. Я - великий фанатик объектно-ориентированного программирования, а также методов и принципов проектирования (разработки), опирающихся на использование алгоритмического языка Симула 67. Однако, эта техника не являетсяэффективной. Многое в программировании лучше сделать методами, которые не помещаются внутри узкой полоски методов, именуемых "объектно-ориентированными". И если Вы не выходите за границу "объектно-ориентированных" методов, чтобы остаться в рамках "хорошего программирования и проектирования", Вы получаете нечто, что является в основном бессмысленным. См. мою статью, "Почему C++ не только объектно-ориентированный язык программирования".

Другая причина состоит в том, что люди, связывали с понятиями "Истинная объектная ориентированность" или "Чистая объектная ориентированность" такое, что вело к огромным непроизводительным затратам даже при решении простых задач, если сравнить полученный код с кодом на C++ и C.

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

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

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

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

Бьерн Страуструп: я не являюсь хорошим предсказателем будущего, так что я не буду этим заниматься, вместо этого скажу, что обычно будущее в большей степени, чем мы думаем, является вчерашним днем. Заметьте, что КОБОЛ, ФОРТРАН, и C - все еще большие языки. Обобщенное программирование - реальность (господствующая тенденция).

Вы можете также видеть, как изящно и эффективно в стандартной библиотеке шаблонов (STL) замствована техника функционального программирования, используемая при этом в контексте C++. Программирование на основе правил (см. ссылку на ресурсы по R ++) имеет в своем активе список неудач и успехов, который не ведет к выводу о возможном господствующем положении. Это, конечно, печально, но я не хочу называть данную парадигму "академическим пустяком". Многие из идей, которые мы сегодня видим в отдельных языках, проявятся как господствующие тенденции, средства и методы, при внедрении в господствующий язык, типа C++. Будущее увидит много мультипарадигм программирования и различные многоязычные системы.

LinuxWorld.com: С утверждением C99 (нового стандарта C), C / C ++ совместимость кажется менее достижимой чем когда-либо прежде. Является ли совместимость вниз с C все еще одна из целей C++? Если так, то что было сделано, чтобы отвернуть от пропасти, встающей между двумя языками?

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

Мой идеал: остающиеся все еще общими части C++ и C99 можно соединить в единый когерентный язык. Я думаю, что такой язык мог бы объединить общие рациональные технические требования. Однако, я не уверен, что политически это будет сделано. Для запуска процесса, требуется слияние комитетов стандартов по C и C++. Невозможно иметь две различных группы людей, развивающих два языка параллельно. Каждый комитет притягивает людей, кто не могут используют идеалы большинства из другой группы, и которые ненавидят возможностей компромисса с этим большинством. В то время как каждый отдельный комитет способствует объединению своего сообщества, оба комитета обеспечивают расходимость языков и игнорирование неудобных предложений и мнений. Лично, я думаю, что комитеты должны выработать соглашение, чтобы соединиться, а затем и слиться, но прежде, чем появится новый стандарт ISO C++. Результатом были бы более хороший язык и намного более сильное сообщество.

LinuxWorld.com: Есть ли элементы или концепции в других языках, например Python или Ada95, которые Вы хотели бы видеть добавленными к C++? Вообще, нуждается ли C++ в любых дополнительных элементах или библиотеках?

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

Рассмотрим "основные" средства языка, часто предлагаемые для внесения в C++:

• Параллелизм: я хотел бы видет библиотеку, поддерживающуюпотоки и связанную с ней библиотеку поддерживающую параллелизм без разделения памяти.
• Отражение: я хотел бы видеть поддержку через библиотеку определение интерфейса, расширяющего информацию о типе.
• Сохраняемость: я хотел бы видеть некоторую поддержку в стандартной библиотеке, возможностей по включению расширенной информации о типе, но я, в настоящее время, не имею каких-либо конкретные предложений.
• Хеш таблицы: Конечно, некоторый вариант популярного hash_map будет включен.
• Ограничения для аргументов шаблона: Это может быть просто и изящно выражено в C++ и сейчас.
• Обработчики (Assertions): Многие из наиболее полезных утверждений [способы проверки кода и обработки ошибок] могут быть выражены как шаблоны. Некоторые должны быть добавлен к стандартной библиотеке.
• Разбор регулярных выражений (Regular expression matching): я бы хотел видеть в стандарте библиотеку с образцами, обеспечивающими разбор.
• Сборка мусора: я бы хотел видеть, что стандарт C++ явно подтверждает, что это - допустимая методика реализации для C++, точно определяющая, что "потерянные указатели" могут игнорироваться и что случится при вызове деструкторов для собранного мусора. (См. секцию C 4.1 Языка программирования C++ для более детального ознакомления).
• Графический интерфейс пользователя (GUI): было бы хорошо иметь стандартный GUI-каркас, но я не вижу, как такое может быть политически возможно.
• Системные средсва, независимые от платформы (Platform-independent system facilities: я бы хотел видеть, что стандартна библиотека обеспечивает более широкий набор стандартных интерфейсов к общим системным ресурсам, например, каталогам и сокетам.

Заметьте, что эти расширения прежде всего являются дополнениями к стандартной библиотеке и могут быть реализованы без новых затрат во время выполнения программы или дополнительных требований к ресурсам. Таким образом, они могут быть добавлены без нарушения принципа "нулевого перекрытия". Между прочим, C++ - хороший язык для программирования аппаратного ядра встроенных систем и должен оставаться таковым. Также, все ресурсы должны быть правильно интегрированы с текущими стандартными библиотечными средствами, такими как строки и контейнеры.

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

LinuxWorld.com: кажется, что C++ потерпел неудачу на одном важном фронте: защите языка. Много людей все еще по ошибке полагают, что C++ по существу медленнее чем C, а среда часто отказывается подтверждать, что C++, наиболее широко используемый универсальный язык программирования, фокусируясь вместо этого на других широко раздутых языках. Где мы шли не так, как надо и что может быть сделано, чтобы зафиксировать все, как надо?

Бьерн Страуструп: C++ не нуждался в эффективной защите, с самого начального момента: его сразу стали использовать миллионы программистов. Удивительно то, что это было достигнуто без специальной организации и использования каких-либо дополнительных ресурсов. Это, возможно, сделало сообщество C++ умиротворенным, что, определенно, приволо к уязвимости со стороны враждебной пропаганды. Я предполагаю, что реальная задача в том, что хороший код является невидимым, даже его пользователям. Рассмотрите программы на C++ типа Netscape и Internet Explorer. Корпорации, которые производят программное обеспечение для решения задач в реальном масштабе времени: управление передачей данных, автоматическое управление, и моделирование, не рекламируют языки, которыми они пользуются. К сожалению, имиджмейкерами программ и инструментальных средств являются продавцы и академики.

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

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

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

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

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

Комитет стандартов должен делать его работу, обеспечивая стандартные версии доступными для критики, но нестандартными, библиотеками. Это может быть сделано, но сделать это будет не просто.

Ресурсы

• Домашняя страница Бьерна Страуструпа:
  http://www.research.att.com/~bs
• Биография Бьерна Страуструпа:
  http://www.research.att.com/~bs/bio.html
• Публикации Бьерна Страуструпа:
  http://www.research.att.com/~bs/papers.html
• The C++ Programming Language, Special Edition, Bjarne Stroustrup (Addison-Wesley, 2000):
  http://www.research.att.com/~bs/3rd.html
• Bjarne Stroustrup's FAQ:
  http://www.research.att.com/~bs/bs_faq.html
• Комитет по стандартизации C++:
  http://anubis.dkuug.dk/JTC1/SC22/WG21
• C++ Boost.org:
  http://www.boost.org/
• Standard Template Library от SGI:
  http://www.sgi.com/tech/stl/
• R++: Основанный на правилах язык программирования:
  http://www.research.att.com/sw/tools/r++/
• Новые достижения C99:
  http://web.onetelnet.ch/~twolf/tw/c/c9x_changes.html
• "Будущее согласно Деннису Ритчи". Danny Kalev (LinuxWorld.com, Dec 2000):
  http://www.linuxworld.com/linuxworld/lw-2000-12/lw-12-ritchie.html
• Комитет по стандартизации C:
  http://anubis.dkuug.dk/JTC1/SC22/WG14
• Организация языка программирования Python:
  http://www.python.org/
• "Будущее функционального программирования". Cameron Laird (LinuxWorld.com, November 2000) :
  http://www.linuxworld.com/linuxworld/lw-2000-11/lw-11-futurecomputing.html