Интервью с создателем С++ Бьёрном Страуструпом (Bjarne Stroustrup)

Вступление

Предлагаем вашему вниманию запись беседы с Бьёрном Страуструпом (Bjarne Stroustrup), который спроектировал и разработал C++. Он также написал ряд книг: «Язык программирования С++» (книга выдержала 4 издания), «Язык программирования С++. Краткий курс» (2 издания), «Программирование: Принципы и практика использования C++» (2 издания) и др. Кроме того, Бьёрн опубликовал больше ста научных статей.

Интервью

Evrone: Ты создал один из самых эффективных и быстрых языков программирования. Без сомнения, это изменило наш мир. Изменился ли ты сам, как личность, работая над ним?

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

Один из аспектов моей работы, которому я с годами уделяю всё больше внимания — это образование. Когда я пытался объяснить свои идеи, я понял, что недостаточно создать что-то, нужно научить людей хорошо использовать то, что создал. Это стало проблемой для C++. Часто мое послание заглушали люди с упрощенным видением и склонностью к громким заявлениям. Я постоянно слышал в 1980–90 годах жалобы вроде «Мы не можем достаточно быстро подготовить преподавателей», и язык C++ часто преподавали ужасно. Неудивительно, что у некоторых сложилось очень негативное представление о C++.

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

И здесь мне больше, чем техническое образование, помогло чтение на общие темы. Я осознал, что для хорошего языкового дизайна необходимо смириться с тем, что мы многого не понимаем, что мир постоянно меняется, наши проблемы и мы сами тоже меняемся.

Evrone: Бизнес-среда требует соблюдения жестких сроков при внедрении новых фич. Как разработчикам сохранить баланс между качеством кода и скоростью разработки?

Бьёрн: Это зависит от управленческой структуры и технической культуры. Моё личное мнение, которое сложилось в основном в Bell Labs  — идеальное решение заключается в том, чтобы нанять лучших людей. При этом их должно быть достаточно не только для текущих срочных задач, но и для планирования задач будущих, для ведения экспериментов и создания первой версии следующей важной системы, а может быть, и той, которая последует за ней. Хорошая организация создаёт постоянный поток продуктов, большинство из которых представляют собой эволюционное развитие уже существующих продуктов, требующих обслуживания и обновления. Очевидно, что это не соответствует распространенным представлениям о сокращении расходов и/или создании революционной системы в будущем году.

Evrone: Сейчас распространилось мнение, что использование современных фреймворков важнее, чем применение математических знаний. Что ты по этому поводу можешь посоветовать начинающим программистам?

Бьёрн: Время, затраченное на математику, почти никогда не пропадает даром. Математика — один из лучших способов тренировки мозга, особенно в сочетании с компьютерными вычислениями, поскольку с их помощью ошибки быстро становятся очевидными.

Математика учит быть точным и не верить в чрезмерно упрощенные или ложные идеи.
Есть области, где математика необходима, например, для научных расчётов, некоторых видов графики и большей части финансового программного обеспечения, но для большинства людей нужны такие разделы математики, как теория вероятности и статистика. Достаточно ли быстро работает ваш код? Будет ли он масштабироваться? Каковы вероятные события и их последствия?

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

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

Бьёрн: Каждую новую мощную фичу или технику обязательно будут использовать к месту и не к месту, часто неправильно. Я не вижу никакого способа избежать этого. Наш энтузиазм нас подстёгивает, но со временем мы должны научиться лучше использовать инструменты и немного сбавить обороты. Впрочем, есть и плюс: чрезмерное использование выявляет недостатки, и мы можем их устранить. Например, метапрограммирование с помощью шаблонов было настолько полезным, что многие разумные люди были готовы игнорировать его уродство и ужасные сообщения об ошибках. Затем мы узнали достаточно, чтобы компенсировать эти недостатки с помощью функций constexpr и consteval, которые вычисляются во время компиляции, и концептов. Они значительно упростили многое при написании кода.

Evrone: С появлением нейронной сети AlphaCode от DeepMind в прессе появляется всё больше заявлений о том, что такие нейронные сети скоро заменят программистов. Как думаешь, есть ли для этого реальные предпосылки?

Бьёрн: Точно не знаю, но сомневаюсь, что ИИ заменит программистов в том виде программирования, который меня больше всего волнует. Высокая степень надежности и близкая к оптимальной производительность не очень-то поддаются стандартизации и усреднению. Когда я слышу об ИИ (в котором не очень силён), я напоминаю себе, что TensorFlow и подобные библиотеки — это C++, а значит, я внес свою лепту, как хорошую, так и плохую.

Evrone: Иногда мы, разработчики, не можем найти правильное решение для поставленной задачи. Оказывался ли ты в такой ситуации? Можешь ли что-нибудь порекомендовать, чтобы справиться с этим?

Бьёрн: Конечно, оказывался! Те, кто пытается сделать что-то новое и значительное, рано или поздно сталкиваются с проблемой, с которой можно биться часами, днями, неделями с ощущением, что зашёл в тупик и всё пропало. Но не следует впадать в отчаяние.
Чтобы понять проблему, нужно постараться рассмотреть её логически. Измеряйте, если есть что измерить, чтобы получить обратную связь. Хорошо обдумайте то, что вы пытаетесь сделать: может быть, вы делаете не то, что нужно, или неверно сформулировали требования. Время от времени устраивайте перерыв и думайте о чём-то другом. Если есть возможность, я выхожу на пробежку. Часто полезные идеи приходят мне в голову именно тогда, когда я расслабляюсь.

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

Бьёрн: Это «Первый закон вычислений» Дэвида Уилера. Для меня ценно, что ты помнишь вторую половину — многие забывают о ней, а между тем в этом суть. Когда я писал диссертацию, Дэвид Уилер был моим научным руководителем. Он был замечательным человеком, и я многому у него научился.

Эта «шутка», возможно, сегодня более актуальна, чем тогда, когда Дэвид её придумал. Люди продолжают прятать реальную логику за несколькими слоями абстракции, включающих косвенные обращения. Это может повлечь увеличение размера и/или времени выполнения на один-два порядка. Многое в современном C++ существует для того, чтобы позволить людям иметь приличные интерфейсы, которые компилятор может свернуть в простой машинный код без лишних промежуточных операций.

Evrone: За последние десять лет в основных языках появилось много «синтаксического сахара». Что ты думаешь об этой тенденции раздувания синтаксиса ради того, чтобы несколько улучшить инструментарий для опытных разработчиков?

Бьёрн: До тех пор, пока «раздувание» синтаксиса упрощает жизнь программистов, его надо приветствовать. Я называю это «упрощением простых задач». По-моему, основная идея заключается в том, чтобы дать программисту возможность выражать фундаментальные идеи непосредственно в коде. Например, нет никакой пользы или выгоды в том, чтобы выразить простой цикл над контейнером как цикл в стиле С. Лучше использовать range-for или алгоритм из стандартной библиотеки шаблонов. В большинстве случаев они напрямую соответствуют замыслу. Кропотливую работу с переменными цикла оставьте для необычных случаев, например, для перебора каждого второго элемента контейнера. Более чёткое выражение идей легче написать, легче прочитать, легче поддерживать, и оно часто лучше поддается оптимизации в целях ускорения выполнения.

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

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

Бьёрн: Готовность слушать и серьёзно подходить к пониманию проблемы. Затем, требуется определенная степень смирения, когда собираешься дать совет, ведь часто наше понимание не является полным. При этом хороший наставник должен давать конкретные советы, а не выдавать общие расплывчатые фразы. Если кто-то обращается к вам с серьёзным вопросом, он заслуживает серьезного ответа, который поможет двигаться дальше. Давать советы трудно.

Хорошие вопросы многому учат. Они являются основным двигателем прогресса. Хороший наставник сам многому учится у студентов.

Evrone: Не мог бы ты рассказать о предстоящих изменениях в языке, которые, по твоему мнению, стоит добавить в будущие версии C++?

Бьёрн: Для начала, сообщество должно привыкнуть к новым, мощным и более простыми в использовании возможностям C++20. По числу улучшений стандарт C++20 сравним с C++11. Здесь я упомяну только две особенности языка (на самом деле их больше) и, конечно же, компоненты стандартной библиотеки.

• Модули. Наконец, мы можем написать import Mod, чтобы получить доступ к интерфейсам, экспортируемым с помощью module Mod, больше ничего не требуется. Это обеспечивает гораздо лучшую гигиену кода, чем подключение хедеров с помощью #include, которые раскрывают детали реализации и макросы. Модули к тому же значительно быстрее компилируются. Например, я скомпилировал простое использование import std в десять раз быстрее, чем #import<iostream>, хотя std содержит всю стандартную библиотеку, а <iostream> - менее 10% из неё. Модуль std пока является экспериментальным, но за его включение в C++23 уже проголосовали.
• Концепты. До появления C++20 все шаблоны были неограниченными; то есть они не указывали интерфейс, на который могли бы смотреть люди и инструменты, чтобы определить требования шаблона к его аргументам. Например, template<typename Iter> для шаблона, которому нужен тип «итератор». Теперь мы можем определять такие требования, называемые concepts, и использовать их: template <random_access_iterator Iter>. Такие ограниченные аргументы шаблонов всегда были идеалом, к которому надо стремиться. Я просто не знал, как реализовать эту идею, не ограничивая гибкость и не повышая потребления ресурсов во время выполнения. Теперь мы можем немедленно проверять использование шаблонов, получать гораздо более качественные сообщения об ошибках, перегружать шаблоны функций, а местами даже повысить производительность.

В Интернете вы можете найти гораздо более подробную информацию; например, поищите сопрограммы (coroutines), ranges, calendars, time zones, formatting, тип span, а также compiler-time vector и string. Фичи C++20 поставляются в основных компиляторах.

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

• Статическая рефлексия: нам нужен механизм для генерации кода во время компиляции на основе типов в программе. Это даст нам почти всю гибкость рефлексии во время выполнения, без затрат времени и пространства. Например, должно быть очень просто сгенерировать оптимизированный JSON-ридер для фиксированного набора типов. Над этим была проделана значительная работа.
• Сопоставление с образцом: возможность выбора действия на основе соответствия выражения какому-либо образцу (например, тип или значение) является одним из самых удобных способов выражения альтернативных действий во многих функциональных языках программирования. Мы можем сделать то же самое для C++, и в процессе архаичный оператор switch станет излишним. У нас почти закончен проект с экспериментальной реализацией, поэтому я надеюсь, что в C++26 эта фича появится.
• Модель параллелизма: Мы уже много лет работаем над общей моделью параллелизма, но постоянно находим сценарии использования, для которых она не работает, поэтому приходится откладывать решение этого вопроса до стандарта C++26.

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

Заключение

Нам было очень интересно поговорить с Бьёрном и кое-что узнать о его огромном опыте.

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