Язык C++ занимает важное место в IT-отрасли России в целом и в компании, где я сейчас работаю в частности. Многие архитекторы рекомендуют C++ для разработки программ широкого спектра категорий.
В последние годы С++ активно развивается. Осознавая значимость языка, я считаю достаточно важным понимать направление, в котором развивается C++. Поэтому когда мне представилась возможность выступить (копия на YouTube) на конференции C++ Siberia 2017, я непременно решил ею воспользоваться, дабы лично погрузиться в C++-сообщество и проверить своё понимание тенденций развития языка.
Как правило, с развитием языки программирования усложняются. И тут есть одна опасность. С одной стороны, язык становится более мощным и очевидна польза новых функций языка в определённых частных случаях. С другой стороны медали мы имеем повышение сложности языка и, как следствие, увеличения порога вхождения, стоимости разработки, поддержки и т.д. Этот недостаток менее заметен в отличие от очевидной пользы для частных случаев. Язык и так очень сложен. От того, что в нём добавится еще немного сложности, вроде бы ничего плохого нет. Бесконечность + 1 = бесконечность.
Так вот посещение конференции создало впечатление, что представители комитета по стандартизации C++ и экспертное сообщество не видят разумного порога сложности языка. Первые преподносят расширение стандарта и усложнение языка как некоторое достижение и абсолютное благо. А вторые искренне радуются тому, что появились новые функции, которые действительно помогут им в некоторых частных случаях.
При этом если сравнить сложность С++ со сложностью других языков, способных конкурировать с C++ во многих задачах, то создаётся впечатление, что разумный порог сложности для C++ давно пройден. Чтобы не углубляться в технические прдробности (в которых легко утонуть при сравнении языков программирования), проведём грубое, но достаточно показательное сравнение объемов спецификаций. Объём спецификации C++17 составляет более 1600 страниц. Для сравнения, объём спецификации языка Go версии 1.9 cоставляет всего 100 страниц. Относительно C++14, спецификация C++17 увеличилась на 200 страниц. Иными словами, человеку, который знает стандарт 14-го года нужно потратить вдвое больше усилий для освоения C++17, нежели изучить язык Go с нуля.
Чрезмерная сложность языка приводит к ряду негативных для компании-разработчика последствий. Становится непросто найти в команду хорошо знающего современной стандарт специалиста. Соответственно, на рынке труда растёт цена таких специалистов, что удорожает разработку и поддержку C++-проектов. Всё это делает язык менее предпочтительным и побуждает пристальнее искать альтернативы, оставляя C++ для тех случаев, где он действительно эффективен (для сложных высокопроизводительных программ).
Владение современным стандартом языка требует не только больших усилий для изучения, но и непрерывной обильной практики. Это негативно сказывается на кругозоре самих C++-разработчиков. Подтверждение тому я наблюдал непосредственно на конференции в keynote-докладе. Оратор представлял попытку реализации монад в C++. Реализация была основана на концепции, которая в Go назыается каналами и приуствует непосредственно в языке. Получается достаточно забавная картина: на переусложнённом C++ вручную реализуется концепция из простого языка Go. В реультате имеем неуклюжую конструкцию (например, с чуждой для C++ системой обработки ошибок), которую к тому же сложно и дорого поддерживать. Чем обусловлен выбор именно C++ для данного решения, оратор объяснить не смог. Как говорится, когда в руках молоток, все задачи кажутся гвоздями.
Таким образом, тенденция развития языка C++ такова, что из языка общего профиля, подходящего для широкого круга задач, язык становится очень мощным инструментом, но эффективным лишь для написания сложных и высокопроизводительных приложений. Принципиальным тут является изменение роли C++ с де-факто языка общего назначения на специализированную.
Если провести аналогию с автомобилями, то язык C++ из обычной легковушки, которую все привыкли использовать в повседневности, становится БелАЗом - автомобилем мощным, но подходящим для сугубо определённого круга задач. Можно, конечно, купить себе БелАЗ ездить на нём в супермаркет за продуктами, но вряд ли такое решение моно считать эффективным. Хотя и на карьерах языку C++ уже есть кому составить конкуренцию.
Update (2018 May 31): Судя по недавней публикации Страуструпа, уже и до авторов языка начало доходить понимание ошибочности вектора развития C++. Но не слишком ли поздно? Несклько цитат, которые стоит упомянуть:
If every extension that is reasonably well-defined, clean and general, and
would make life easier for a couple of hundred or couple of thousand C++
programmers were accepted, the language would more than double in size. We
do not think this would be an advantage to the C++ community.
...
We should not spend most our time creating increasingly complicated
facilities for experts, such as ourselves. We need a reasonably coherent
language that can be used by “ordinary programmers” whose main concern is
to ship great applications on time.
...
We are on the path to something that could destroy C++.