У Python'а грамматика намного проще, в отличие от грамматики C++.

Python интерпретируемый язык, не компилируемый (по крайней мере Pyston так и не взлетел). Это сразу развязывает руки в плане
типизации объектов. И кстати, она там утиная (динамическая), а не строгая.

Python создан для программирования, а не для решения технических проблем и постоянной борьбы с инструментом, как этот ваш
C++. То есть, на питоне проще выразить свои идеи в коде, нежели в C++, где нужно сначала описать сценарий сборки на том же CMake,
прилинковать нужные либы, прописать INCLUDEPATH'ы, и ещё не забыть про остальные платформы. В питоне же просто в большинстве
случаев требуется запустить и будет работать везде.

Ну а за интроспекцию типов вообще можно не волноваться в Python'е. Чего не скажешь про C++ с его метапрограммированием и
compile-time вычислениями, когда нужно постоянно помнить где код "выполняется" во время компиляции, а где в рантайме.

Работа с variadic template'ами также здесь далеко не светлая сторона С++, в то время как Python обходится *args и **kwargs на изи.

А вообще, это сравнение тёплого с мягким, так как, у каждого языка своё назначение

Siemarglпросто нет всяких begin/end'ов

Да в плюсах, как бы, тоже нет. Всё достигается отступами, а если нужен RAII делаешь with ...: с объектом, у которог оперегружены __enter__ и __exit__

Siemarglиз обратного - медленнее в 100 раз


Так это смотря что делать. Если тебе нужна числоробилка -- используй NumPy. Тяжёлые части critical path'ов всегда можно вынести в C extension.
Но только когда нужно.

Siemarglи удачно сохранив программу не тем редактором с другим размером табов - навернешь ее безвозвратно


Современные IDE уже давно умеют справляться с такими, даже запортившимися скриптами. Например, в PyCharm, можно нажать шоткат
Ctrl(Cmd)+Shift+F и он сам всё отформатирует.

Siemarglиз второго пункта следствие - особое удовольствие при совместной разработке

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

Siemarglеще "удачно" выполнив pip пакет, можно подтянуть полинтернета всякого говна себе в питоновские каталоги =)

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

AlekseySQLИх грамматика отличается только указанием типа (хотя в С++ теперь можно использовать auto), фигурными скобками и точкой с запятой. Остальное все тоже самое.

Я говорил про грамматику БНФ . Так вот, у C++ она намного сложнее. Не зря были приведены ссылки на грамматики обоих языков.

AlekseySQLВ Python строгая типизация

В питоне нет строгой типизации.

AlekseySQL просто имена объектов в процессе выполнения могут "привязываться" к другим объектам.

Это одно из преимуществ утиной типизации.

AlekseySQLВ современных IDE (анализирующих только измененные файлы) компиляция С++ программ

IDE не компилируют программы.

AlekseySQLзанимает пару секунд.

Ага, то-то я и смотрю, что чтобы собрать, скажем, фреймворк Qt, требуется (примерно) 40 минут.
Компиляция каждого C++ файла занимает время, а затем ещё и линковка, которая тоже немало времени берёт.
Современные продукты собираются долго, особенно, если кто-то поменял какой-нибудь хедер, который много где используется.

AlekseySQLНикаких сценариев сборки в С++ никто не пишет. Это все делает IDE.

В кроссплатформенной цепочке сборки с использованием известных CI, скажем, Jenkins, сценарий сборки необходим чтобы сгенерить Makefile
для Linux, Xcode проект для мака и Visual Studio проект для винды. Не нужны, говоришь?

AlekseySQLОба пункта настолько редко используются, что представляют исключительно академический интерес.
Чувак, ты точно профессиональный C++ программист, или просто толсто троллить пытаешься?
Для Hello world'а не нужны, а на практике приходится прибегать к ним.

AlekseySQL"Форма Бэкуса — Наура - формальная система описания синтаксиса, в которой одни синтаксические категории последовательно определяются через другие категории."
В С++ одни синтаксические конструкции НЕ определяются через другие, исключение составляют классы и структуры (точно также присутствующие в Python), которые представляют совокупность полей и методов. Все остальное находится на одном уровне.

То есть ты не понял, что имелся в виду синтаксис формы БНФ, а не целевого описываемого языка.

AlekseySQLВ Python строгая типизация, это знает любой грамотный программист.

Можешь привести ссылку где это утверждается? У Python'а отродясь не было строгой типизации. Во всех учебниках по Python'у описывается утиная
(динамическая) типизация. Тянет на очень жирный троллинг, либо синдром Дедала с его FVMas.

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

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

AlekseySQLЧто за детские придирки к словам? IDE в настройках хранит путь к компилятору и по нажатию кнопочки его вызывает. Так пойдет?

Это не придирки, это твоё непонимание что такое IDE. IDE -- вещь опциональная. Ею можно и не пользоваться, отдав предпочтение Makefile'ам.
Тот же Eclipse умеет создавать проекты на основе Makefile'ов, при учёте, что синтаксис Makefile является полным по Тьюрингу.
IDE лишь один из инструментов, которым можно собрать C++ проект. Под виндой, например, ты можешь в консоли вызвать msbuild для сборки
студийного проекта. На маке xcodebuild. Заметь, IDE в этом процессе, по факту не участвует. Проект IDE является сценарием сборки для перечисленных
консольных утилит. И именно так и собираются пакеты в современном продакшне, без ручной сборки через IDE, а через вызовы скриптов сборки,
которые уже вызывают эти самые команды. В большинстве случаев это

AlekseySQLРазговор был о скорости разработки своих пакетов, компиляция при которой занимает секунды.

Как обычно, всё зависит от обстоятельств.

AlekseySQLК тому же сборки чужих пакетов распрастраняются уже в бинарниках и только для редких платформ их надо собирать самостоятельно.

Питоновые тоже. У pip'а нет ограничений ставить питоновые скрипты в пакетах, или уже готовые бинарные модули .so/.pyd.

AlekseySQLКстати, если на С++ что-то собирается 40 минут, то на Python это будет РАБОТАТЬ 100 * 40 минут.

Очередная клюква от незнакомого с Python'ом.

AlekseySQLВ топике поставлен вопрос выразительности разработки на Python, а не его возможности для применения как интегратор различных компонентов. Зачем подменять понятия?

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

AlekseySQL"Hello world" правильно пишется так: "Hello, world".
AlekseySQLЧто за детские придирки к словам?

В общем, слив.

AlekseySQLсинтаксис С++ ничем не сложнее синтаксиса Python

Ноу комментс

AlekseySQLВ этом курсе автор рассказывает, что объект и его имя- раздельные сущности. Когда происходит конвертация данных, то старый объект удаляется, новый создается, а имя старого объекта "переподвязывается" к новому объекту.

Почитай что такое Reference counting. Объекты однозначно индентифицируются по id (built-in функция id). Привязанные имена являются ссылками
на объект.

AlekseySQLВсе объекты имеют тип, который строго определен. Утиная типизация (все что крякает, летает и плавает- будем называть уткой) не имеет ничего общего с динамической. Это разные понятия. Утиная типизация отталкивается не от свойств объекта, а от тех возможностей, которые у него есть.

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

AlekseySQLХотели сделать читаемый язык, а сделали нечитаемый.

Субъективное мнение ниасилившего.

AlekseySQLКстати, если на С++ что-то собирается 40 минут, то на Python это будет РАБОТАТЬ 100 * 40 минут.

AlekseySQLЯ написал "на Python", а не на С / С++.

Сам себе противоречишь?

AlekseySQLЭто у вас непонимание как происходит работа всего комплекса.
7+ лет опыта разработки C/C++ экстеншнов для CPython под Linux, macOS, Windows для индустрии VFX для Python-скриптинга в разных C++-хостах.
Не надо мне говорить, что я не понимаю как оно работает под капотом.

Перестать уже сравнивать тёплое с мягким, это смотрится непрофессионально, как и рассуждения Дедала о "дырявом C++" и "кишке танка".

SiemarglСказки не рассказывай только. Неоднострочные блоки он не восстановит.
Да и я говорил про "не тот редактор" (вроде ноутпада, mc-edit итп), а не про несуперзаточенное чудо.

mcedit... Ну да, ну да, наверное не стоит пейсать код в mcedit'е и коммитить сразу в продакшн.

SiemarglНаверное ты этим (костыли пишешь) занимаешься, потому что иначе работает непростительно паршиво =)

Это нужно для пользовательского скриптинга. Как например тот же VBA в MS Office, или JS в OpenOffice. Так и тут, но в VFX инструментах, Python
является стандартом для скриптинга и построения пайпланов для пост-процессинга рендеринга видео, как и низкоуровневой работы с пиксельными
данными.

SiemarglМое мнение - хороший учебный язык

Согласен.

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

Тренды показывают обратное. Мало того, что у него огромное коммьюнити, так ещё и крупные корпорации активно контрибьютят в него.

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

SiemarglНо я бы после Питона посмотрел на D - там есть все это (правда и овердофига больше и есть сложные концепции), и скорость С.

Зачем, когда есть православный Go?

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

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

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

Тему можно переносить в ПТ, если только кто-нибудь не нашёл способ сломать питона.

Модератор: Зачем... Можно просто закрыть топик. Только вот, сама тема "уловить причину выразительности" так и осталось не вполне понятной. А жаль. Думается, в причинах что-то должно быть общее с улыбкой Джоконды.

AlekseySQLКороче, выразительность Pythona- миф. Например, вот как выглядит первый попавшийся код из SciPy Cookbook :




Этот код нечитаем. Код должен читаться как обычная книга, и тогда он легко воспринимается (спасибо, Боб Мартин!). Тут же мы видим кашу из инструкций, которую надо при повторном использовании ВСЮ перечитывать и в голове воссоздавать идею работы программы.

Вот тебе такой же код на плюсах



ИМХО, любой вычислительный научный код выглядит везде одинаково плохо. Но в C++ пришлось написать гораздо больше, но выразительности это,
скорее, убавило.

AlekseySQL
Это не на плюсах, а на С. На плюсах код изначально мыслится объектами со своими свойствами и методами.
Где ты в C видел ключевые слова "auto" и "using namespace"
Как видишь, на C++ тоже можно писать в процедурном стиле. Так же как и на питоне. Это вопрос к авторам этой библиотеки, а не к самому языку.
Так шта...(С)