Pull to refresh
Как мы делаем Яндекс

Настоящее и будущее C++. Интервью с Эриком Ниблером

Яндекс corporate blog Website development *Programming *C++ *Industrial Programming *
Эрик Ниблер — известный эксперт по C++, один из важных контрибьюторов Boost, человек, который добавил в стандарт библиотеку Ranges.

26 августа в рамках C++ Party Эрик выступит в новосибирском офисе Яндекса, где как раз расскажет о библиотеке и поговорит с гостями о новых стандартах C++.


Я заранее поговорил с Эриком и задал ему несколько вопросов от себя и коллег о том, каким он видит настоящее и будущее C++, что ему кажется самым важным в программировании, будет ли в C++ когда-нибудь нормальный менеджер пакетов, модули, что будет со стандартной библиотекой и о многом другом.

Кстати, если у вас есть ещё хорошие вопросы к Эрику, — их можно задать в комментариях, и мы попросим его на них ответить.

Оригинал для тех, кто предпочитает читать по-английски (увы, по-русски Эрик пока не говорит)
How did you start to code on C++? Do you write code by yourself (boost and stl not counted) or just consult?

I learned C++ as an undergraduate student at the University of Virginia. It was actually required back then.Writing code is like breathing or eating for me. If I didn't do it daily, I would die. Find me on github to see what I'm working on this week.

What would you most likely advise to be changed in the language? Were there any wrong decisions in the C++ history? What would you change in the language if you could?

I don't have many complaints about the language, but there is a major shortcoming in the Standard Library that I would like to see changed: it's way too small. C++ is a great language for building libraries. We just need more.

What should be improved in C++ first?

There's really so much: compile times, better support for Generic Programming, reflection, ranges, Unicode support, etc, etc. But if I had to pick the one things that would transform the C++ world the most, I would say an easy-to-use, robust, powerful, and flexible package
manager. Finding, downloading, compiling, and installing libraries — with all their dependencies at the correct versions — is just way too hard today.

What do you think about C++ Standards Committee? Does it do a good job? Or is it too slow or conservative in some respect?

As a long-time member of the Committee, I probably have a different perspective on this than most. Design-by-committee happens. Catering to the experts happens. Solving small, isolated problems while ignoring larger systemic issues happens. But on the whole, I think the committee does a good job for what it is: a group of volunteers. And the «release cadence» has picked up dramatically since C++11. It's a full-time job to keep up with it all. It's exciting to be a part of it.

Do you think that if there were one person or someone esle who would be making all of the decisions — like W3C — it would be better, or is the Committee a good compromise?

Better in some ways, worse in others. I've occasionally wondered if C++ would be better with a BDFL like Python has in Guido. When the committee has to choose between two incompatible designs for a feature, it sometimes chooses both and adds a third option. That's bad. The alternative is to trust one person to have the good judgement to pick the «right» solution. But nobody chooses right every time. Distributing the decision making adds a crucial sanity check before ideas get baked into an International Standard. I know my work is vastly better for having to run them through the committee gauntlet. It's grueling, but C++ as a whole is better for it, IMO.

Is there any chance that some day a version of C++ with little or no backward compatibility will be released?

I don't see that happening ever, no. In the library perhaps, but not in the language.

What is your favourite code language after C++?
For simple scripting stuff, I reach for Python. Every now and then I poke at Haskell a bit. I like the rigor and math-y-ness. It's fun to puzzle out how things work in that language, but I'm not proficient enough to be productive yet.

Do you always understand multi-page errors that you get when using Boost?
Not right away, no.

Does it worries you that using Boost makes compiling manyfold slower for some projects?

Absolutely. I can haz modules? :-)

Do you use exceptions in your C++ code?
I write exception-neutral code (exceptions can pass through harmlessly), but I don't often write code that throws exceptions. In my way of thinking, exceptions are only for runtime failures: when the state of the world disagrees with the state of a program. As a library developer, I don't often interact directly with the outside world. (It's messy out there.) I am primary concerned with the internal consistency of programs. E.g., has this API been called incorrectly? For those sorts of errors (so-called logic errors), I use assertions.

When you look at your code after time do you like it or want to rewrite?
I usually like it and I want to rewrite it. Library redesign is the most important part of library design.

If you had to name one or two changes in the C++11/14 Standard that are the most important, which ones would you choose?

Again, my perspective is skewed here by my role as a library developer. I feel that decltype was the most sorely needed feature before C++11. When I look back on all the ugly hacks in Boost to work around the lack of decltype, I am deeply grateful that we don't have to live like that

The same question, but about the most controversial changes. Is there something that can have a negative effect?
Certainly: rvalue references. They're powerful, but they're just too hard to use correctly, and too easy to use incorrectly. My style has evolved such that I use them very sparingly and only in ways that I can feel confident about.

Noexcept gets honorable mention here. Not even the Committee can agree on how and where to use it.

How to deal with the complexity of the language?
Program in the «modern» subset. It's possible to write clean, simple, beautiful C++ code these days.

As for evolving a complex language like C++: Make changes that increase uniformity (see: uniform initialization) and give people simpler, safer ways to do complicated, error-prone things (see: auto, range-for, smart pointers). Deprecate the bad stuff (see: throw specifiers, auto_ptr). Write tools that help people program in the modern subset (see: clang modernize).

C++ is sometimes criticised for being a very discrete and abstract, almost Spartan, Standard Library. It doesn’t have a variety that other modern languages have. Do you think this is the right approach?

Absolutely not! The criticism is fair: the Standard Library needs to be greatly expanded. I want: Unicode support, databases, date/time support, serialization, networking (with support for lots of different protocols), parsing, etc., etc. The list is endless.

Creators of the original standard library think that it should be small and atomic, and everything else should be in a different library, not in the language itself. Do you think that this should be the case?

Who says this? I have never heard this view espoused in the Committee. Folks there are eager to expand the Standard Library.

Many people are asking for some standard repository like in some other languages. What do you think about this? Is there a need for it and how soon the C++ community can make it possible?

YES. Together with tooling, it's the biggest obstacle to adoption C++ has today, IMO. Some clever folks have tried to solve this problem, with limited success to date. It would take Microsoft or a Google (or a Yandex?) to really fix this, I think. It's the kind of hard, boring,
inglorious work that tends not to get picked up by volunteers.

Many people may think that C++ is terrible, actually, but they’re still using it, and it’s the main language used in their development. How do you think the decision should be made about what language to use in a large projects?

C++ is a very good language for large-scale projects, and projects where performance and footprint matter. I wouldn't pick C++ for a simple scripting task. It's all about picking the right tool for the job.

Do you think that it’s bad for C++ that it’s rarely used on mobile devices? All these new things use managed languages. Java for Android, Objective C and Swift for iOS. What do you think about that and couldn’t C++ be used more efficiently for these applications.

I'm dumbfounded that C++ isn't used more heavily on mobile. These are resource-constrained devices. Why pay for a VM?

These days, I'm hearing a bit more about teams writing the bulk of their mobile application logic in C++ for the sake of portability. The prospect of maintaining parallel codebases in different languages is just too awful to consider. It's a «well duh» that's been a long time

What do you think about Rust?

I've heard some positive buzz, but I haven't looked into it.

What is your favorite C++ IDE?

Visual Studio, hands down. I haven't tried CLion yet, but Eclipse was too awful for words the last time I tried it (which admittedly was a long time ago). Emacs/vim/gdb feels like banging rocks together when the rest of the world is at cruising speed. (Cue the angry trolls telling me what a Luddite I am for disparaging Emacs/vim/whatever.)

How did you convince the Committee that the Ranges library is important?

I got the job by volunteering to do the work, I think. The Committee was ready to say yes to just about any coherent Ranges proposal. There was an almost audible sigh of relief when I first presented my work.

Some developers think that C++ include too much poorly compatible features, that language is exaggerated. Do you share their opinion? If you were creating a language from scratch which existing features you would not have included? Is there a chance that some parts of modern C++ in the future will be declared obsolete and deprecated?

Parts of C++ have already been declared deprecated (throw specifiers) and some have actually been removed (export templates and auto as a storage specifier). I won't argue that C++ has warts. It does. Some are from it's C legacy, like the declaration syntax. Some are from standardizing features we didn't have enough experience with (allocators), and some are just bloated and poorly designed (iostreams, locales, string). I've never seen a compelling use case for virtual inheritance (OK, I use it in my own code for simulating Concepts, but I look forward to a time when it's not needed). I think inheritance is grossly overused. I would de-emphasize that feature and provide a clean, simple way to achieve dynamic polymorphism with value semantics (see: Sean Parent, «Inheritance is the Base Class of Evil»).

I would love to see the preprocessor go away. Other languages have awesome tooling support that is hard or impossible in C++ because of the preprocessor. In it's place, I would prefer an AST-based, hygenic macro processor. Let me manipulate my program's AST at compile time. I'll never need to do token pasting ever again.

What is more important for you: aesthetics (to make language or ibrary more beautiful, elegant) or practice (to make it more useful for daily tasks)? If the answer is practice, what daily tasks come into your mind first of all?

Aesthetics are important, but if I thought that was the most important thing, I'd program in Haskell. That said, I think «aethetics vs. practicality» is a false dichotomy. It's possible to have both, and I think the modern style of C++ is quite close.

The daily tasks that matter to me are the ones that come up again and again in every program of every scale in every domain: writing and calling ALGORITHMS and reasoning about their complexity, efficiency, and correctness. This is what programming is about. Making C++ better in this regard is what gets me out of bed. It has to be efficient, and it has to solve real-world problems. But it also has to be elegant. Elegant code is easy to write, easy to read, easy to use correctly, and hard to use incorrectly. Elegant code is a joy to use. If I can make the day-to-day lives of C++ programmers more fun, then I've done my job.

Расскажите, как вы начали программировать на C++? Вы ещё пишете код сами (boost и stl не считается) или только консультируете?

Я выучил C++ студентом, когда учился в Университете Вирджинии. Он был обязательным предметом. Для меня писать код — это как дышать или есть. Если я не буду этим заниматься каждый день, умру. Можете посмотреть на моём гитхабе, чем я занимаюсь на этой неделе.

Если бы вы создавали C++ с нуля, что бы вы сделали по-другому?

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

В каких направлениях в первую очередь стоит улучшать C++?

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

На ваш взгляд, Комитет по стандартизации достаточно эффективно выполняет свою работу?

Поскольку я давний член Комитета, моя точка зрения на этот вопрос, вероятно, отличается от обычной. Иногда бывает «разработка коммитетом», когда у семи нянек дитя без глаза. Иногда узкие проблемы решают без системного подхода. Но в целом мне кажется, что Комитет свою работу делает хорошо, особенно для своего формата, а это формат группы волонтёров. И ритмичность релизов значительно улучшилась, особенно после C++11. Просто оставаться в курсе всего происходящего — работа с полной занятостью. Я рад быть частью этого.

Возможно, было бы лучше, если бы был один человек, который отвечает за ключевые решения?

С одной стороны, лучше, но с другой — хуже. Я иногда раздумывал, не было бы лучше, если бы у C++ был свой просвещённый диктатор, как Гвидо у Python. В случаях, когда комитету нужно выбрать между двумя несовместимыми видами какой-то фичи, иногда он выбирает оба и ещё добавляет третью опцию. Это плохо. Альтернатива — довериться одному человеку, чтобы он всегда делал «правильный» выбор. Но никто не выбирает правильно в ста процентах случаев. Разделение такого решения на нескольких человек значительно уменьшает вероятность пропустить что-то плохое через Комитет. Я уверен, что моя работа становится лучше от того, что приходится проходить пекло Комитета. Это изматывающе, но C++ от этого на мой взгляд выигрывает.

Как вам удалось убедить комитет в необходимости библиотеки Ranges?

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

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

Кстати, части С++ уже объявлены устаревшими (throw specifiers), а некоторые уже убрали из стандарта (export templates и auto как спецификатор хранения переменной). Я не буду спорить, что в C++ есть свои уродства. Конечно, есть. Некоторые — наследство от C, вроде синтаксиса деклараций. Некоторые от добавления в стандарт фич, в работе с которыми у нас ещё не было достаточного опыта (аллокаторы), и некоторые просто были плохо спроектированы и раздуты (iostreams, locales, string). Я ни разу не видел ситуацию, где было бы оправданно использование виртуального наследования (ОК, я сам его использовал, чтобы эмулировать Concepts, но надеюсь, что в будущем этого будет не нужно). Я думаю, наследование используют слишком часто. Я бы убрал с него акцент и предоставил простой и понятный путь для динамического полиморфизма с value semantics (читайте «Наследование — базовый класс всех зол» Шона Парента).

Я рад был бы застать момент, когда препроцессор уйдёт в прошлое. У других языков есть очень крутые инструменты, которые невозможно реализовать в C++ из-за существования препроцессора. Я бы предпочёл на его месте основанный на AST чистый макропроцессор. Позвольте мне управлять AST моей программы во время компиляции. И мне никогда больше не понадобится вставлять или заменять что-либо.

Есть ли шанс, что в какой-то версии С++ не будет обратной совместимости, как было с некоторыми другими языками?

Не думаю, что такое случится, нет. Может, отдельные библиотеки, но точно не стандарт языка.

Какой у вас любимый язык программирования после C++?

Для простых скриптов я использую Python. Иногда экспериментирую с Хаскеллом. Я люблю строгость и математичность. Прикольно бывает разбираться, как там устроены какие-то вещи, но моего опыта недостаточно, чтобы делать что-то серьёзное.

Когда вы используете Boost, часто ли бывает такое, что вы с трудом понимаете многостраничное сообщение от компилятора?

Не всегда.

Не расстраивает ли вас, что, если подключить к проекту библиотеку Boost, время компиляции замедляется в разы?

Конечно. Когда уже будут модули? :-)

Используете ли вы исключения, когда пишете на C++?

Я обычно пишу код, который exception-neutral (такой, который не влияет на чужие исключения), но довольно редко я выбрасываю исключения из своего кода. Моё понимание жизни такое: исключения надо использовать только для поломок в рантайме, когда устройство мира не совместимо с состоянием программы. А как разработчик библиотек я довольно редко взаимодействую с миром вовне (там слишком большая суматоха.) В первую очередь я сосредоточен на консистентности внутреннего устройства кода. Например, корректно ли вызвали этот метод API? Для такого типа ошибок (их называют логическими) я использую assertions.

Когда вы просматриваете свой код по прошествии времени, он вам нравится или вы хотите его переписать?

Он мне нравится, и я хочу его переписать. Переконструирование библиотек — самая важная часть их конструирования.

Что бы вы хотели увидеть в новом стандарте C++? Какую фичу C++ вы считаете самой вредной и самой полезной?

Повторю, что на мой взгляд здесь сильно влияет то, что я разработчик библиотек. Мне кажется, что decltype были самой отчаянно нужной фичей до появления C++11. Когда я вспоминаю все те кривые костыли, которые пришлось использовать в Boost, чтобы обойтись без decltype, я немедленно становлюсь очень-очень благодарен миру, что нам так больше делать не придётся. Если говорить, об изменениях, которые имели негативный эффект, то совершенно точно это rvalue ссылки. Они очень мощные, но их очень сложно использовать правильно и слишком легко — неправильно. Я сам научился использовать их строго только в тех случаях, в которых я абсолютно уверен.

Не могу не упомянуть ещё noexcept. Даже участники комитета не могут договриться о том, как и где их правильно использовать.

У вас есть совет, как бороться со сложностью языка?

Программируйте только на современном подмножестве языка. В наше время можно писать чистый, понятный и красивый код на C++.

Что до развития в таких сложных языках, как C++ — изменяйте старый код так, чтобы улучшать единообразность кода (см. единообразную инициализацию), и делайте так, чтобы у людей была возможность просто и безопасно делать сложные вещи, в которых легко ошибиться (см. auto, range-form, умные указатели). Переставайте использовать устаревшее (см. auto_ptr, throw specifiers). Создавайте инструменты, которые помогут людям разрабатывать на современном подмножестве языка (см. clang modernize).

C++ часто критикуют за слишком краткую и абстрактную, почти спартанскую стандартную библиотеку. Нет такого разнообразия, как в некоторых современных языках. Вы считаете такой подход правильным?

Точно нет! Критика справедлива: Стандартная библиотека должна стать больше. Я хочу поддержку Юникода, баз данных, date/time, сериализацию, сетевой стек (с поддержкой большого количества разных протоколов), парсеры и т.п. и т.д. Список бесконечен.

Авторы STL считали, что стандартная библиотека должна быть маленькой и атомарной. Это одна из причин того, что в ней нет некоторых базовых для нашего времени вещей. Что вы думаете об этом?

Кто так говорит? Я никогда не слышал, чтобы такое мнение кто-то высказывал в Комитете. Все готовы расширять стандартную библиотеку.

Нужен ли С++ единый репозиторий?

ДА. Помимо нехватки удобных инструментов, я считаю это главным препятствием к ещё более широкому распространению C++ сейчас. Несколько умных парней уже пытаются эту проблему решить, но пока с переменным успехом. Мне кажется, для её решения, возможно нужен гигант вроде Майкрософта, Гугла (или Яндекса?). Это сложная, большая, занудная и не приносящая славы задача того типа, которыми не любят заниматься волонтёры.

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

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

Плохо ли, что C++ редко используется на мобильных устройствах? Все они по-прежнему работают на управляемых языках: Java — на Android, Objective-C и Swift — на iOS. Не пора ли более активно применять C++ в этой области?

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

Но на деле сегодня я всё чаще слышу, что команды пишут часть логики мобильных приложений на C++ ради переносимости. Необходимость поддерживать разный код на разных языках для разных платформ становится слишком ужасной. Это озарение, которое должно когда-нибудь прийти.

Что вы думаете о Rust?

Я слышал о нём хорошие слова, но подробно не разбирался.

В какой IDE вы предпочитаете работать с C++?

Лёгкий вопрос: Visual Studio. Я не пробовал пока CLion, но Eclipse в последний раз, когда я им пользовался (довольно давно, надо признаться), был ужасен настолько, что и словами не описать. Использовать emacs/vim/gdb — это как пытаться каменными инструментами сделать колесо в то время, как остальной мир давно ездит по автострадам. (Да, это вам, злые тролли, которые говорят мне, что моё пренебрежение к emacs/vim — признак луддита.)

Что для вас важнее в вашей работе: эстетика (сделать язык или библиотеки красивее, стройнее) или практика (сделать их удобнее для повседневных задач)? Если второе, то какие задачи вам приходят в голову прежде всего?

Эстетика важна, но6 если бы я считал её самой важной штукой в мире, я бы программировал на Хаскелле. Имея это в виду, я думаю, что «эстетика против практичности» — ложная дихотомия. Можно иметь и то, и то. И мне кажется, что современный стиль программирования на C++ к этому нас очень приближает.

Каждодневные задачи, важные для меня — это те, что встречаются вновь и вновь в каждой программе любого уровня и по любой теме: написание и использование АЛГОРИТМОВ и размышления над их сложностью, эффективностью и корректностью. Программирование именно про это. Сделать C++ лучше применимым для этого — то, что поднимает меня каждое утро. Язык должен быть эффективным, должен решать задачи из реального мира. Но он должен быть и элегантным. Элегантный код легко писать, легко читать, легко корректно использовать и сложно использовать некорректно. Элегантный код доставляет удовольствие, когда его используешь. Если я смогу добавить удовольствия в каждодневную жизнь разработчиков на C++, я буду считать свою работу сделанной.

PS: На мероприятие ещё можно зарегистрироваться. Также можно прийти в офисы Яндекса в Нижнем Новгороде, Екатеринбурге и Минске, чтобы поучаствовать в телемосте и задать свои вопросы Эрику. Для тех, кто не сможет до нас дойти, мы организуем трансляцию, которая будет доступна здесь. Начало трансляции — 16:00 по московскому времени (19:00 — по новосибирскому).
Total votes 64: ↑57 and ↓7 +50
Views 42K
Comments 97
Comments Comments 97



over 10,000 employees