Отмер справедливости кажется чуток ровнее, когда ты удовлетворен. И чуток не ровнее, когда ты чем либо недоволен. При том довольство или недовольство - штука эмоциональная и не обязательно связана с работой. Так что между марксистами и анти-марксистами в этом вопросе есть еще история про то "понимает ли человек с какой стороны у него болит". Думаю что плюсы и минусы ориентированы примерно по этому принципу.
В целом опыт C/C++ команд показывает что скорость разработки бинарика умелой командой вообще ничем не отличается от скорости разработки командой под интерпретаторы. При условии того, что команда уже есть.
Отличие тут только одно - скорость найма разработчиков.
ИМХО поиск оптимальности здесь на уровне следующих требований: инструментарий в любом случае должна разрабатывать имеющаяся команда погруженная в остальное окружение. Не так важно "где именно имеющаяся" - внутри компании или на рынке, главное это погруженность в текущие потребности.
Что можно сказать именно о Python - со то стороны заказчика этот язык я вижу как боль по следующей основной причине: достаточно специалистов, которые о нем говорят, мало тех, кто может отлаживать код написанный на нем быстро и эффективно. А с инструментарием потом нужно будет жить и его чинить.
Из побочных проблем языка - они точно такие же как у Golang и ruby, преимуществ с точки зрения разработки инструментов практически никаких: что у go, что у python, что у ruby. Последний давал плюсы в районе 2015-2016 годов, но сейчас ими обзавелись и другие языки. Главный минус всех интерпретаторов в плане работы с инструментарием - низкий уровень интеграции с ОС, как итог невозможность или сложность реализации части функционала.
Выводы к которым я пришел при разработке инструментов - когда команда C/C++ готова делать инструменты - это бесспорный выбор в их пользу. Когда не готова - не так важно на чем прототипировать: python, golang, ruby, десяток инструментов на PHP - в любом случае проблемы будут близкие (на php конечно их будет больше количественно :-) ).
Согласен. Это какая-то вечная тема. Особенно радуешься, когда находишь Inotify в первый раз
Конечно может. Разработчик у себя локально может просто случайно оторвать pre‑commit и локальная проверка вообще не выполнится.
Отмер справедливости кажется чуток ровнее, когда ты удовлетворен. И чуток не ровнее, когда ты чем либо недоволен. При том довольство или недовольство - штука эмоциональная и не обязательно связана с работой. Так что между марксистами и анти-марксистами в этом вопросе есть еще история про то "понимает ли человек с какой стороны у него болит". Думаю что плюсы и минусы ориентированы примерно по этому принципу.
Вы представляете себе схему с 1000 узлов? Я бы не стал её рисовать ибо это издевательство над читателем - её смотреть.
В целом опыт C/C++ команд показывает что скорость разработки бинарика умелой командой вообще ничем не отличается от скорости разработки командой под интерпретаторы. При условии того, что команда уже есть.
Отличие тут только одно - скорость найма разработчиков.
ИМХО поиск оптимальности здесь на уровне следующих требований: инструментарий в любом случае должна разрабатывать имеющаяся команда погруженная в остальное окружение. Не так важно "где именно имеющаяся" - внутри компании или на рынке, главное это погруженность в текущие потребности.
Что можно сказать именно о Python - со то стороны заказчика этот язык я вижу как боль по следующей основной причине: достаточно специалистов, которые о нем говорят, мало тех, кто может отлаживать код написанный на нем быстро и эффективно. А с инструментарием потом нужно будет жить и его чинить.
Из побочных проблем языка - они точно такие же как у Golang и ruby, преимуществ с точки зрения разработки инструментов практически никаких: что у go, что у python, что у ruby. Последний давал плюсы в районе 2015-2016 годов, но сейчас ими обзавелись и другие языки. Главный минус всех интерпретаторов в плане работы с инструментарием - низкий уровень интеграции с ОС, как итог невозможность или сложность реализации части функционала.
Выводы к которым я пришел при разработке инструментов - когда команда C/C++ готова делать инструменты - это бесспорный выбор в их пользу. Когда не готова - не так важно на чем прототипировать: python, golang, ruby, десяток инструментов на PHP - в любом случае проблемы будут близкие (на php конечно их будет больше количественно :-) ).