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

И даже в обе одним выстрелом :-(

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

На пайтоне кода меньше, разрабатывать намного проще.

Так, а за счет чего его меньше? Ну вот делаю я гипотетическую функцию:

auto f()
{
  auto result1 = action1();
  auto result2 = action2();
  return std::make_tuple(result1, result2);
}

И что же, аналог на Python будет короче?

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

Каким образом, например?

Кодер, хорошо знающий плюсы и питон, сам решит не чём писать прикинув все за и против. Кодера, знающего только питон, к плюсам подпускать нельзя на пушечный выстрел :) Либо только после изучения всей цепочки «железо-коды-асм-си-...» :)

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

Ну в мире C++ сегодня есть CMake. Кроме того, есть IDE с поддержкой CMake, где от программиста всего лишь требуется добавлять ссылки на исходные файлы в CMakeLists. А по поводу скорости сборки, то небольшие проекты собираются за 1-2-3 секунды, да и то, если сборка с нуля.

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

Ну и в IDE для C++ можно делать тоже самое. Запустить тест одной кнопкой и тестить.

Дата регистрации: 18.10.2017 11:04:57

Просто его выписали, и он пришел домой и включил компьютер. И создал эту тему. Вот почему его так долго не было - лечили.

Кодер, хорошо знающий плюсы и питон, сам решит не чём писать прикинув все за и против.

Так вот очень интересуют именно такие прикиды. То есть холодный расчёт сегодняшних опытных кодеров, знающих C++ и Python, когда они предпочитают второй первому.

Либы в питоне ставить легче. Все либы имеют унифицированную работу с памятью. Нет такой сложной обвязки для сборки большого проекта, как в C++. Портирование под другую платформу, частенько, есть лишь перезапуск кода. В крестах надо его пересобрать для начала (что уже может быть квестом не на один день если проект не тривиальный и требуется какой-нибудь Windows XP SP3, а в проект уже втащили C++11).

Вот есть у меня задача, которая отлично показывает разницу, правда речь не сколько о скриптота vs компилируемость (тут понятное дело скриптота выигрывает за счёт скорости цикла написал->запустил->проверил), сколько разницу статическая vs динамическая типизация.

А именно - фреймворк для мокапов (типа gmock). Можешь сравнить обьём кода, с любыми решениями на питоне, разница настолько показательна, что даже сомнительностью такого метода оценки как величина кодовой базы, можно пренебречь.

Или например сравни flask и crow.

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

def f():
  return action1(), action2()

Намного меньше. :)

На таких сферических примерах да, разница будет неочевидной. А в реальном проекте у нас будет здоровенная стандартная библиотека Питона на все случаи жизни и биндинги ко всему на свете, которые легко подключаются и которыми удобно пользоваться, с одной стороны; с другой стороны, у нас наркоманская STL, в которой ни шиша нет для создания полноценных прикладных приложений, зато есть очень важные и необходимые вещи вроде std::variant или std::optional, упоротый boost, в котором вообще никто нормально не разбирается, кроме его авторов, а всё остальное ищется самостоятельно по всяким узкоспециализированным библиотекам с просторов сети, которые в половине случаев себя скромно характеризуют как C/C++-library, то есть никаких smartpointer-ов, move semantics и прочих плюсовых ништяков из 10-х, только C-style-API, только хардкор!

Мешает то, что надо делать много ручной работы. И отладку проводить отдельным инструментом. Шаг влево, шаг вправо - сегфолт. В отличие от питона

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

Здесь понятно. Теперь упростим, ограничившись одной платформой. Будем рассматривать лишь Linux.

Ну в мире C++ сегодня есть CMake.

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

сколько разницу статическая vs динамическая типизация

Получается, на первое место в качестве барьера, мешающего продуктивности работы с C++, ты ставишь его систему типов. Это интересная мысль.

Это не вдаваясь в плюшки типа первоклассных функций на уровне языка

А как первоклассные функции влияют на продуктивность разработки?

и изкоробочной арифметике больших чисел.

Ну в C++ есть же библиотеки для этого?

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

Для определенного круга задач - безусловно. Ты же не будешь спорить с тем, что шелл-скрипты писать на bash быстрее и легче, чем на C++? Тут дело в приоритетах, которые ставят перед собой авторы языков. У авторов С++ главным приоритетом всегда была эффективность использования вычислительных ресурсов железа. Отсюда растёт его небезопасность (возможность выстрелить себе в ногу, которой авторы языка никогда не лишают программиста), кривизна STL, громоздкость API библиотек и т.п. У Питона же в приоритете изначально именно скорость разработки, а эффективность использования вычислительных ресурсов в списке приоритетов стоит ближе к концу. Отсюда и лаконичность, и динамическая типизация, и отсутствие необходимости в компиляции с компоновкой.

Мне же хочется четкого понимания. Может быть это миф?

Конечно...

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

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

Сегодня есть уже более-менее нормальные IDE для C++. Так?

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

Так что же тогда мешает писать на C++ столь же продуктивно, как на том же Python?

Инфраструктура. В питоне уже почти всё есть из коробки, в плюсах же её нужно собирать для каждого проекта - это и система сборки, и дополнительные стандартные библиотеки (в плюсах не ждут когда что-то завезут в std::, если чего-то нет, то пишут сами), и многое другое.

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

напишите ОС на питоне, для rpi. Некоторые задачи нужно решать С++ некоторые МОЖНО решать на Питоне, причем здесь скорость ?

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

Почему? Проекты собираются, IDE его поддерживают. Язык не нравится? Ну он примитивный. А наворотов там и не надо.

Можно вообще в REPL писать в каком-нить ipython. Даже ничего запускать не надо.

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

А в реальном проекте у нас будет здоровенная стандартная библиотека Питона на все случаи жизни

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

И отладку проводить отдельным инструментом.

Почему отдельным? В C++ IDE и проводить отладку.

Получается, на первое место в качестве барьера, мешающего продуктивности работы с C++, ты ставишь его систему типов

Не совсем так, просто сравниваются языки с разными доменами для использования. На питоне нельзя написать всё что можно написать на плюсах. Так же как и на чистых плюсах сложно/невозможно написать то, что на питоне делается легко. И на это как раз разница в системах типов оказывает наибольшее влияние.

Ну в C++ есть же библиотеки для этого?

Вроде бы и есть. Но их надо найти, изучить, сравнить, выбрать. А в питоне нужно просто написать c = a * b.

А как первоклассные функции влияют на продуктивность разработки?

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

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

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

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

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

Я не считаю, что vim - это IDE. Vim - это бесплатный настраиваемый редактор. IDE - это готовое решение, зачастую платное. Плата за профессиональную настройку, встроенный парсер языка для нормальной навигации, встроенную интеграцию с gdb и другими инструментами считаю более чем обоснованной.

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

А что касаемо продуктивности?

python и другие подобные, типа php и JS - хороши либо для несложных скриптов или для ваншотных проектов. исправлять баги в таком коде - крайне сложно и проще всё переписывать с нуля.

Язык не нравится? Ну он примитивный. А наворотов там и не надо.

Язык ужасный. Он не примитивный и когда сложный cmake делает что-то не то - очень сложно искать ошибку.

Ещё одно

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

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

Тогда батарейки. На питоне цикл использования библиотеки ограничивается прочтением ее API беглым и можно уже что-то писать. На крестах надо читать API очень аккуратно + придумать, как согласовывать его с моделью управления памятью, что используется в основном коде (бывают конфликты и проблемы).

Кстати вот ещё момент, вроде явно его не назвали.

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

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

Ну вот возьмем пример. Многопользовательская браузерная игра змейка, на вебсокетах. https://dpaste.de/aMdq архив вместе с html/js http://rgho.st/8PNTcnnJk

Я её наговнокодил где-то за полчаса-час. В зависимостях tornado.

Или вот клиент для faceapp с примитивной gtk мордой https://dpaste.de/VSAm тоже полчаса на коленке - и то, в основном формочка. Сам код запроса пишется и тестируется в repl за минуту.

За сколько времени ты её напишешь на плюсах?

Не совсем так, просто сравниваются языки с разными доменами для использования.

Ну так а какие домены для использования C++ и Python? Насколько я знаю, C++ всегда позиционировался как «язык общего назначения с уклоном в сторону системного программирования».

Вроде бы и есть. Но их надо найти, изучить, сравнить, выбрать.

Согласен. Т.е. опять довод в пользу стандартной библиотеки.

вот с поддержкой и оптимизацией, так однозначно сказать сложно.

Почему?

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

В тех проектах, для которых вообще имеет смысл сравнивать питон и плюсы - да, это важный аргумент.

python и другие подобные, типа php и JS - хороши либо для несложных скриптов или для ваншотных проектов. исправлять баги в таком коде - крайне сложно и проще всё переписывать с нуля.

Не думаю, что исправлять баги в Python/PHP сложнее, чем в C++. Насчёт JS - может быть, кстати.

Язык не нравится? Ну он примитивный. А наворотов там и не надо.

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

и когда сложный cmake делает что-то не то - очень сложно искать ошибку

А что CMake может сделать не то, что очень сложно понять?

что такое тесты?

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

Будто ты пишешь код сразу под все платформы.

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

Ну это же к продуктивности работы с языком имеет посредственное отношение.

вот с поддержкой и оптимизацией, так однозначно сказать сложно

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

Ну так а какие домены для использования C++ и Python?

Ты не напишешь на питоне ПО делающее что-то полезное за <=20-40мкс быстрого i/o. Ну точнее напишешь, но оно будет на порядки не эффективнее решения на плюсах, без возможности оптимизировать его не переписав 90% процентов кода на те же плюсы или си. Фактически любые динамичные игрушки, лоулэйтенси, а так же всё, что не масштабируется горизонтально идёт лесом в лучшем случае в перспективе развития проекта.

Ну на питоне же пишешь не запариваясь так.

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

В первую очередь CMake убог тем, что это генератор make файлов, а не полноценная система сборки.

CMake - генератор не только файлов для make, а генератор для разных систем сборки. В этом как раз его сила, а не убожество. Он именно эту задачу и выполняет.

Из-за этого у него ужансые язык, cli и рантайм.

Ну и чем ужасен его язык?

Но ведь пока до «танкистов» не дошло, надежды на инфраструктуру и не было.

Не танкисты же делают инфраструктуру, танкисты это так, шлак. Инфраструктуру делает философия языка и в C/C++ станлартной инфраструктуры в принципе не бывает.

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

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

Я не считаю, что vim - это IDE. Vim - это ... настраиваемый редактор.

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

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

Это примерно как сахаром в плюсах: IDE даёт днищам ложное впечатление «профессионализма» и, как обычно бывает с наркотой, за деньги.

А что касаемо продуктивности?

Это же и есть про продуктивность. В питоне нет проверки типов, излишняя динамичность (объекты точно не должны иметь изменяемое кол-во полей в рантайме), слишком скудные стандартные структуры данных, тормозной как хрен знает что, неэффективен по потреблению памяти, неудобный язык описания объектов (нет нормальных private, protected, интерфейсов, убогий super) - из-за всего этого с ростом кол-ва кода слишком много времени начинает уходить на выискивание опечаток и борьбы с потреблением ресурсов.

Инфраструктуру делает философия языка и в C/C++ станлартной инфраструктуры в принципе не бывает.

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

большего для разработки и не нужно
Это примерно как сахаром в плюсах: IDE даёт днищам ложное впечатление «профессионализма»

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

В питоне нет проверки типов, излишняя динамичность

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

На плюсах лет 15 не писал, поэтому даже интересно стало.
На главной питона(http://www.python.org) есть 5 базовых примеров использования.
Показывай как на современных плюсах они будут выглядеть.

Ты просто не видел cmake на десяток тысяч строк в сумме. С макросами и функциями.

А может быть есть какие-то рецепты по продуктивности работы на C++?

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

Когда говоришь, что что-то ужасно, следует сразу выдать альтернативу, иначе, выглядит как-то голословно.

Не знаю альтернатив. Может scrot или новомодный мезон. Не смотрел на них. Но про ужасный cmake знаю на основе личного опыта в большом проекте.