|
|
C/C++ Visual C++ >Статьи
Интервью со Страуструпом
Общие сведения
В этом интервью, Бьерн Страуструп, создатель
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++ как нового языка" в Ресурсах.
Комитет стандартов должен делать его работу,
обеспечивая стандартные версии доступными для критики, но
нестандартными, библиотеками. Это может быть сделано, но сделать это
будет не просто.
Ресурсы
|