Продуктивность разработки на C++.

определённые классы ошибок, возможные в C++, невозможны в питоне, обратное утверждение неверно.

обратное утверждение неверно.

Таки вы утверждаете, что в C++ возможна ситуация, когда в рантайме выясняется, что у объекта a на самом деле нет метода a.b(), и всё с грохотом падает? А в Python возможна. Busted.

О чём вы? В C++ с грохотом упадёт компиляция, в питоне рантайм, в обоих случаях ошибка обнаружена. Читайте внимательно о чём идет речь прежде чем влезать. А ещё подумайте что в C++ случится в рантайме, если поменяется ABI библиотеки (скажем, методы поменяются местами), а использующий её код не будет пересобран.

Как интересно. Несколькими сообщениями выше ты писал про «на руках ты имеешь только результат, не зная ни изначальных данных, ни имея возможности их повторить», а теперь уже gdb и valgrind доступны?

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

Посмотрю я как ты поотлаживаешь многопоточную программу с левыми плагинами, у клиента, у которой в выхлопе раз в год появляется мусор. В питоне ты можешь хоть бы и обернуть выходной массив в обёртку проверяющую что в него кладут и кидающую assert, поскольку точно знаешь что ничто не изменит содержимое массива кроме как через его интерфейс. А в плюсах... ну, удачи, рассказывай клиенту про то как вотчпоинты в gdb ставить и под валгриндом тормозить.

Cool story.

Я говорю что они ловят не всё и используются не всеми

И это ты упрекаешь меня в том как и на что я отвечаю... Ну и, да, не все и не всеми, а вот программы на С и С++ используются всеми, в то время как от многого софта на питоне плюются, и далеко не всегда дело в производительности.

В C++ с грохотом упадёт компиляция, в питоне рантайм, в обоих случаях ошибка обнаружена

В цитатник.

Нет, это ты сводишь разные классы ошибок к сферической «порче данных» в вакууме, и делаешь вывод что она возможна во всех языках. Логично чо. Только если глаза разуть, то там где в C++ ты не попав в массив тихо изменил то что расположено за ним, и нашёл это только под valgrind, которого у тебя, как ты сам же сказал и так удобно забыл, может и не быть, в питоне ты получил исключение. As easy as that.

С++:

vector<int> v { 0 };
int index = 0;
v.at( index - 1 ) = 10; // Не проверили index - исключение

Питон:

v=[1]
index=0
v[index-1]=0 // Не проверили index - похерили данные

На плюсах много тупой писанины. В большинстве случаев приходится описывать одно и то же дважды (с немного отличающимся синтаксисом): определение класса в заголовочном файле / реализация в cpp-файле. Даже с умными IDE это раздражает. Кроме того, несмотря на наличие стандартной библиотеки, в ней мало что есть. Шаг в сторону - извольте искать стороннюю либу или изобретать велосипед. Если все необходимые библиотеки есть - продуктивность не сильно ниже, чем при использовании python. На практике даже ручное управление памятью в C++ не такое сложное и страшное, как рассказывается в легендах разработчиками, не вылезавшими за пределы уютной VM.

Читайте внимательно о чём идет речь прежде чем влезать.

Спасибо, и вам доброго вечера. На зрение пока не жалуюсь. А о чём идет речь, а то очень хочется влезть? :)

В C++ с грохотом упадёт компиляция, в питоне рантайм, в обоих случаях ошибка обнаружена

В C++ с грохотом упадёт компиляция, в питоне рантайм, а вместе с ним и боевой сервер. Так себе сравнение.

Сначала прокомментируйте пример с ABI, потом поговорим про «падение боевого сервера».

vector<int> v { 0 };
int index = 0;
v.at( index - 1 ) = 10; // Не проверили index - исключение

Смешно. И много ты видел кода с at вместо []?

v=[1]
index=0
v[index-1]=0 // Не проверили index - похерили данные

Как ты удобно выбрал частный случай index - 1 вместо index + N.

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

Правильно. А ещё есть такие которые легко повторить в питоне и малореально в C++. А таких, которые малореально в питоне но реально в C++ - нет.

Cool story.

То есть возразить нечем.

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

Список всего софта от которого плюются и всех кто плюётся.

определение класса в заголовочном файле / реализация в cpp-файле

Но при этом заголовочный файл может быть более удобен для чтения.

Кроме того, несмотря на наличие стандартной библиотеки, в ней мало что есть

Да и то, что есть, не особенно «дружелюбно». Тяжелое наследие царского режима (с). Хотя до С++11 все еще хуже было.

ABI - боль, но в питоне же будет тоже самое, или я не прав?

Вот удалил метод в новой версии либы - как мне это узнать не в рантайме. Читать чейнжлоги?

Но при этом заголовочный файл может быть более удобен для чтения.

Только при использовании pimpl. Как только начинается inline и шаблоны - всё превращается в ад.

Да и зачем этот пережиток прошлого, если любой текстовый редактор умеет в outline.

А таких, которые малореально в питоне но реально в C++ - нет.

Их еще больше. Одна только динамическая типизация дает массу вариантов.

То есть возразить нечем.

Я сомневаюсь, что твой опыт написания многопоточного софта на питоне сравним с моим на С++. В том числе по низкоуровневости задач.

Список всего софта от которого плюются и всех кто плюётся.

Все непопулярные аналоги софта на С и С++, которым ты несомненно пользуешься. Плюются очевидно те, кто не выбрал аналог на питоне, да и ты в том числе, пусть и не буквально.

Смешно. И много ты видел кода с at вместо []?

Достаточно. В том числе и с другими контейнерами, отличных от std-ых.

Как ты удобно выбрал частный случай index - 1 вместо index + N.

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

Не надо путать API и ABI. Я сейчас о последнем, и в питоне вообще такой проблемы нет.

Я сомневаюсь, что твой опыт написания многопоточного софта на питоне сравним с моим на С++. В том числе по низкоуровневости задач.

И очень зря, но уповать больше не на что, да?

Все непопулярные аналоги софта на С и С++, которым ты несомненно пользуешься. Плюются очевидно те, кто не выбрал аналог на питоне, да и ты в том числе, пусть и не буквально.

То есть ни списка софта, ни списка людей. Пук в лужу.

В питоне вообще много чего нет. И?

Как только начинается inline и шаблоны - всё превращается в ад

Приличные люди отделяют реализацию инлайновых и шаблонных методов, см. как в том же Qt сделано. В самых жестких случаях в отдельный _impl.h

Что раздувает хедер ещё сильнее.

И очень зря, но уповать больше не на что, да?

Уповать? У тебя там видно своя атмосфера. Ну и если я не прав, то можешь рассказать чем занимался. Интересно что же такое многопоточное пишут на питоне, если это не тупо веб, конечно.

То есть ни списка софта, ни списка людей. Пук в лужу.

Может еще список заверить у нотариуса? Но хорошо, к примеру возьмем провалившиеся bazaar и mercurial, тормозные yum и portage, практически любую гуйню, если только не в тесной связке с С и С++. Про СУБД и пр. смысла говорить вообще нет.

П.С. При этом питон хорош для скриптования, и прекрасно дополняет выше упомянутые С и С++.

Не понимаю, чем философия C++ мешает появлению «стандартной инфраструктуры». Что же в ней особенного такого?

Плюсы в каком-то смысле следуют unix философии, т.е. пытаются сделать нормально язык и только ... т.к. ЯП далеко не ушёл от системщины из-за чего существует мн-во способов готовить инфраструктуру и требования к ней в разных случаях могут быть несовместимыми.

Вот ты что предпочтёшь, купить кучу деталей, из которых потом сделаешь автомобиль себе, или купишь его в автосалоне?

Вообще то сборка частей в целое это как раз работа инженера, в данном случае софтварного. Инженер не может пойти в магазин и купить конечный продукт своей деятельности.

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

Но мне такого счастья не нужно. Это значит, что я «днище», а ты тру?

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

Так, хорошо. Т.е. ты вообще всё делаешь на C++?

Если я успел нажраться питона что он уже порядком задолбал, то, очевидно, не всё.

неужели на C++ продуктивными могут быть только киборги и/или гении, которые никогда не допускают ошибок?

Для плюсов очень важна культура разработки. Заставить человека перестать ошибаться невозможно, но можно пользоваться определённым набором правил благодаря которым можно существенно уменьшить кол-во подобных ошибок.

В частности, нужно делить код на опасный и безопасный. Когда работаешь с потенциально опасным кодом, то нужно уделять больше внимания работе. В твоём примере есть опасная работа с указателями и её нужно было перепроверить, сходить в man для прояснения контрака стандартной ф-ии и т.д. А обезопасить его можно завернув в ф-ю интерфейс которой не позволяет наделать плохого. Такой ф-ией уже можно пользоваться как попало.

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

Просто для тебя стакан наполовину пуст. Так-то нужно радоваться возможности писать многопоточные программы.

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

Сказочник уев. А тебе не рассказывали, что в питоне все объекты шарабельны со всем кодом и ещё мутабельны кроме примерно чисел? Т.е. кто-то нехороший может запомнить ссылку на твой массив и поменять его через стандартный интерфейс хрен знает из какой мухосрани. И хрен ты найдёшь как такое происходит в большой программе. Типичный пример питонокосяков

a = [[]] * 3
a[0].append(1)

существует мн-во способов готовить инфраструктуру и требования к ней в разных случаях могут быть несовместимыми

Ну так сейчас как раз работают над тем, чтобы сделать совместимыми. То есть твое мнение понятно. Но есть мнение, что такую инфраструктуру создать можно. Для этого и желают пакетные менеджеры. Тот же Conan. А в язык хотят добавить модули.

Инженер не может пойти в магазин и купить конечный продукт своей деятельности.

Как так? Вообще-то может. В принципе может. Ну какой-то инженер придумал какой-нибудь ZX Spectrum. Потом пошёл в магазин и купил готовый ZX Spectrum.

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

Так если vim даже не умеет в навигацию по коду, с какой такой стати я его должен рассматривать как качественный и, тем более, удобный инструмент? Это как раз швейцарский армейский нож.

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

И чем же твои аналогии про «вообще то сборка частей в целое это как раз работа инженера» и про «если хочешь аналогии, то нужно смотреть как собираешься склеивать детали в целое» отличаются от аналогии собрать автомобиль из деталек? Что-то я не вижу отличия шила от мыла.

Если я успел нажраться питона что он уже порядком задолбал, то, очевидно, не всё.

Если ты успел нажраться Питона, то очевидно, что теперь ты уже не пишешь на Питоне. А на чем ты пишешь? На C++ или еще на чем-то?

Собирать дольше и сложнее.

Это если писать код для запуска только на localhost. Промышленный код, обычно нужно запускать на разных системах, поэтому, для него потребуется что-то еще кроме cool_proga.py, и написание CmakeLists.txt - это копейки.

А, вообще, я уже давно не понимаю нытье разработчиков в стиле «я пишу код, а CmakeLists.txt писать не хочу и не буду» (или скрипты сборки, или разбираться, как настроить базу, чтобы код работал с нужной скоростью). Возможно, предыдущий опыт сисадминства (когда нужно было решать задачу от подбора и сборки железа до настройки всего софта на сервере и написания всех нужных скриптов) мешает понять такой подход к разработке. Впрочем, IMHO, разработчики слишком много и вкусно кушают из-за сильного перекоса соотношения спроса/предложения в их пользу, потому и возникают ситуации типа я код написал, он на моей машине работает, а теперь вы сами разбирайтесь, что сделать, чтобы он заработал на сервере (типа, мое время дороже, а на самом деле мне лень). У сисадминов в разы (2-3 раза) ниже оплата, количество нервотрепки во время работы и сложность смены работодателя, поэтому, приходится решать задачи, а не плакаться, что не хочется писать CmakeLists.txt.

То ещё говно...

Почему?

Есть секта cmake-хейтеров. Они почему-то не могут сказать, что им cmake просто не нравится, вместо этого зачем-то придумывают какие-то оправдания. В результате я еще толком ни разу не слышал нормальных аргументов, чем плох cmake (особенно с предложением лучшего инструмента или хотя бы предложениями, как его сделать лучше), зато высказывания типа «cmake аццтой» слышу регулярно.

В общем, «cmake - отстой» - это просто тема поговорить.

Вдогонку, единственное нормальное объяснение, как нужно использовать современный cmake (для тех, кто уже хорошо знаком с cmake)

https://www.youtube.com/watch?v=bsXLMQ6WgIk&feature=youtu.be

Вот недавно кейс был

И насколько хорошо эта задача решится на питоне, где про битность платформы даже не задумываются?

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

Тебе показалось...

Но есть мнение, что такую инфраструктуру создать можно. Для этого и желают пакетные менеджеры.

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

В разработку инструментов инфраструктуры вкладываются все: fb сделало поддержку своей помойки для HG, m$ пытается впихнуть в Git репозитории на сотни GiB через свою GVFS, google вообще имеет свою VCS, какой-то yandex пилит собственную систему сборки в такой же помойке и т.д.

У всех есть ресурсы заниматься разработкой востребованных инструментов, но пакетный менеджер для с++ никому не нужен. Ты всего лишь принял нишевое мнение хипстоты на счёт инфраструктуры за тренд. К слову, все эти пакетные менеджеры загнулись в зародыше - в с++ мире не хотят вляпываться в клоунады (хватает чудес с UB).

Это всё для иллюстрации разнообразия мнений на счёт инфраструктуры плюсов и почему она никогда не будет стандартной.

А в язык хотят добавить модули.

Фича ортогональная инфраструктуре.

Потом пошёл в магазин и купил готовый ZX Spectrum.

Готовый продукт купил пользователь, а инженер - набор для сборки спектрума (да, такие были).

Так если vim даже не умеет в навигацию по коду, с какой такой стати я его должен рассматривать как качественный и, тем более, удобный инструмент?

Умеет, хотя она особо и не нужна.

И чем же твои аналогии ... отличаются от аналогии ... я не вижу отличия шила от мыла.

Да, это проблема. Все нужные слова для пояснения уже написал в прошлом посте, видимо нужно потратить время на осмысление аналогий.

... то очевидно, что теперь ты уже не пишешь на Питоне. А на чем ты пишешь?

Какая-то у тебя странная логика, нет, такого суждения сделать нельзя. Пишу в основном на с++ и иногда вспомогательное гогнецо на питоне.

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

P.S.: Тут товарищи еще про необходимость компиляции упомянули. В общем, это больше спор предпочтений: скорость исполнения (C++) vs скорость разработки (Python)

В каком месте mercurial провалился? Им очень многие пользуются и многим он удобнее git.

гуйню

Постоянно использую meld, gajim, deluge, gwsmhg, exaile. Не плююсь.

Вообще много всего на нем даже банальные command-not-found и ubuntu-software-center

в тесной связке с С и С++

Что в этом плохого? Сам питон на си и куча модулей к нему.

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

Да. Но не любой язык это прощает.

Хорошо. Вот нужно _с нуля_ написать сетевой сервер. Допустим, пусть будет HTTP-сервер.

C/rust, т.к. сервер не должен проседать по цп/памяти, не должно быть оверхеда, извратные абстракции не нужны.

Как раз говнокодить на плюсах намного проще.

Я не говорю о том, проще или нет. На си/плюсах _надо_ писать аккуратно, иначе будет очень плохо. На пистонах можно писать как попало и тебе за это ничего не будет, кроме жора памяти и тормозов.

кроме примерно чисел

И строк, и tuples и чего ты сам в таком виде накодишь со всякими __slots__.

И хрен ты найдёшь как такое происходит в большой программе.

In [32]: class MyList(list):
    def __setitem__(self, k, v):
        list.__setitem__(self, k, v)
        curframe = inspect.currentframe()
        calframe = inspect.getouterframes(curframe, 2)
        print 'caller name:', calframe[1][3]
   ....:         

In [33]: x = MyList([1,2])

In [34]: def foo():
   ....:     x[1] = 'z'
   ....:     

In [35]: foo()
caller name: foo

А ещё через модуль gc можно найти все ссылки на твой объект и много чего ещё.

питонокосяков

Здесь нет никакого косяка, ты создаешь объект один раз и делаешь 3 ссылки на него. А вообще так никто не пишет. Мог ты что-нить более забавное найти типа:

>>> a = ([],)
>>> a[0].extend([1])
>>> a[0]
[1]
>>> a[0] += [2]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment
>>> a[0]
[1, 2]

Питонщики могут себе позволить предусматривать только самые опасные/вероятные особенности - те, в которых клиент получил трейсбек

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

не захочет исправить окружение

Вы хотите чтобы пользователь за вас дописывал? Вот это наглость.

обратится в супорт.

Конечно платный, желательно где-нибудь 100килобаксов в год.

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

Готовый продукт купил пользователь, а инженер - набор для сборки спектрума (да, такие были).

Будто бы инженер, который способен собрать спектрум, не может пойти в магазин и купить себе готовый, как раз чтобы не собирать (ибо собирать просто в лом).

пользователь просто обожает

При чём тут пользователь и его боги? Обсуждался банальный факт - падение с понятной диагностикой - «приемлемо», и требует меньше труда от питонщиков со товарищи.

пользователь за вас дописывал ... платный, желательно где-нибудь 100килобаксов

Ты когда-то обращался в поддержку с софтовой проблемой? Особенно коммерческую, за 100кбаксов? По моему опыту общения с таковыми, понятный трейсбек рулит нецензурно. К тому же, у него есть безусловно полезный побочный эффект - обучение конечных пользователей:).

Выражаю вам презрение

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

Тебе показалось.

Да нет, вчера был вебинар по Conan. Нормальный такой менеджер пакетов. Так что я остаюсь при своём мнении по поводу возможности создания стандартного менеджера со всеми вытекающими отсюда следствиями в части инфраструктуры. Ну и вообще, чего гадать? Время всё расставит по местам. Вот мы и посмотрим кто был не прав.

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

Совершенно верно.

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

Под «никому» ты, видно, имеешь в виду софтверных гигантов. Им пакетный менеджер не нужен. А вот мне он очень нужен. Мне не хочется тратить дни и ночи на рутину. Мне хочется подгружать зависимости легко и непринуждённо. Почему я должен вечно жрать кактус, оглядываясь на какую-то мифическую философию C++, или на корпорации мирового уровня с сотнями наёмных программистов, архитекторов, экспертов и т.п.? Мне нужен простой и удобный механизм для работы с зависимостями. Хипстота это или нет - мне всё равно.

Фича ортогональная инфраструктуре.

Ну не совсем она уж ортогональная. Способствующая, я бы так сказал.

Готовый продукт купил пользователь, а инженер - набор для сборки спектрума (да, такие были).

Нет, ну если инженеру хватает времени и желания спаять спектрум самому - это его личное решение. Он распоряжается отрезком, отведённому ему в этом мире времени, именно таким образом. Так же как и гордые и несгибаемые пользователи vim. Мне (торгашу и потребителю, как ты соизволил меня назвать) жалко времени на изготовление инструмента для работы. Поэтому я расплачиваюсь деньгами и беру более-менее подходящий мне, уже настроенный дядей инструмент. Я плачу деньги, получаю инструмент для зарабатывания денег, а дядя-разработчик - свой доход. В итоге - оба в профите, оба рады, оба идут в магазины и покупают жёнам шубы. (Ах, это торгаш же идёт за шубой в магазин, а инженер идёт в лес на охоту, добывает шкуру и шьёт жене шубу сам. Жена оценит.)

Да, это проблема. Все нужные слова для пояснения уже написал в прошлом посте, видимо нужно потратить время на осмысление аналогий.

Не понял я тогда, не понял и сейчас.

Пишу в основном на с++ и иногда вспомогательное гогнецо на питоне.

Вот, по теме! А почему ты иногда вспомогательное гогнецо пишет на питоне? Мне вот это и важно понять. Почему? Быстрее что-ли пишется или что?

В каком месте mercurial провалился? Им очень многие пользуются и многим он удобнее git.
Постоянно использую meld, gajim, deluge, gwsmhg, exaile.

Все относительно, кто-то конечно пользуется, но таки можно без проблем назвать то, что реально «взлетело» из этих категорий софта. А, exaile, например, и я пользовался, но он у меня тупо вис, и я его заменил на quodlibet (тоже кстати на питоне, единственное, что прижилось на нем).

ubuntu-software-center

Загнулся из-за многоличсленных багов и тормозов. Теперь вместо него gnome-software.

Что в этом плохого?

Ничего.

на питоне писать не стоит ничего. говно а не язык.

А насчёт эффективности кодирования - попробуй сам и сделай выводы. Никто не знает твои ментальные способности и склонности.

Нет, нормальная IDE тоже существует достаточно давно, это vim.

что ты лепишь? блокнот для телетайпов 60х годов уже стал IDE - замечательно.

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

Вот недавно кейс был, хэш функции в плюсах должны возвращать значение размером указателя платформы. И надо снять хэш со структуры содержащей два 32битных числа, притом отличное распределение получается как раз, если эти два числа упаковать в одно 64битное, но в плюсах - сей подход не заработает на x86 и прочих 32битных платформах.

Оху-ная история из разряда «я у мамы великий оптимизатор». Ты хоть бенчмарки прогнал, или так, на глаз решил? max_load_factor и reserve используешь? И еще расскажи как питону, его не привязанность к платформе, помогла не тормозить, и насколько ж он С++ обогнал.

И задумываться в случае питон просто не придётся

В случае питона задумываться надо не меньше, чтоб писать сколько-нибудь не тормозящий код.

Тред про продуктивность. А история как раз про оптимизацию скорее по времени разработки чем в рантайме.

Согласен. Но речь про скорость разработки, а, если твоё по состоит больше чем на 50% из i/o, то задумываться придётся скорее об оптимизации этой части чем о чём то жрущем такты процессора, а это более высокоуровневая тема и думать о ней придётся вне зависимости от языка.

Иногда прототипирую на плюсах, собственно, моя солянка

c++ интерпретатор: cling

пакетный менеджер для плюсов: conan

Собственно, еще нужна compile-time рефлексия и многопоточная система событий на подобии google breadboard(правда сабж однопотоковый, ну да ладно), одно уже написано, другое - в процессе.

Еще не хватает интеграции cling в какой нибудь редактор типо vs code/sublime, может, когда-нибудь, сам даже напишу плагин для него.

Системы сборки: на одной работе и для себя - божий qbs, на другой работе - убогий cmake.

В целом, если судить по скорости написания, то пишется на плюсах где-то на 30% медленнее, чем на питоне (естественно, третьи зависимости могу использовать какие душе угодно, лишь бы лицензия позволяла) (на питончике я писал в основном комп. зрение и нейронные сети (numpy, ocv, tensorflow), в плюсах вышло, что теперь пишу графику (osg, OpenVR, OculusSDK, VRWorks, OGL 4.3+ (тут либ много, не буду писать), зрение (тот-же ocv), нейросетки и вычисления(eigen, плюсовый биндинг tensorflow) и потоки (libcds, tbb, mpi), в присыпку часто идут бусты и Qt5). Питончик хорош тогда, когда весь твой код останется на питончике, мои же все наработки в итоге приходилось на плюсы и переписывать, что невероятно приятно на самом деле.

При чём тут пользователь и его боги?

При том, что пользователю (скорее всего без навыков программирования) приходится читать трейсбеки.

Обсуждался банальный факт - падение с понятной диагностикой - «приемлемо»
понятной

С чего вы взяли, что пользователю понятны ваши трейсбеки?

Ты когда-то обращался в поддержку с софтовой проблемой?

Да. Но обращаться туда на каждый чих — это и потеря времени, да и вовсе, качественный продукт не нуждается в ежесекундной поддержке, но это недополученная прибыль разработчиком, да.

По моему опыту общения с таковыми, понятный трейсбек рулит нецензурно.

По моему опыту использования ПО грамотно составленное сообщение об ошибке, будь то диалоговое окно, поток ошибок в терминале запуска или какой специальный лог, гораздо удобнее для пользователя, чем какой-то трейсбек. Просто потому, что пользователь получив грамотное сообщение, может проанализировать свои действия, придти к выводу, что он допустил ошибку или во входных данных какая-то ошибка (то есть не в ПО), всё поправить и работать дальше. А в этих ваших трейсбеках никому ковырять не интересно, пользователю задачу решать надо, если он видит трейсбек, то скорее всего сразу напишет в саппорт. Хотя для разработчиков такой подход даже выгоден, чтобы пользователь без платного саппорта не мог работать нормально с программой.

К тому же, у него есть безусловно полезный побочный эффект - обучение конечных пользователей:).

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

Это не помогает.

Как знать, вдруг(если вы разработчик ПО), вы начнёте с уважением и заботой относиться к тем для кого вы пишете этого ПО и решать в первую очередь _их_ задачи, а не свои.

языки на вроде Python позволяют работать программисту более продуктивно

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