Коли вже в C++ з'явиться свій менеджер пакетів? Яким бачиться майбутнє мови C++ Standards Committee. Інтерв'ю з Еріком Ниблером

Ерік Ниблер — відомий експерт з C++, один з важливих контриб'юторів Boost, чоловік, який додав в стандарт бібліотеку Ranges.

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

image

На захід ще можна зареєструватися. Також можна прийти в офіси Яндекса в Нижньому Новгороді, Єкатеринбурзі та Мінську, щоб взяти участь у телемості і задати свої питання Еріку. Для тих, хто не зможе до нас дійти, ми організуємо трансляцію, яка буде доступна тут. Початок трансляції — 16:00 за московським часом (19:00 — по новосибірському).

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

Оригінал для тих, хто віддає перевагу читати по-англійськиHow did you start to code on C++? Do you write code by yourself (boost stl and 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 to advise 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, installing and 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, sometimes it chooses both and adds a third option. That's bad. The death 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
anymore.

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 and discrete 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 fix this really, 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 Swift and 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
coming.

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 зневажливе 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 actually have 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 feature that and provide a clean, simple way to achieve dynamic polymorphіsm 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 дихотомію. 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, підтримка unicode і так далі і тому подібне. Але, якщо б мені потрібно було вибрати лише одну штуку, яка найбільше вплинула б на 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++, я буду вважати свою роботу зробленою.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.