как я понимаю, основная проблема там в т.н. python way. Лично я вижу для себя два варианта для скриптового языка, вернее три: лютая стабильность как у баш, механизм добавления функционала и избыточность как в перл, либо встраивание опциональной строгой проверки типов как у того же груви, но это сложнее, скрипт уже нужно адаптировать под это и начинаются баги уже в самом механизме проверок, хотя такая помесь компилируемого и динамического языка выглядит интересной. Все варианты позволяют более-менее переносить скрипты на новые версии. Иначе я не представляю, как отследить баги, когда они могут быть в любой ветке кода и выстрелить при рандомных условиях, тесты с тулзами тоже такое себе. Ну или вариант использовать компилируемые языки ди\го как скрипты... но они под скрипты не заточены, будут разные мелочи вроде ";" у ди. Хотя насколько я в курсе, rdmd не ругается на return посередине скрипта и недоступные участки кода.

Ну если речь о стабильности, то согласен.
А что за мелочь вроде ";"?

и зачем проверка типов должна быть опциональной?

За много лет на питоне сталкивался с небольшим числом проблем связанным с нестабильностью. В основном это был переход 2 на 3. Импользую и в скриптах и в приложениях. Основной плюс к стабильности - наличие любых библиотек приличного качества

на питоне куча скриптов уже понаписана, я на руби писал скрипты. Баш - в жопку.

На D скрипты тоже пишу, просто потому что я его помню, а руби нет, а баш - для инопланетян.

python прекрасно переносится на новые версии в пределах мажора

Особенно если не сидеть прям на bleeding edge

Есть же setuptools и requirements.txt

В скриптах ";" меня незначительно, но раздражает. Хотя тоже на вкус и цвет, недавно как-то просили помониторить наличие продукта в одном из инет-магазов, который не мог в уведомления о наличии товара. Подумав, я взял дарт из-за его dart:html, он работал как скрипт и там-таки тоже ";". Что касается ди, то тут есть другие мелочи, например, либы, которые должны в два щелчка подключаться с скрипту без каких-то сложных сборок. проблемы как в самих либах, так и в их подключении, хотя может rdmd более-менее адаптирован к этому, тут не знаю.

>и зачем проверка типов должна быть опциональной?
чтобы выключать её для производительности, dsl и метапрограммирования, например, для динамического добавления методов в базовые типы чисел\строк\etc, которые компилятор никак не может вывести, они могут создаваться очень виртуозно. В случае строгих проверок часть динамических фич отвалятся. Ну, такой пример... полезность его сомнительна, но все таки:

def columnName = "User"
String.metaClass."from$columnName" = { "$delegate from $columnName" }
//компилятор скажет, а схренали тут это?
println "select".fromUser()
//select from User

В принципе да

там Mercurial что-то пытались на новую версию пайтона переводить, наполовину успешно). Есть мнение, что от этого проект и загибается\гнулся.

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

Но гит стандарт дефолт уже :(

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

2->3?

наверное вот это https://www.opennet.ru/opennews/art.shtml?num=52184

Ну в принципе это да, больно
Но приводить как пример этот случай немного некорректно

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

не ошибка, а python way же

это цитата была