1. На любом языке можно написать код хорошо, а можно раком. It's true, что для написания кода на языках более высокого уровня нужно меньше мозгов, чтобы было "неплохо". Но на C++ при должной дисциплине кодирования, будет заведомо быстрее. Как минимум потому, что можно использовать свою собственную аллокацию памяти, заточенную под задачу. (Это особенно касается парсеров). На C++ должно быть можно написать сериализатор/парсер, работающий в разы быстрее любого интерпретируемого языка.
2. Твоя статья по ссылке несколько устарела, хотя даже для своего времени (2014/12) она содержит враньё. Например, она упоминает Google Search как пример успешного проекта на Питоне. Это bs, потому что Гугл к тому времени уже давно перевёл Python в разряд скриптовых языков, годящихся только для тулов и тестов. Никакая часть Google Search в production'е не использует Питон. Почему? Потому что это таки скриптовый язык. Lack of static type checking is killing maintainability. Качество 3rd-party библиотек тоже низкое. В этом Питон заведомо ХУЖЕ других интерпретируемых языков, в которых ЕСТЬ static type checking (напр., Java). Но и, конечно, C++ заметно быстрее. Когда для задачи не нужна скорость (напр., very low latency responses) и эффективность использования (для CPU-bound задач), Питон приемлем, хоть и не рекомендован из-за maintainability issues.
Что касается компактности исходников - тот же аргумент. Можно раком и очень длинно, а можно модульно и компактно. Опять же, для Питона нужно меньше мозгов, чтобы компонентизировать, как минимум, потому что ты вынужден пользоваться библиотеками вместо того, чтобы писать свой код. "Скриптовость" языка выражается в том, что расписывать алгоритмы на низком уровне будет заведомо неэффективно, ты *вынужден* использовать библиотеки. На C++ ты *можешь* использовать библиотеки, *можешь* писать свои, но также можешь и писать сплошняком 100500 строк кода. Последнее, конечно, не считается хорошим стилем. Нужно делать первое или второе.
Когда я два раза подряд вижу «нужно меньше мозгов» – тут дело нечисто, потому что это довольно слабый аргумент даже чисто логически, без эмоций.
Там, где нужно меньше мозгов, нужно меньше и денег. Инструменты для того и создают, чтобы делать работу дешевле. Что же в этом плохого? Большинство не пишет парсеры и библиотеки.
Насчёт компактности исходников – не годится аргумент, overall C++ чрезвычайно многословен, это в целом общепризнано. Многобукв == тяжело читать.
Я считаю, что _такое_ многословие избыточно, даже несмотря на предоставляемую гибкость. Она мало где действительно необходима, а там где она опциональна – мало кто может себе позволить C++, как раз из-за дороговизны многословия.
Лишние такты CPU часто оказываются дешевле программистов на C++. С учётом а) огромной вилки цен на рынке на вычислительные ресурсы и б)* явной тенденции выносить вычисления на уже теперь мощные клиентские девайсы, можно об эффективности кода не париться даже в очень существенных проектах.
Очень часто дешевле не код оптимизировать, а архитектурными или административными способами уменьшать затраты, сохраняя при этом гибкость.
И да, Питон – это совсем не для меня есчо, просто на картинке попался. Мне неудобно, когда невидимые символы – необходимая разметка. Для меня это неприемлемый design flaw, который убивает весь кайф от программирования )
----
* – самый тупой пример – ресэмплить картинки на клиенте. Очень дорогая для сервера операция, и в плане IO, и в плане CPU. Вынеси её на клиент – и не пиши на C++, потому что стало не надо.
> Когда я два раза подряд вижу «нужно меньше мозгов» – тут дело нечисто, потому что это довольно слабый аргумент даже чисто логически, без эмоций.
Наверное, это неудачное слово, т.к. я вижу, что оно может нести негативный оттенок. Но если без эмоций, чисто логически, то это весомый аргумент. Мозги это ресурсы - это, во-первых, уровень опыта (свежий выпускник через два месяца будет писать неплохой production code на Питоне, но для такого же неплохого по стандартам C++ стиля ему потребуется пару лет), а во-вторых, объём человеко-трудовых вложений, чтобы создать такой environment, в котором можно будет писать красивый, компактный и эффективный код. Для C++ нужно значительно больше. Нужно либо писать свои библиотеки (что очень дорого), либо хорошо разбираться в существующих и их поддерживать (что, вообще-то, тоже очень дорого).
C++ относительно немногословен, если писать на нём хорошо, особенно C++ 11/14 с новыми фишками (auto, closures, lamdas) и с использованием STL и boost, и, конечно, если не изобретать велосипедов и использовать библиотеки для всего (как это делается в языках высокого уровня) или писать свои, но не учитывать "многословность" реализации библиотек при сравнении. Да, он таки всё равно многословнее, но мы говорим про 2-3x, а не 20x.
> Лишние такты CPU часто оказываются дешевле программистов на C++
Часто - да, но не везде. И уж проект масштаба eBay/Paypal точно не такой. Программисты там стоят столько же, потому что они нанимаются в той же самой Долине за те же деньги, где берут программистов в Google, Apple, Facebook, Microsoft, HP, Oracle, etc. Железки в датацентрах стоят такие же деньги, какие платят все эти компании. Масштаб объёмов и нагрузок очень сравним. Так что я думаю, вероятнее всего, там просто бардак.
На самом деле единственная причина использовать С++ — это скорость. И она, как видим, перевешивает всё остальное. Всё остальное в С++ — это антипричины, доводы за то, чтобы его не использовать.
> единственная причина использовать С++ — это скорость
Есть ещё системы гарвардской архитектуры, в которых JIT/p-code практически невозможен. Повсеместная ситуация в тощих микроконтроллерах, например (хотя там обычно вообще на Сях пишут, потому что даже классы – дорого).
> На самом деле единственная причина использовать С++ — это скорость.
Ну так за это и боремся, поэтому обидно, когда сравнивают кривой код на C++ и хороший на Python, и потом приговаривают, что Python ещё и быстрее.
Скорость и использование памяти.
Я недавно где-то видел бенчмарк тривиального HTTP-сервера на C++, выдающего небольшую статическую страницу, там, кажется, было больше миллиона QPS с одного хоста, типа 15% CPU load, и полный saturation 10 GbE.
Lol, надо же яблоки с яблоками сравнивать. Понятно, что там куча bias'ов. Приведу навскидку примеры возможных bias'ов: *) проекты на C++ и Java существенно более сложные, поэтому в них больше багов, *) C++ и Java более сложные языки, соответственно, больше нубов, пишущих раком (мой поинт выше - выпускник куда быстрее будет писать "неплохой" код на Питоне, чем на C++).
Надо делать настоящий тест - взять тех же людей, проекты той же сложности, с теми же требованиями по performance и resource usage, и написать их и так, и так. Собственно, именно это и сделал Гугл Search, после чего переписали то, что было на Python, на C++, и основная причина переписывания был не performance, а maintainability. В Гугл-Search'е сейчас Python используется только для тестов и тулов.
(Disclaimer: it's nothing official, just my personal opinion and rants, based my own on intuitive guesses)
Для Гугла был выбор оставить Python (для тех production компонент, которые его использовали) или переписать на C++. Причина невыбора других языков в том, что для них в Гугле не было инфраструктуры. Так что это тоже, по сути, maintainability - не та часть, которая баги, а та, которая total cost. Увеличения количества используемых технологий в одной компании дорого стоит. У меня создалось впечатление, что даже Go - в принципе, неплохой язык - развивается медленнее, чем мог бы (и куда ниже, чем могла быть, internal adoption) - именно по причине, что это yet another thing, а мы и так умеем на C++ делать хорошо. Зачем extra things? В отношении Питона таких аргументов не было, т.к. Питон в Гугле был давно и инфраструктура его поддержки хорошая.
Maintainability имеет чёткое определение например в ISO/IEC 25010:2011. Там же кста полно и других аналогичных терминов и их соотношений.
На англ. версию ссылку давать не буду, она платная и дорогая. Вот есть бесплатный русский перевод (достаточно хороший) http://docs.cntd.ru/document/1200121069, ну или на торрентах, если англ. принципиален.
> для них в Гугле не было инфраструктуры. Так что это тоже, по сути, maintainability - не та часть, которая баги, а та, которая total cost
> В чём конкретно я, по-твоему, вышел за рамки понятия?
Я не знаю, что ты имеешь в виду под инфраструктурой, «по сути» и total cost of maintainability, поэтому не могу сказать в чём конкретно.
Тем не менее, инфраструктура обычно к maintainability не относится. Создание инфрастуктуры и обслуживание – это вообще разные этапы жизненного цикла проекта, нет?
Стоимость обслуживания противопоставляется стоимости разработки. Вот нужна новая фича X, её не было, ты её написал, теперь она есть. На это ушёл один человеко-год. Это стоимость разработки.
Обслуживание - это всё остальное. Например, ты взял и заапгрейдил железки, на которых ты run-аешь софт. Например, ты используешь third-party либу, а она не поддерживает эти новые железки, и тебе нужно импортировать новую версию. Ты её заимпортировал, протестировал, там нашлись баги. Ты в них разбираешься, чинишь, cherry-pick'аешь фиксы из development branch'а. Это не баги твоего софта и твоей фичи X, правильно? Это "вообще, обслуживание", та часть, которая total cost. Я именно это имел в виду, здесь я не расширяю понятие сопровождение, как видишь.
Или: тебе нужны инструменты для отладки, код ревью, code coverage. Чем больше всякого говна ты тянешь из third party, тем больше работы. Ты рассудил, что это слишком дорого, и вместо third party либы пишешь свою либу. Количество фич в продукте не меняется - поэтому написание такой либы это инфраструктурный проект по сопровождению.
Понятно, инфраструктурные вещи не всегда причисляются к сопровождению, например, когда у тебя ничего не было, и тебе нужнен самый первый application, те инфраструктурные вещи, которые ты в самом начале строишь можно отнести к стоимости разработки. Без хорошей инфраструктуры будет 5 человеко-лет, а с хорошей инфраструктурой, на разработку которой уйдёт 10 человеко-лет, фича займёт 1 человеко-год. Зато следующие три фичи будут тоже по одному человеко-году каждая, а не по 5.
С другой стороны, сопровождение по стоимости относится к разработке как 4 к 1 (80% всех расходов), поэтому, в принципе, вполне можно "округлять" и говорить, что вся инфраструктурная работа (libraries, tools, refactoring, cleanup) это сопровождение. В этом случае понятие сопровождение действительно немного расширяется.
> Например, ты взял и заапгрейдил железки > Это "вообще, обслуживание"
Я не помню, чтобы _внезапный_ железный апгрейд вообще где-нибудь считали в обслуживание – и спецы другие, и риски, и incentives делать систему, которую можно апгрейдить когда угодно.
Есть в военных стандартах понятие evolutionary acquisition – создание системы с нечёткими конечными требованиями по шагам. Там пригодность системы к развитию связывается с maintainability в контексте существования нескольких версий продукта с разными процедурами обслуживания. Но это всё равно не то, что ты описываешь.
С другой стороны, частичное внесение апгрейда софта в понятие «обслуживание» точно не лишено смысла. Просто стандарты, касающиеся system engineering, обычно идут из мира атомов, а там всё немного иначе.
Я почитаю ещё, good point.
---
> Стоимость обслуживания противопоставляется стоимости разработки
Деление мира на свою поляну (разработка) и весь остальной лес – плохое деление. Оно удобно, только если всегда смотреть с этой поляны.
В той части IT, что меня окружает, maintenance определен куда проще, с бизнес т.з. Вот есть онлайн-магазин Shopogon (названия вымышлены). У него есть поисковый движок. Я директор магазина и группе поискового движка выделяю 20 млн в год. Из них 5 млн железки, 15 все остальное (люди, их менеджеры, hr, receptionist, может даже и офисы/facilities). С моей т.з. 20 млн в год это стоимость статус-кво. Т.е. это железо плюс сопровождение. Если я хочу новую фичу X, на нее нужно нанять 5 человек, и это будет +1 млн в год на разработку. Через год разработка закончится, но 2 человека потребуются для дальнейшего сопровождения (0.4 млн в год). 0.6 млн в год - оставшийся ресурс для новых фич.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2016-06-20 05:22 pm (UTC)1. На любом языке можно написать код хорошо, а можно раком. It's true, что для написания кода на языках более высокого уровня нужно меньше мозгов, чтобы было "неплохо". Но на C++ при должной дисциплине кодирования, будет заведомо быстрее. Как минимум потому, что можно использовать свою собственную аллокацию памяти, заточенную под задачу. (Это особенно касается парсеров). На C++ должно быть можно написать сериализатор/парсер, работающий в разы быстрее любого интерпретируемого языка.
2. Твоя статья по ссылке несколько устарела, хотя даже для своего времени (2014/12) она содержит враньё. Например, она упоминает Google Search как пример успешного проекта на Питоне. Это bs, потому что Гугл к тому времени уже давно перевёл Python в разряд скриптовых языков, годящихся только для тулов и тестов. Никакая часть Google Search в production'е не использует Питон. Почему? Потому что это таки скриптовый язык. Lack of static type checking is killing maintainability. Качество 3rd-party библиотек тоже низкое. В этом Питон заведомо ХУЖЕ других интерпретируемых языков, в которых ЕСТЬ static type checking (напр., Java). Но и, конечно, C++ заметно быстрее. Когда для задачи не нужна скорость (напр., very low latency responses) и эффективность использования (для CPU-bound задач), Питон приемлем, хоть и не рекомендован из-за maintainability issues.
no subject
Date: 2016-06-20 05:26 pm (UTC)no subject
Date: 2016-06-20 06:54 pm (UTC)Там, где нужно меньше мозгов, нужно меньше и денег. Инструменты для того и создают, чтобы делать работу дешевле. Что же в этом плохого? Большинство не пишет парсеры и библиотеки.
Насчёт компактности исходников – не годится аргумент, overall C++ чрезвычайно многословен, это в целом общепризнано. Многобукв == тяжело читать.
Я считаю, что _такое_ многословие избыточно, даже несмотря на предоставляемую гибкость. Она мало где действительно необходима, а там где она опциональна – мало кто может себе позволить C++, как раз из-за дороговизны многословия.
Лишние такты CPU часто оказываются дешевле программистов на C++. С учётом а) огромной вилки цен на рынке на вычислительные ресурсы и б)* явной тенденции выносить вычисления на уже теперь мощные клиентские девайсы, можно об эффективности кода не париться даже в очень существенных проектах.
Очень часто дешевле не код оптимизировать, а архитектурными или административными способами уменьшать затраты, сохраняя при этом гибкость.
И да, Питон – это совсем не для меня есчо, просто на картинке попался. Мне неудобно, когда невидимые символы – необходимая разметка. Для меня это неприемлемый design flaw, который убивает весь кайф от программирования )
----
* – самый тупой пример – ресэмплить картинки на клиенте. Очень дорогая для сервера операция, и в плане IO, и в плане CPU. Вынеси её на клиент – и не пиши на C++, потому что стало не надо.
no subject
Date: 2016-06-21 04:43 am (UTC)Наверное, это неудачное слово, т.к. я вижу, что оно может нести негативный оттенок. Но если без эмоций, чисто логически, то это весомый аргумент. Мозги это ресурсы - это, во-первых, уровень опыта (свежий выпускник через два месяца будет писать неплохой production code на Питоне, но для такого же неплохого по стандартам C++ стиля ему потребуется пару лет), а во-вторых, объём человеко-трудовых вложений, чтобы создать такой environment, в котором можно будет писать красивый, компактный и эффективный код. Для C++ нужно значительно больше. Нужно либо писать свои библиотеки (что очень дорого), либо хорошо разбираться в существующих и их поддерживать (что, вообще-то, тоже очень дорого).
C++ относительно немногословен, если писать на нём хорошо, особенно C++ 11/14 с новыми фишками (auto, closures, lamdas) и с использованием STL и boost, и, конечно, если не изобретать велосипедов и использовать библиотеки для всего (как это делается в языках высокого уровня) или писать свои, но не учитывать "многословность" реализации библиотек при сравнении. Да, он таки всё равно многословнее, но мы говорим про 2-3x, а не 20x.
> Лишние такты CPU часто оказываются дешевле программистов на C++
Часто - да, но не везде. И уж проект масштаба eBay/Paypal точно не такой. Программисты там стоят столько же, потому что они нанимаются в той же самой Долине за те же деньги, где берут программистов в Google, Apple, Facebook, Microsoft, HP, Oracle, etc. Железки в датацентрах стоят такие же деньги, какие платят все эти компании. Масштаб объёмов и нагрузок очень сравним. Так что я думаю, вероятнее всего, там просто бардак.
no subject
Date: 2016-06-21 08:21 am (UTC)Относительно чего? 😜
no subject
Date: 2016-06-21 08:25 am (UTC)no subject
Date: 2016-06-21 12:11 pm (UTC)Насчет «заведомо» я бы не был так уж уверен https://labs.ig.com/static-typing-promise
На самом деле единственная причина использовать С++ — это скорость. И она, как видим, перевешивает всё остальное. Всё остальное в С++ — это антипричины, доводы за то, чтобы его не использовать.
no subject
Date: 2016-06-21 01:06 pm (UTC)Есть ещё системы гарвардской архитектуры, в которых JIT/p-code практически невозможен. Повсеместная ситуация в тощих микроконтроллерах, например (хотя там обычно вообще на Сях пишут, потому что даже классы – дорого).
no subject
Date: 2016-06-21 03:31 pm (UTC)Ну так за это и боремся, поэтому обидно, когда сравнивают кривой код на C++ и хороший на Python, и потом приговаривают, что Python ещё и быстрее.
Скорость и использование памяти.
Я недавно где-то видел бенчмарк тривиального HTTP-сервера на C++, выдающего небольшую статическую страницу, там, кажется, было больше миллиона QPS с одного хоста, типа 15% CPU load, и полный saturation 10 GbE.
> Насчет «заведомо» я бы не был так уж уверен https://labs.ig.com/static-typing-promise
Lol, надо же яблоки с яблоками сравнивать. Понятно, что там куча bias'ов. Приведу навскидку примеры возможных bias'ов:
*) проекты на C++ и Java существенно более сложные, поэтому в них больше багов,
*) C++ и Java более сложные языки, соответственно, больше нубов, пишущих раком (мой поинт выше - выпускник куда быстрее будет писать "неплохой" код на Питоне, чем на C++).
Надо делать настоящий тест - взять тех же людей, проекты той же сложности, с теми же требованиями по performance и resource usage, и написать их и так, и так. Собственно, именно это и сделал Гугл Search, после чего переписали то, что было на Python, на C++, и основная причина переписывания был не performance, а maintainability. В Гугл-Search'е сейчас Python используется только для тестов и тулов.
no subject
Date: 2016-06-21 04:38 pm (UTC)no subject
Date: 2016-06-21 05:18 pm (UTC)Для Гугла был выбор оставить Python (для тех production компонент, которые его использовали) или переписать на C++. Причина невыбора других языков в том, что для них в Гугле не было инфраструктуры. Так что это тоже, по сути, maintainability - не та часть, которая баги, а та, которая total cost. Увеличения количества используемых технологий в одной компании дорого стоит. У меня создалось впечатление, что даже Go - в принципе, неплохой язык - развивается медленнее, чем мог бы (и куда ниже, чем могла быть, internal adoption) - именно по причине, что это yet another thing, а мы и так умеем на C++ делать хорошо. Зачем extra things? В отношении Питона таких аргументов не было, т.к. Питон в Гугле был давно и инфраструктура его поддержки хорошая.
no subject
Date: 2016-06-21 06:20 pm (UTC)Maintainability имеет чёткое определение например в ISO/IEC 25010:2011. Там же кста полно и других аналогичных терминов и их соотношений.
На англ. версию ссылку давать не буду, она платная и дорогая. Вот есть бесплатный русский перевод (достаточно хороший) http://docs.cntd.ru/document/1200121069, ну или на торрентах, если англ. принципиален.
no subject
Date: 2016-06-22 03:40 am (UTC)Maintainability это сопровождаемость, п.4.2.7 (включая подпункты)
no subject
Date: 2016-06-22 10:46 am (UTC)> В чём конкретно я, по-твоему, вышел за рамки понятия?
Я не знаю, что ты имеешь в виду под инфраструктурой, «по сути» и total cost of maintainability, поэтому не могу сказать в чём конкретно.
Тем не менее, инфраструктура обычно к maintainability не относится. Создание инфрастуктуры и обслуживание – это вообще разные этапы жизненного цикла проекта, нет?
no subject
Date: 2016-06-22 03:47 pm (UTC)Обслуживание - это всё остальное. Например, ты взял и заапгрейдил железки, на которых ты run-аешь софт. Например, ты используешь third-party либу, а она не поддерживает эти новые железки, и тебе нужно импортировать новую версию. Ты её заимпортировал, протестировал, там нашлись баги. Ты в них разбираешься, чинишь, cherry-pick'аешь фиксы из development branch'а. Это не баги твоего софта и твоей фичи X, правильно? Это "вообще, обслуживание", та часть, которая total cost. Я именно это имел в виду, здесь я не расширяю понятие сопровождение, как видишь.
Или: тебе нужны инструменты для отладки, код ревью, code coverage. Чем больше всякого говна ты тянешь из third party, тем больше работы. Ты рассудил, что это слишком дорого, и вместо third party либы пишешь свою либу. Количество фич в продукте не меняется - поэтому написание такой либы это инфраструктурный проект по сопровождению.
Понятно, инфраструктурные вещи не всегда причисляются к сопровождению, например, когда у тебя ничего не было, и тебе нужнен самый первый application, те инфраструктурные вещи, которые ты в самом начале строишь можно отнести к стоимости разработки. Без хорошей инфраструктуры будет 5 человеко-лет, а с хорошей инфраструктурой, на разработку которой уйдёт 10 человеко-лет, фича займёт 1 человеко-год. Зато следующие три фичи будут тоже по одному человеко-году каждая, а не по 5.
С другой стороны, сопровождение по стоимости относится к разработке как 4 к 1 (80% всех расходов), поэтому, в принципе, вполне можно "округлять" и говорить, что вся инфраструктурная работа (libraries, tools, refactoring, cleanup) это сопровождение. В этом случае понятие сопровождение действительно немного расширяется.
no subject
Date: 2016-06-22 04:40 pm (UTC)> Это "вообще, обслуживание"
Я не помню, чтобы _внезапный_ железный апгрейд вообще где-нибудь считали в обслуживание – и спецы другие, и риски, и incentives делать систему, которую можно апгрейдить когда угодно.
Есть в военных стандартах понятие evolutionary acquisition – создание системы с нечёткими конечными требованиями по шагам. Там пригодность системы к развитию связывается с maintainability в контексте существования нескольких версий продукта с разными процедурами обслуживания. Но это всё равно не то, что ты описываешь.
С другой стороны, частичное внесение апгрейда софта в понятие «обслуживание» точно не лишено смысла. Просто стандарты, касающиеся system engineering, обычно идут из мира атомов, а там всё немного иначе.
Я почитаю ещё, good point.
---
> Стоимость обслуживания противопоставляется стоимости разработки
Деление мира на свою поляну (разработка) и весь остальной лес – плохое деление. Оно удобно, только если всегда смотреть с этой поляны.
no subject
Date: 2016-06-22 05:35 pm (UTC)