Мне бы хотелось объединения Си и Си++

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что дальше?