[ Комментарий к переводу ]
Денни Калев (Danny Kalev)
Англоязычный оригинал интервью опубликован на сервере
linuxworld.com
21.02.2001
Перевод А.И. Легалова 18.03.2001
Общие сведения
В этом интервью, Бьерн
Страуструп, создатель 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++ как нового языка"
в Ресурсах.
Комитет стандартов должен делать
его работу, обеспечивая
стандартные версии доступными для
критики, но нестандартными,
библиотеками. Это может быть
сделано, но сделать это будет не
просто.
Об авторе
Дэнни Калев, системный аналитик и
программный инженер с 12 летним
опытом, специализируются в C++,
объектно-ориентированном анализе и
проектировании на различных
платформах, включая Linux.
Ресурсы
[ Комментарий к переводу ]
|