Ок. Всё просто. Пример со стормом:
Есть WebStorm, который подойдёт для тех вещей, которые вы описали чуть выше, более чем. PhpStorm идёт с удобной работой с xdebug, phpunit, symfony, laravel, навигацией по классам, выбора различных версий интерпретатора для разных профилей тестов и ещё приличным количеством вещей, которые для разработки не на PHP вообще не нужны — это то, что я называю заточкой среды разработки под язык программирования. Брать PhpStorm не для работы с PHP — не вижу смысла впринципе ни по цене, ни по функциональности. Стоимость первого — $100, а второго $200.
Таким образом заточенной средой разработки под язык программирования можно назвать ту среду, основная задача которой упрощать работу с конкретным языком и его окружением.
Просто если вы не согласны с тем, что «Шторм только для PHP», в первую очередь уточните какой именно из вышеперечисленных стормов. А то получается, что мы можем говорить про разные вещи.
Большая часть IDE которые я знаю и использовал работают по той же схеме — основа + плагин. Спорить не буду, просто расскажите, пожалуйста, что же такое «заточка» в вашем понимании?
Для IDE веб-разработка на PHP не исключает работы с тем, что вы перечислили, но требует специфичной заточки под него. И, заметьте, я не писал «только» :)
Ну давайте всё же разделять язык программирования и среду для работы с ним, с языком разметки. Языки разметки, которые вы перечислили, успешно можно редактировать и в Java специфичных IDE, .NET и т.д. SQL так же достаточно универсальный язык запросов, который в том или ином виде поддерживается разными СУБД, а так же используется другими языками программирования.
Опять-таки надо разделять время на создание проекта и его дальнейшую поддержку. Часто решения «в лоб» по скорости разработки с нуля не сильно уступают некоторым подходам, которые вы описали. Зато на этапе поддержки (изменения функциональности) это может вылится в дикие трудозатраты и бессоные ночи(не всегда, но зачастую).
Комментарий про DEVConf скорее говорит про то, что иногда проще «по-древнему» запилить прототип, а если уже «выстрелит», то сделать по уму, чем потратить больше времени на то, что может просто не пригодиться в дальнейшем.
WebStorm — не специфичен, а вот PhpStorm всё же чётко заточен под веб-разработку на PHP, а не на питоне, например.
Я бы ещё добавил, что пишут и могут писать — разные вещи. Практически для всех задач, которые мне приходится решать (в т.ч. и консольные приложения не для веба), php подходит отлично, чем я и пользуюсь. Но это не значит, что я не умею писать на других языках и не умею пользоваться другими IDE.
Такая проблема чаще всего возникает из-за того, что разработчики сосредоточены на «красоте» проекта. Код ради кода, а не ради бизнеса. Насколько я понимаю, то «мамонт» в посте — это опытный разработчик, который не использует новые инструменты. Думаю, что у опытного разработчика, который использует эти инструменты и подходы, время на выполнение проекта не сильно увеличится. Я бы даже сказал, что многие инструменты больше помогают в дальнейшей поддержке проекта. Проблемы будут лишь у тех, кто про эти вещи узнал, но не правильно их применил. Так что эта история больше относится к людям, принимающим неоправданные решения с точки зрения бизнеса (обычно это лиды и ПМы).
«Неважно какой фреймворк вы используете, простейший механизм миграций в состоянии написать даже Junior за пару часов.»
1. Если мы говорим про изменение схемы — migrate down работает прекрасно. Но как только дело касается изменения данных — даже доктрина(как пример написанный не джуниором) бессильна сделать адекватный лог изменений. Приведу пример — у вас поле-флаг где часть записей имеют значение 0, а остальные 1. Миграция заменила все 0 в 1 запросом «UPDATE table SET flag=1». Как предлагаете реализовать откат? Без бэкапа перед деплоем не обойтись. А вот вопрос — не будет ли реализация migrate down избыточной при сохранения бэкапа?
2. Я прекрасно понимаю, зачем класть тех же вендоров в гит, но не могу придумать, зачем класть свои локальные настройки в гит?
3. В целом я согласен, что исползьование composer'а вне контекста фреймворка частенько сильно экономит время. Но это касается людей которые смотрят на фреймворки чуть глубже, чем на их документацию и примеры из stackoverflow.
Ага, я тоже это заметил, когда первый раз их посмотрел. Теперь когда смотрю канобувости — всегда вспоминаю «Привет, с вами Бонус и Гамовер» и тот дирижабль :)
php.net/manual/ru/class.splenum.php
Есть WebStorm, который подойдёт для тех вещей, которые вы описали чуть выше, более чем. PhpStorm идёт с удобной работой с xdebug, phpunit, symfony, laravel, навигацией по классам, выбора различных версий интерпретатора для разных профилей тестов и ещё приличным количеством вещей, которые для разработки не на PHP вообще не нужны — это то, что я называю заточкой среды разработки под язык программирования. Брать PhpStorm не для работы с PHP — не вижу смысла впринципе ни по цене, ни по функциональности. Стоимость первого — $100, а второго $200.
Таким образом заточенной средой разработки под язык программирования можно назвать ту среду, основная задача которой упрощать работу с конкретным языком и его окружением.
Просто если вы не согласны с тем, что «Шторм только для PHP», в первую очередь уточните какой именно из вышеперечисленных стормов. А то получается, что мы можем говорить про разные вещи.
Комментарий про DEVConf скорее говорит про то, что иногда проще «по-древнему» запилить прототип, а если уже «выстрелит», то сделать по уму, чем потратить больше времени на то, что может просто не пригодиться в дальнейшем.
Я бы ещё добавил, что пишут и могут писать — разные вещи. Практически для всех задач, которые мне приходится решать (в т.ч. и консольные приложения не для веба), php подходит отлично, чем я и пользуюсь. Но это не значит, что я не умею писать на других языках и не умею пользоваться другими IDE.
1. Если мы говорим про изменение схемы — migrate down работает прекрасно. Но как только дело касается изменения данных — даже доктрина(как пример написанный не джуниором) бессильна сделать адекватный лог изменений. Приведу пример — у вас поле-флаг где часть записей имеют значение 0, а остальные 1. Миграция заменила все 0 в 1 запросом «UPDATE table SET flag=1». Как предлагаете реализовать откат? Без бэкапа перед деплоем не обойтись. А вот вопрос — не будет ли реализация migrate down избыточной при сохранения бэкапа?
2. Я прекрасно понимаю, зачем класть тех же вендоров в гит, но не могу придумать, зачем класть свои локальные настройки в гит?
3. В целом я согласен, что исползьование composer'а вне контекста фреймворка частенько сильно экономит время. Но это касается людей которые смотрят на фреймворки чуть глубже, чем на их документацию и примеры из stackoverflow.