Будущее по Бьерну Страуструпу

Бьерн Страуструп — создатель Си++, одного из наиболее широко используемых языков объектно-ориентированного программирования, а также автор книг «Язык программирования Си++» (русские переводы: M.: Радио и связь, 1991; М.: Финансы и статистика, 1992; М.: Бином, 1999) и «Дизайн и эволюция Си++» (русский перевод: М.: ДМК Пресс, 2000). Сейчас он возглавляет отделение AT&T Labs по исследованиям в области корпоративного программирования, находящееся в шт. Нью-Джерси. Научные интересы Страуструпа включают распределенные системы, операционные системы, имитационное моделирование, методы проектирования и программирования.

Linux World Объектно-ориентированные языки появились в конце 1960-х годов. Однако «объектно-ориентированная революция» разразилась двумя десятилетиями позже. Как вы объясняете такую задержку и какие выводы можно отсюда сделать?

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

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

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

Кроме того, многие люди, в том числе программисты, преподаватели и руководители, просто не хотят считаться с фактическими трудностями разработки ПО. Они мечтают о «серебряных пулях»* и отвергают эффективные идеи, поскольку те не во всем совершенны и слишком нетривиальны для новичков. В результате реальные проекты выполняются с использованием неоправданно устаревших языков, инструментов и методов, а дефицитные ресурсы расходуются на все новые и новые причуды. Подобная недооценка проблем разработки ведет и к тому, что все «пули» оказываются слишком примитивными, чтобы справиться с трудностями практической разработки. А как только новшество удается адаптировать к жизни, оно становится уязвимым для обвинений в сложности — справедливых и нет — со стороны последователей очередной «серебряной пули».

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

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

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

Linux World С принятием нового стандарта Си-99 (C99) совместимость Си и Си++, похоже, стала еще более шаткой. Сохраняется ли задача обеспечить в Си++ совместимость с Си «сверху вниз», и если да, то что следует сделать для уменьшения зияющего разрыва между двумя языками?

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

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

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

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

Скажу о «значительных» средствах языка, о добавлении которых в Си++ часто спорят:

• Параллелизм (concurrency): мне хотелось бы, чтобы в стандарт были включены библиотеки для поддержки параллельных потоков и параллельного выполнения без совместно используемой памяти.
• Рефлексия (reflection): я был бы рад увидеть нечто в этом роде, поддерживаемое с помощью библиотеки, которая будет определять интерфейс для расширенной информации типа.
• Устойчивость (persistence): хорошо бы включить определенную поддержку для нее в стандартную библиотеку, возможно, в соединении с расширенной информацией типа, но конкретных предложений у меня пока нет.
• Хэш-таблицы (hash tables): разумеется, некоторый вариант популярной библиотеки hash_map должен быть включен.
• Ограничения для аргументов шаблонов (constraints for template arguments): они могут быть просто и элегантно выражены в Си++ уже сейчас.
• Контрольные вставки (assertions — средство верификации кода и обработки ошибок): многие вставки из числа самых полезных можно выразить через шаблоны. Некоторые такие вставки следует добавить в стандартную библиотеку.
• Сопоставление на основе регулярных выражений (regular expression matching): хотелось бы увидеть в стандарте библиотеку сравнения по образцу.
• Сборка мусора (garbage collection): меня порадовало бы, если бы в стандарте Си++ открыто признавался этот метод реализации, указывалось, что «скрытые указатели» можно игнорировать, и объяснялось, что происходит с деструкторами для сборки мусора (подробнее см. раздел C.4.1 книги «Язык программирования Си++»).
• Графический интерфейс (GUI): было бы прекрасно иметь стандартную основу для него, но мне неясно, каким образом это могло бы оказаться приемлемым с политической точки зрения.
• Системные средства, не зависящие от платформы (platform-independent system facilities): мне хотелось бы, чтобы стандартная библиотека обеспечивала более широкий диапазон интерфейсов к обычным системным ресурсам (там, где это возможно) — каталогам, сокетам и т. д.

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

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

Linux World Похоже, Си++ потерпел неудачу на одном очень важном направлении — в пропаганде языка. Многие до сих пор ошибочно считают Си++ «по природе» более медленным, чем Си, а СМИ часто отказываются признавать, что Си++ — самый распространенный универсальный язык программирования, и вместо того сосредотачивают внимание на других чрезмерно разрекламированных языках. Где был сделан неверный шаг и как можно исправить эту ошибку?

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

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

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

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

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

Необходимо улучшить преподавание Си++, построив курс вокруг стандартной библиотеки и возможностей абстрагирования. Изучение Си++ как набора «продвинутых» или сложных расширений Си — непроизводительная трата времени и запутывание учащихся (см. статью «Learning Standard C++ as a New Language»).

Комитет по стандартизации, со своей стороны, должен представить стандартные версии жизненно важных, но нестандартных библиотек. Это можно сделать, но работа будет очень и очень непростой.

Об авторе

Дэнни Калев — системный аналитик и программист с 12-летним стажем работы, специализируется в Си++, объектно-ориентированном анализе и проектировании для различных платформ, включая Linux. Ведет раздел о программировании для Linux в форуме Linux Forum на сервере ITworld.com, а также еженедельник Linux Tips and Tricks.

назад

Ссылки