О ненависти к С++

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



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

Взял на себя смелость перевести статью и пару комментариев к ней.

Но прежде чем читать, посмотрите, пожалуйста, на прекрасную карту языка С++ (The C++ Lands). Особая благодарность за карту Алёне Сагалаевой:

---

• Оригинал статьи «C++ Hating» (автор Dean Michael Berris)
• Статья о закате С++ «A skeptic’s history of C++» (автор Chad Perrin)

---

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

Не буду вдаваться в детали — если вам интересно, то оригинал можно найти по ссылке. Разберу только отрывок, на который не могу не отреагировать.

Можно считать, что дни С++ сочтены. Альтернатива, которая наиболее подходит для решения схожих задач — это Objective-C. Другой вариант — Objective Caml, язык который регулярно приводится в качестве примера для высоко-производительных задач и по некоторым показателям часто опережает С++. На нем можно писать кратко и структурировано, предоставляет разработчикам более понятные и интересные модели, которые порой отсутствуют в языках того же уровня. Язык D также можно назвать конкурентом, хотя его проприетарные корни могут помешать его широкому применению. В языке Go от Google много спорных компромиссов, но без сомнения его возможности дают большое преимущество при создании некоторого типа программного обеспечения, включая параллелизм.

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

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

Давайте посмотрим, что он на самом деле говорится в статье и попробуем прочитать между строк.

Можно считать, что дни С++ сочтены. Альтернатива, которая наиболее подходит для решения схожих задач — это Objective-C.

К сожалению, автор не указал какие задачи имеются в виду. Он привёл пример браузеров. Так-что давайте познакомимся с этим поближе.

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

• Google Chrome — кроссплатформенный браузер, первый по скорости и производительности. Если вы захотите заменить язык программирования, на котором он написан, то придется использовать тот язык, который портируется на многие платформы. Я говорю не только о Mac OSX, Windows или Linux — также имею в виду Android (проверьте, Google TV — это Android с портированным Chrome).
  
• Adobe Creative Suite — системы, работающие с видео, аудио и графикой очень требовательны к производительности. Если вы захотите портировать продукты Adobe, то вам придется использовать язык, при помощи которого можно создавать программы использующие наименьшее количество ресурсов компьютера при выполнения простых задач создания/редактирования, и при этом оставляют достаточно ресурсов для выполнения других задач системы. Ох, и конечно же необходимо что-бы программа работала как на OS X, так и на Windows.
  
• Microsoft Office — широко распространенная, расширяемая, встраиваемая и самая нашпигованная фичами система. При портировании Microsoft Office, нужно чтобы в результате не получился монстр и программа быстро реагировала на ваши действия. Вы должны быть уверены, что можно будет написать мощные расширения, которые смотрелись как одно целое с программой.
  
• World of Warcraft — и здесь я рассматриваю не только десктопного клиента, который перерабатывает огромное количество событий, следует куче правил, отрисовывает графику и делает еще кучу всего связанного с игрой. Подумайте также о серверной части. Нужны ли еще какие-либо слова об этой прекрасной программе?
  

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

Другой вариант — Objective Caml, язык который регулярно приводится в качестве примера для высоко-производительных задач и по некоторым показателям часто опережает С++. На нем можно писать кратко и структурировано, предоставляет разработчикам более понятные и интересные модели, которые порой отсутствуют в языках того же уровня.

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

Если говорить о высокопроизводительном коде, то здесь большую роль играет используемый компилятор, а не используемый язык высокого уровня. Это верно для всех компилируемых языков. Легко можно сказать, что один язык лучше другого, если инструменты первого лучше, чем у второго, но в реальности производительность продукта в большей степени зависит от нескольких вещей — железа, компиляторов и кода. Одна из основных причин низкой производительности некоторых программ — это плохой код. Например, когда выбирается алгоритм без учёта реальной ситуации, входных данных,… Если сравнивать пузырьковую сортировку в C++ и поразрядную сортировку в OCaml, то, возможно, программа на OCaml будет более быстрой.

Говоря об эстетике, то это дело вкуса. Поэма, написанная на французском, не будет для меня прекрасна, поскольку я не читаю/говорю/пишу на французском — и тут уже не важно насколько она прекрасна для другого человека. То же самое и для C++ — я видел (и надеюсь, что писал) прекрасный код на C++, но программист на Java или С будет, возможно, иного мнения, поскольку они не знают язык так же как я.

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

У некоторых может возникнуть мнение, что прочитанная книга о С++, даст вам право считать себя профессионалом, но также, как и в случае с другими языками, профессионализм и эффективность приходят только с опытом.

Язык D также может составить конкуренцию, хотя его проприетарность может помешать широкому применению. Язык Go от Google, содержит много спорных компромиссов, но без сомнения его конструкции дают большое преимущество при создании некоторого типа программного обеспечения, включая параллелизм.

Цитируя Джона Дворака (John Dvorak) — «ерунда все это».

Если считаете, что проприетарность может мешать широкому применению, то взгляните на Java, который стал новым Cobol’ом в мире бизнеса. Вспомните об ассемблере x86 — он тоже проприетарен. Существует много закрытых языков программирования, которые широко применяются, проприетарность не помеха: что реально имеет значение — это техническая сторона. Хакеры которые выбирают только те инструменты, которыми будут пользоваться. Если вы хотите продать мне мышеловку, то и она должна быть достаточно хороша, чтобы я решил потратить на неё деньги.

По поводу параллельности, то реальная проблема в том, что основная часть программистов не знает как писать эффективные параллельные программы. Вот где загвоздка. И не имеет значения, какой язык используется. Недостаток знания в предмете, машинных архитектурах, шаблонах разнообразного доступа к данным, в совокупности с ограничениями на ресурсы — вот, что делает параллельное программирование «сложным». Даже когда упоминается Erlang или Go, то все-равно не эффективно писать приложения, когда вы делаете это неправильно и не используете идиомы и шаблоны для параллельных программ.

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

B cнова — фигня все это.

Разработчики, использующие С++ каждый день, не живут в вакууме. Мы знаем о Ruby, Python, Haskell, Lisp, JavaScript, Java и даже такие новомодные языки как Erlang, Go, Lua и т. д. Причиной, по которым организации используют С++ для создания хороших С++ приложений, — является то, что С++ работает и позволяет делать вещи, которые могут делать и другие небольшие языки. Я буду первым, кто признает, что C++ не столь продуктивен, когда необходимо работать с задачами для которых предназначен Lisp, но чтобы вы знали, при использовании современных фич С++, таких как метапрограммирование на шаблонах, можно решать и эти задачи.

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

Заключение

Я смотрю на количество слов в статье — их около 2000. Этот вид ненависти к С++ разжигает меня и заставляет защищаться, но давайте я взгляну в будущее. Причина, по которой считаю С++ мощным инструментов — это не только та, что я потратил на его изучении и использовании много времени. Это далеко не правда, есть другая причина — я очень многого достиг, начав применять С++.

Я слышал много критики в адрес С++ от разных людей. CEO, HR менеджеров, разработчиков, бизнес партнёров и даже С++ программистов. Но причина, по которой С++ стандартизирован ISO, причина по которой процветает рынок приложений на этом языке — это его не ограниченность дизайном — так случилось, что язык был спроектирован с учетом лучших и случайно попавших плохих частей прошлых языков для представления многогранного инструмента для создания хороших приложений. Много что можно сделать с++, намного больше, что можно сделать на других языках.

Если и есть одна критика в сторону C++, то это его неправильное понимание. Если каждый потратит на его изучение столько же времени как на Ruby/Python/JavaScript, то я уверен, что это поменяет представление о языке. Существует много хороших книг о С++ — одна из них Programming: Principles and Practice using C++. Прежде, чем стучать на C++ снова, прочитайте эту книгу и расскажите о слабостях C++ — и будет нормальным, если вы поблагодарите меня потом.

Об авторе Dean Michael Berris:

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

---

Пара критических комментариев к статье и ответы на них.

Программируя на С++ очень легко попасть в ловушки. На нем сложно программировать, поскольку многие вещи просто скрыты от разработчика компилятором (например, компилятор создает по умолчанию конструктор копирования, и если он не был явно создан, то это ведет к побайтовому копированию указателей и может привести в аварии в программе. Даже программа, которая большую часть времени работает нормально, может нести в себе ошибку неправильного использования удаленного указателя. Очень сложно программировать на С++, когда поджимают сроки и, особенно, когда в команде присутствуют новички.

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

Очень большая платформозависимость. Нужно приложить много усилий для портирования с Unix на Windows и обратно.

С++ можно применять для академических проектов, в которых важна гибкость языка и есть достаточно времени, чтобы привести программу к идеальному виду.

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

Но посмотрите на С++ с той стороны, где он напрямую работает с железом. Ещё, вы говорите о «базовых вещах», но не каждый язык имеет четкое представление, что есть «базовая вещь». В С++ базовым является выделение памяти, средства работы с памятью (указатели), типы (классы, структуры, примитивные типы), объекты этих типов (объекты первого класса), управляющие структуры и функции, такие синтаксические конструкции как namespace’ы, модификаторы типов, и все те инструменты для создания модулей и библиотек.

Если вы не любите работать с низкоуровневыми инструментами, то учите STL, используйте Boost, изучайте Loki или ACE. Если вы не понимаете, что такое указатели, то не сможете применять даже С в реальных программах и ничего не добьётесь от С++.
Для С++ существует множество библиотек для разных вещей. Вы можете также использовать уже написанные С библиотеки.

Я не уверен, что вы используете C++ в рабочих проектах и обидно слушать от вас нападки тем, кто использует С++ уже продолжительное время. Но предполагаю, что коль вы считаете, что для С++ имеется меньше библиотек, чем для Java, то не удивлён вашим словам о том, что C++ «полезный инструмент для академических разработок».

Если вы сравниваете С++ c молотком, то существует по крайней мере 5 разных приспособлений и насадок к нему и непонятно какую из них выбрать. Выбрав неверный, вы отобьете себе руки. Да, если выберите правильный, то сможете работать быстрее, но какова вероятность выбора правильного молотка?

C++ был одним из моих инструментов более 10 лет. Я участвовал в больших проектах и некоторые из них все еще используются. Однако, было много проектов, которые останавливалиcь еще до своего завершения — выходили за рамки отпущенного времени и бюджета. После этого команда java программистов реализовывала ту же функциональность в течение 2 недель и без существенных багов. Даже производительность java версии была выше (с++ код не был оптимизирован).

Я видел опытных программистов делающих глупые ошибки, которые так легко совершить, но трудно найти в С++.

Портирование кода с unix на windows — это полный кошмар. Причудливые конструкции с шаблонами имеют большой шанс не быть скомпилированными на другой платформе.

Портирование с windows на unix тоже не сахар.

STL хороша и делает программирование проще и библиотека поддерживается всеми компиляторам. Она предоставляет много «базовых вещей», такие как контейнеры, необходимые нам для реализации бизнес логики. Но помимо хорошего дизайна и удобных штучек, ее сообщения об ошибках просто ужасны. STL может немного различаться на разных платформах, что может привести к проблемам при портировании.
Мы используем ACE/TAO фрейморк, но и с ним возникали проблемы на windows платформе, хотя заявляется, что библиотека платформонезависимая.

Мы тестируем, как Boost может использоваться в наших проектах.

Проблема заключается в том, что мы уже имеем 3 разный фреймворка (2 из них внутренние разработки), которые уже используются и не могут быть просто заменены другим без переписывания большого количества кода — нам это не позволяет бюджет. Написание 4го приведет еще к большей путанице (проблема cвязана не с++, а с непредсказуемой сложностью добавления фунциональности и растущем временем на рефакторинг кода)

Каждый язык имеет свои хорошие и плохие стороны. Очень важно выбрать правильный для проекта.

Хотя C++ предоставляет достаточную гибкость по сравнению с другими языками, но это не тот инструмент для задач, где нужна скорость разработки.

Извините, но инструмент, который вы описали не имеет ничего общего с молотком.
О том, что разработка на С++ более дорога, говорит больше о команде, чем о языке программирования, не правда ли? Я не уверен о каком тип программ вы говорите, но если речь идет о сетевом приложении (я это понял по использованию ACE/TAO), то не вижу где могут возникнуть проблемы. Зная ACE и профессионально используя его ранее, я уверен, что вы быстро реализуете требуемую функциональность, поскольку это уже готовый фреймворк.

Когда вы говорите о глупых ошибках, то на самом деле это зависит от человека пишущего код. Я написал клиента к memcache с нуля за 1 неделю, используя современный C++ стиль, и библиотека все еще используется в том месте, где я ее написал (подсказка: ищите по ключевому слову memcache++). Переписал сервер с нуля за два месяца, 1 месяц использовал для тестирования и улучшений, и это при том, что работал один — сервер может обрабатывать около 5k запросов в секунду (RPS), при этом используется не более 60% CPU и средняя нагрузка 2:1 для СPU. И мне трудно понять, почему многие испытывают сложно с++, когда мне удается делать подобные вещи.

Уверен, что не я один имею такой же положительный опыт.

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

Если говорить о сообщениях об ошибках, то это обязанность компилятора. Cогласен, GCC ужасен в этом плане. Но другие компиляторы могут выводить диагностику лучше, чем GCC — я имею в виду clang — он должен выстрелить в скором времени. MSVC 10 тоже может давать хорошие сообщения.

О вашем проекте я должен сказать, что вы должны нанять эксперта, который знает что делать в подобной ситуации. Наймите BoostPro и обучите вашу команду использовать современные С++ подходы, а не те, что были десятилетие назад.

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