Это перевод статьи Ruby (on Rails) ecosystem bittersweet or "we like to hate PHP", написанной 30 мая 2016, т.е. совсем недавно. Я полностью согласен с её автором, и сам давно горел желанием написать что-то подобное в последнее время, но у меня не так много опыта с Ruby, поэтому моя писанина не была бы настолько объективна, как писанина человека, который этот опыт имеет, и имеет его в хорошем количестве. А тут на тебе: всё в одном месте уже собрано, и мысли прямо один в один как у меня. Грех не перевести на русский. Также, статья вообще очень хороша как небольшой набор объективного и беспристрастного анализа двух языков современной веб-разработки. В общем, далее — перевод слов автора.


многобукв; нечитал;
В этой статье я рассказываю о некоторых фактах и персональном опыте для того чтобы доказать, что PHP в данный момент живее, конкурентоспособнее, а также имеет менее связанную экосистему, чем Ruby. Я говорю о Производительности, Синтаксисе и Аспектах кодинга, Сообществе и Инструментарии разработчика.

Если у вас есть желание пропустить воду — проскрольте до заголовка "Основная часть начинается здесь..." :) Но мне нужно это сказать...


Что? Очередная анти-RoR проповедь?


Ну да, я начал собирать материал для этого поста больше шести месяцев назад, и я знаю о всех дискуссиях, которые ведутся на тему "за" и "против" RoR в последние недели. Основные обсуждаемые нынче статьи — это Моё время с Rails закончилось и Rails выйграл: Слон в Комнате. Я определённо не настолько опытен в RoR, чтобы сказать что-нибудь новое на тему архитектуры, что ещё не сказал кто-то другой. Я только хочу поспорить за лидерство Rails в веб-разработке.


[PHP]… фрагментированные, независимые и изолированные сообщества… Это один большой океан разрозненных островов.

Сказал как-то AkitaOnRails, и всё это правда с одной стороны, и ложь — с другой. Дорогие рубисты, позвольте мне продемонстрировать вам вашего ближайшего конкурента: PHP. И не существует чего-то особенного в Ruby для типичного Basecamp приложения, чего мы не можем найти в PHP.


Эволюция моего видения...


Я пришёл в мир Ruby только около полутора лет назад, после более пяти лет разработки на PHP. Я испытывал много мучений. Это не лёгкая миграция и адаптация. Жизнь сложилась так, что я решил с нуля создать команду разработчиков Ruby (on Rails) в MobiDev. С того момента я замешан в самообучении и ускорении развития своих Ruby джуниоров и миддлов.


Очень скоро я понял одну вещь: все эти хипстерские и cool-kids образы из мира RoR были немного преувеличены. Сегодня, RoR не предлагает ничего особенно более лучшего, чем любой средний PHP фреймворк, разве что за исключением фоновых задач из коробки.


Что ещё хуже: он стимулирует некоторые подходы к разработке, которые "считаются вредными" © даже в PHP. Тут поощряются нарушение принципа единственной обязанности и CQRS прямо самим фреймворком. И, если честно, большое RoR приложение является тотальной магией из-за вездесущих манки-патчей неявного включения во всё подряд.


Просто подумайте об одном примере нарушения принципа единственной обязанности...


image


"Разве мы не перестали работать с PHP по этой причине?"


Прости Ник, я цитирую твою книгу, и не согласен с данным утверждением. Я вижу, что огромное количество Ruby разработчиков любят пошпынять PHP. Большинство из них не видели ни одной строки реального PHP кода, но "мой друг сказал мне… что это кошмар". Или они видели WordPress — самый популярный и самый уродливый с точки зрения архитектуры PHP код, который когда-либо был написан.


Я хочу заявить о том, что это некорректное мышление для 2016 года, и PHP сообщество имеет множество таких вещей, которые отсутствуют в сообществе Ruby на данный момент.


Piotr Solnica
В мире Ruby фреймворк следующего поколения никогда не появится... http://disq.us/9qybwk

И, простите, но перед тем как перейти непосредственно к PHP, я должен оставить здесь два риторических для Ruby параграфа...


Это как домашнее насилие


Когда я думаю о Rails и о реакции большинства рубистов на предложение "думать вне RoR", это напоминает мне поток сознания жертвы бытового насилия. И что-то вроде Стокгольмского Синдрома зависимых от RoR.


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


Они поженились и переехали в его замок. И её жизнь немного изменилась...


После множества прожитых совместно лет, она уже не может сделать и шага без Его разрешения, Он даже мог побить её, когда она пыталась. Она должна докладывать о каждом своём шаге и подстраивать всё под Его течение жизни. Она уже давно забыла о том, как можно жить без его чрезмерной опеки и помощи со стороны слуг. Все люди, которых она знает и с которыми она общается — такие же жёны домашних тиранов. И всё чаще и чаще она слышала от её "очарования": "Даже не думай оставить меня! Никто не нуждается в тебе, кроме меня! Ты не можешь ничего сделать в одиночку!"...


Замкнутый круг спроса


Ответ: ничего. Нет ничего запрограммированного в Ruby для того чтобы остановить тебя при использовании своих острых ножей для того, чтобы разорвать отношения с разумом. Мы претворяем в жизнь такие хорошие соглашения путём подталкивания и через обучение. Не через запрет острых ножей и не через призывы использовать ложки для нарезания помидоров.
DHH, "Provide sharp knives"

Образование. Rails действительно учат нас?


Разработчики начинают использовать Rails. Обучаются только рельсам. Не могут сделать шага без них. Не могут отличить, что является чистым Ruby, а что является рельсовым манки-патчем. Они не видят чего-то лучше этого, да и не хотят ничего лучше. Не могут сделать даже крошечный SQL запрос без ActiveRecord. Производительность? Кто об этом заботится? Клиенты попадают на Rails-маркетинг и "широкое сообщество разработчиков". Они требуют, чтобы проекты писались на Rails. Разработчики используют Rails потому что это так легко (не просто!), ну и Клиенты же хотят Rails (спрос рождает предложение).


Когда вы подумаете о том, куда пойти после Rails — вы поймёте, что идти, в общем-то, некуда. Клиенты не желают писать не-Rails приложения, потому что они "скорее всего не нашли бы не-Rails разработчиков". То же самое с разработчиками: они боятся оставить Rails, потому что "они не смогут найти не-Rails работу". Порочный круг. И уже нет разницы, "предложение рождает спрос", или же наоборот.


Такой проблемы не существует в мире PHP. Клиенты почти никогда не требуют какой-то конкретный фреймворк. Разработчики, в свою очередь, имеют возможность свободно выбрать тот инструмент, который они знают, и который лучше всего подходит к требованиям. Да, тут есть много Rails-подобных фреймворков, но также здесь имеется и набор фреймворков с отличной философией.


?( •??•??) Основная часть начинается здесь...


Эволюция и Производительность


В 2005-м PHP зарелизил версию 5.0, и ООП-подходы стали возможными для реализации (с момента релиза версии 3.0, там были очень ограниченные возможности ООП). Безусловно, RoR здесь является правопреёмником. И PHP не мог показать нечто конкурентоспособное в течении долгого времени.


Но, начиная с 2012, PHP получил массивный толчок вперёд вместе с версией 5.4, HipHop VM от Фейсбука и расширением экосистемы. Сегодня, с версией 7.0 и HackLang от Фейсбука, PHP имеет увеличенную вдвое производительность и низкое потребление памяти. Это определённо не медленнее Ruby 2.x.


Самое большое преимущество PHP приложений заключается в том, что скорость работы кода не зависит от Dev / Production окружения. Он не требует перезагрузки классов (т.к. каждый новый запрос использует актуальный код). Только расширение отладки даёт некоторый штраф. Но Production окружение не выкинет вам какое-то неожиданное поведение, так как обычно нет никакой разницы где запускается ваш код.


Будущее PHP ясно, потому что он имеет корпорации, стоящие за ним — Zend, Facebook, и так далее. Они постоянно работают над языком для того чтобы сделать его ещё лучше и быстрее.


Что насчёт Ruby? Множество туманных реализаций с туманный перспективами. (прим. переводчика — есть ещё такая вещь как Elixir, который тоже во многом является приёмником Ruby)


Сообщество


Не смотря на то, что корпорации вкладываются в развитие PHP, сам по себе он имеет реальное сообщество — PHP FIG (Framework Interop Group)


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


И эти парни из множества PHP проектов работают вместе (да, иногда они очень громко ссорились) и предлагают хорошо продуманные Стандарты Рекомендаций PHP. И сообщество реально принимает их через какое-то время.


Спасибо PHP FIG за то, что мы теперь имеем такие важные вещи, как Стандарты Кодинга и Стандарт Автозагрузки по Неймспейсам. Трудно переоценить, насколько важны эти вещи для современного PHP. Это действительно даёт нам возможность совмещать различные проекты и библиотеки в одной безконфликтной кодовой базе.


Я честно не вижу ничего подобного в Ruby, есть лишь Rails-диктатура.


Пакеты


Да, Bundler и Gems были удивительны для Ruby, и ручное копирование-вставка в PHP была ужасной. Начиная с 2012, PHP получил Composer, спасибо стандартам PHP FIG. Его цель в управлении пакетными зависимостями и в автозагрузке кода приложения.


Самая большая разница в том, что зависимости PHP хранятся на уровне проекта (каждый проект скачивает свой набор зависимостей), и по этой причине не может возникнуть каких-то коллизий между проектами.


Код автоматически загружается на основе Неймспейсов. И на практике это работает лучше, чем Constant Autoload в Rails с Ruby модулями. В PHP все пакеты имеют уникальное имя поставщика в Неймспейсе, и это позволяет очень легко отследить, какой код был загружен. Я реально имею массу проблем с этим в Rails, и не имею никаких проблем на стороне PHP.


PHP имеет Лигу Выдающихся Пакетов — группу разработчиков, которые объединились вместе, чтобы построить прочные, хорошо проверенные PHP пакеты с использованием современных стандартов программирования. Они имеют множество высококачественных независимых пакетов для Роутинга, Внедрения Зависимостей, Событий, Команд, Авторизации, Манипуляцией временем и многого другого. И нет ни одного ограничения для того, чтобы вы использовали эти прекрасные библиотеки в любом PHP фреймворке. Вы даже можете совместить их и создать свой собственный фреймворк!


Другой прекрасный пример — Aura for PHP — это полнофункциональный фреймворк, но состоящий из слабо связанных компонентов, которые вы можете использовать самостоятельно, или комбинировать из них то, что вам нужно.


[PHP]… фрагментированные, независимые и изолированные сообщества… Это один большой океан разрозненных островов.

Хм… Быть реюзабельным, изолированным и слабо связанным — это не значит быть "фрагментированным" или "разрозненным", и Магический Монолит — это не единственный архитектурный вариант!


Манки патчинг


Следует ли мне рассказывать о том, что PHP не имеет возможности манки-патчинга в своей основе? И что пакеты не сталкиваются друг с другом, когда какой-то манки-патч уже создал подобный метод в объекте. Да, это является ограничением PHP, вы не сможете делать много всякой магии как в Ruby, но мне правда лучше живётся без этих "острых ножей", и лучше думать о правильном OOП-дизайне, чем о заплатках.


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


Но подождите! 5.minutes.ago — это же так прикольно!

На самом деле не очень. Очень хорошая мотивация для этого даётся realntl на Reddit (читать полный текст)


Это в своей основе плохая форма: вставлять магические цифры в коде. Предпочтительнее использовать константы, и из-за того, что вы используете Integer#minutes от ActiveSupport, вы скорее всего закончите кодом вроде этого:

class Foo
  MINUTES = 5

def bar
    MINUTES.minutes.ago
  end
end

Обратите внимание на избыточность, которая содержится в указанном мною моменте в то время когда я назначаю значение переменной. Это означает, что вся польза от Integer#minutes будет только в ситуациях, когда элементарное значение вкладывается непосредственно в код — что на самом деле является наименее желательным местом, в которое было бы хорошо поместить это элементарное значение. Другой недостаток Integer#minutes (и, естественно, дней/неделей) это то, что он в основном используются для работы с временными отрезками, связанными с другой точкой времени — как правило, "сейчас". В этих ситуациях у вас возникнет потребность в указании источника времени, чтобы поведение можно было бы корректно контролировать во время тестов. Без возможности управления временем, вам придётся использовать timecop style gem для решения этой проблемы. Отныне всё, над чем вы работаете, стало более сложным и менее явным. Это предсказуемо: неявный код создаёт проблемы, а потом в качестве решения предлагается ещё более неявный код.

Так каков же правильный путь для того чтобы сделать 5.minutes.ago в Ruby? Использовать библиотеку Time и сделать это через TimeMath.minutes.decrease(Time.now, 5).


В Rails манки-патчи добавляют в стремлении к красоте кода, чтобы скрыть проблемы "жирных контроллеров". Rails пытается сделать код Контроллера маленьким через некоторые кусочки кода вроде Array#second_to_last, Array#third_to_last или ArrayInquirer. Простите, но это уже выглядит смешным.


(Уродливый) Синтаксис


Ruby имеет определённо больше возможностей для написания "хорошего" кода. PHP никогда не будет даже близок. Потому что он требует явного указания $this, а также точки с запятой и скобок :) И, конечно, это лишь вопрос времени, чтобы привыкнуть к этому. Ну а с хорошей IDE это вовсе перестаёт быть проблемой в написании кода и читабельности.


Ruby имеет возможность определить классные предикатные методы вроде admin?/access?, в PHP вы не можете использовать символ ? в названии метода, и предикаты в PHP обычно решаются через называние методов как isAdmin/hasAccess.


PHP имеет опциональный(!) Контроль типа. И поверьте мне — когда вы привыкнете к этому, вы поймёте, какая это удобная функция. Если у вас есть стремление сделать свой код более строгим, вы всегда можете сделать это через нативные языковые конструкции. Это позволяет добавить натуральную поддержку реализации контейнеров Внедрения Зависимостей, а также получить классное автодополнение в IDE.


DSL


PHP не имеет DSL, по крайней мере такой, какой существует в Ruby.


DSL хорош в тех ситуациях, когда он используется где-нибудь в Vagrantfile. Но не очень хорошо, когда его использованием злоупотребляют без хороших причин, стремление писать всё в DSL ИМХО некорректно. Вы должны сначала создать прочную ООП конструкцию, а уже потом упрощать её с помощью DSL. Всё, что делается через DSL, должно делаться и без него. Таким образом мы согласуемся с принципов "Простое легко, сложное возможно".


Метапрограммирование


Ruby имеет непревзойдённую возможность к динамической композиции во время выполнения. Разработчик имеет возможность переопределить элементы Класса (методы, и так далее). Господи, как я это ненавижу! :D Потому что я никогда не знаю "где найти это ***ое определение метода". Но это "острый нож", и в хороших руках разработчик может делать великие вещи.


В PHP нет такой силы. Единственная магия, которую вы можете делать — это использовать "магические методы" типа __get для получения и возвращения отсутствующего свойства или __call для реакции на отсутствующий метод. Есть некоторый набор подобных методов. И, тем не менее, меньшее количество магических возможностей, которое у вас имеется, упрощает анализ кода.


Фреймворки


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


Полнофункциональные фреймворки:


  • Laravel 5 — один из самых трендовых фреймворков в последние 2-3 года, с большим количеством DDD архитектурных подходов.
  • Symfony 3 — считается одним из самых Enterprise-подобных фреймворков, имеет слабо связанные компоненты и хранит код приложения изолированным от фреймворка.
  • Yii 2 — имхо, один из самых "рельсовых" фреймворков, довольно твёрдый и связанный в пользу скорости разработки.
  • Phalcon — совершенно уникальный PHP фреймворк, работающий как C-расширение, имеющий самый высокий показатель количества запросов в секунду.
  • Zend 2 — один из самых старых фреймворков, созданный компанией Zend, разработчиками PHP, но, тем не менее, имеющий очень низкое влияние на рынке PHP кадров.

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


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


Помимо прочего, существует также параллельная вселенная мини-фреймворков, некоторые из которых являются урезанными версиями "старших братьев" (Lumen < Laravel, Silex < Symfony). Но даже они предоставляют прочные и отработанные механизмы роутинга и внедрения зависимостей для создания такой бизнес-логики, которая вам может потребоваться.



Что мы имеем в мире Ruby? Ответ прост: Rails. И ещё Sinatra, мини-фреймворк.


Молитесь Всевышнему за Hanami.


Архитектура


К сожалению, в PHP я не знаю разобранного архитектурного фреймворка (такого как Trailblazer в Ruby). Каждый фреймворк пытается предложить свой собственный архитектурный подход. К примеру, Laravel предлагает DI, RequestForms, Events и Command/Handler, Entity/Repository, и так далее.


Большинство фреймворков в PHP поощряют разделение компонентов и внедрение зависимостей, но, к несчастью, как и в Rails — никто не учил их хорошим и правильным подходам. Всё это по большей части зависит от самого разработчика.


UPD


Я нашёл пример архитектурного фреймворка в PHP: Broadway


Broadway является проектом для создания инфраструктуры и помощников в тестировании для создания CQRS или событийно-ориентированных приложений. Broadway старается из-за всех сил, чтобы не встать у вас на пути. Проект содержит несколько слабо связанных компонентов, которые могут быть использованы вместе, чтобы обеспечить полный опыт CQRS \ ES.


ORM / DAO / Data Access


Это начинается с ActiveRecord в виде ORM'ов, но быстро оценивается в подход с Entity/Repository. Также существует множество конкурентов для Yii ActiveRecord со слоем DAO (кстати, в них имеется поддержка нескольких БД, запросов между несколькими БД, даже между реляционными и NoSQL), Doctrine, Eloquent, PropelORM, и так далее.


В Rails мы имеем ActiveRecord — и весь мир вращается вокруг него. Hanami имеет свой DataMapper-подход. И ещё есть библиотека Sequel.


Интересный факт заключается в том, что создатель DataMapper в Ruby стал NoORM-персоной и теперь рассматривает все ORM-подходы не стоящими усилий.


Статический контент


Rails имеет качественный инструмент Sprockets, которая была магически клёвой в ранние дни: они может компилировать и комбинировать JS, CSS, SASS, LESS, и так далее. Можете расслабиться и забыть про него.


PHP фреймворки изначально не имели ничего подобного. В PHP не запускается свой сервер и наблюдатель изменений. Rails имел превосходство.


Но мир JS/CSS изменился. Так быстро, что Sprockets просто не успевает приспособиться (это очень медленный процесс в Dev окружении, assests:precompiletask нужна вечность при деплое, и он не поддерживает все последние JS пре-комилеры). Вся работа по обработке JS/CSS нынче выполняется на стороне утилит Node.js вроде Webpack/Babel. Это практически промышленный стандарт. И Rails теперь потерял своё преимущество.


Сегодня каждый может взять Node.js + WebPack и использовать все современные ES6 + SASS + JS фрейморки + Горячую перезагрузку, не смотря на язык и фреймворк, который он использует. Я делаю это и с PHP, и с Rails. Мне не нужны специфичные для Rails скиллы, когда я могу использовать общие навыки.


Фоновые задачи и очереди


Одна вещь, которая отсутствует в PHP — это фоновые задачи. В силу того, что его процессы не предназначены для долгой жизни. Есть несколько подходов для подключения PHP демонов, но PHP требует некоторую помощь здесь — супервизоры, следящие за процессами + бекенд для очереди задач (Redis, Beanstalkd, и так далее).


У Ruby здесь имеется гораздо больше собственных инструментов типа DelayedJob, Sidekiq, и так далее. И это является удивительным, когда вы откладываете операции "бесплатно", без всякой дополнительной мозговой деятельности — вы можете сделать более лучший старт на начале. Но в конечном счёте масштабируемые очереди Ruby используются вместе с Redis или чем-то подобным.


Поддержка IDE и авто-завершение кода


Изначально мне было интересно, по какой причине большинство Ruby разработчиков не используют большие IDE, и вместо этого сидят в Sublime, и т.д. Впоследствии я понял, что даже такие классные IDE как RubyMine не дают вам практически ничего в плане автодополнения кода для Ruby. Из-за его динамической природы. И это до сих пор меня расстраивает.


В PHP, не смотря на то, что это тоже динамический скриптовый язык, автодополнение работает намного лучше. И он имеет широкий стандарт PHPDoc, который позволяет аннотировать ваш код, чтобы дать почти 100% корректное автодополнение даже для динамических фабрик. Фреймворки и библиотеки полностью аннотированы, это правило этикета в PHP: аннотация исходных кодов. И мне очень не хватает этого в Ruby.


Тесты


Ruby имеет выдающиеся возможности тестирования благодаря своей способности вновь открывать классы и создавать нативные заглушки. Это действительно не требует использования внедрения зависимостей для изменения сложного поведения кода во время тестов. Вместе с RSpec, Minitest и Cucumber вы можете создавать любые типы тестов: Юнит, Интеграционные и BDD.


PHP также имеет набор инструментов для тестирования — основным является PHPUnit. Он предоставляет прочную основу для различных проверок и заглушек. Фреймворк Codeception предоставляет BDD-стиль Юнит и Интеграционных тестов. Также имеются подходы, копирующие Cucumber (такие как Behat), но я думаю, что это едва используется в PHP. Единственным ограничением является лишь то, что в Юнит тестах вы можете использовать грязные методы и действительно нуждаетесь в обдумывании внедрения зависимостей или создании заглушек для точек входа ваших классов.


Да, TDD не мёртв, вам просто нужно продумать архитектуру своего кода.


Заключение


И нет никакого заключения.


В любом случае, я не призываю вас оставить Ruby и начать работать на PHP!


Я просто надеюсь на то, что данный пост сможет убедить кого-то в том, что Ruby on Rails является не таким уж большим Слоном в Большой Комнате Разработки Веб-Приложений. В течении долгого времени люди из "параллельной PHP вселенной" делают великие продукты и хорошо проводят время вместе с инструментами, которые совсем не хуже того, что существует в мире Ruby. Если вы не можете смотреть так широко — вы знаете, кто в этом виноват!


Обновление от 2016.06.01


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


Это не про Ruby On Rails, а про плюрализм и агностицизм

Я не собирался обсуждать недостатки архитектуры Rails в данной статье. Это не основная цель. Я стремлюсь показать, как сильно это влияет на всю экосистему Ruby. И как отличается ситуация в мире PHP с плюрализмом фреймворков и агностицизмом библиотек.


Пост посвящён в целом экосистемам, а не каким-то конкретным фреймворкам или отдельным аспектам языка (вроде манки патчинга).


5.minutes.ago

Окей, просто остановим это :) Мы всегда говорим о разных вещах. Одна сторона пытается убедить в "красоте кода", а другая винит его за "внутреннее состояние". И пока мы будем обсуждать вопрос 5.minutes.ago в таком ракурсе — это будет бесполезно.


Laravel

Любопытно, что он жалуется на RoR и при этом приводит в пример Laravel, когда Laravel — это практически RoR в мире PHP

В определениях функций RoR и Laravel разделяют не так много, но ведь в терминах философии они разделяют намного больше?

Это на самом деле не так важно, насколько Laravel и Rails разделяют, и насколько авторитетен Taylor Otwell. Что более важно, и что я старался подчеркнуть — это то, что Laravel не вредит экосистеме PHP, вне зависимости от того, что происходит в экосистеме Laravel (и это нормально для PHP, так как язык поощряет писать реюзабельные решения и просто делать небольшие обёртки для интеграции с фреймворками, а не наоборот). Что касается Rails — то они делают больно и влияют на всю экосистему Ruby.


Laravel и DDD, да, я сделал слишком громкое заявление, я просто хотел подчеркнуть, что не смотря на то, что он был вдохновлён Rails, он имеет множество передовых архитектурных особенностей из коробки: внедрение зависимостей, формы, командная шина, и так далее.


Behat / Cucumber

Я удивлён, что он "почти не используется". Я люблю Behat

Потому что это не утилита для тестов :) Это инструмент коммуникации, который позволяет вам преодолеть разрыв и избежать недоразумений между вашим бизнесом и вашей технической командой.

Я сильно удивлён тем, сколько людей подняли руки в пользу Behat / Cucumber. И простите, кажется, мои слова могли выглядеть резкими. Я всегда рассматривал Behat как инструмент для тестирования. Я имею очень упрямое видение автоматизированного тестирования, и рассматривание подхода Огурца не самый простой путь (без разницы, реализация на PHP или Ruby). Тесты это очень чувствительные вещи, и я стараюсь держать их ближе к нативному коду, насколько это возможно (с простой отладкой и автодополнением), т.е. я использую PHUnit + Codeception в PHP или Minitest+Capybara в Ruby.

Поделиться с друзьями
-->

Комментарии (203)


  1. TheDeadOne
    28.07.2016 06:13
    +34

    Или они видели WordPress — самый популярный и самый уродливый с точки зрения архитектуры PHP код, который когда-либо был написан.

    Счастливчик автор, не видел битрикса.


  1. printercu
    28.07.2016 07:19

    Откуда такой кипиш?! Раз в месяц кто-то новый пишет, как ему не нравятся рельсы. Ну не нравятся — хорошо. "Но, пожалуйста, не доставайте и не размахивайте им на людях."


    1. saggid
      28.07.2016 07:38
      +23

      Ответная реакция на эти регулярные выпады в сторону PHP, мсье) Пыха нынче уже не тот, может кое-чем и ответить.


      1. printercu
        28.07.2016 12:21
        +8

        Я особо не слежу, но мне не попадается уже пару лет про пхп ничего нового такого. Про го — помню, про ноду — помню, про скалу — тоже. Про пхп — нет, уже все давно написано. Да и выпадов на пхп, по-моему, меньше стало.


        1. VolCh
          28.07.2016 12:27

          Вы пропустили выход PHP 7.0 чуть больше полугода назад? А на днях 7.1 вышел в бету.


          1. printercu
            28.07.2016 12:28
            +6

            Было много выпадов на него? Вроде всем понравилось, как я понял.


            1. VolCh
              28.07.2016 13:13
              +5

              В том-то и дело, что многие выпады на PHP не учитывают даже появление 5.3.


    1. taliban
      28.07.2016 10:35
      +8

      Откуда такой кипиш?! Раз в месяц кто-то новый пишет что ему не нравится такая статья. Ну не нравится — хорошо. «Но, пожалуйста, не доставайте и не размахивайте им на людях.»


  1. varnav
    28.07.2016 08:19
    -9

    Для меня как админа смущает многошаговый деплой RoR приложения по сравнению с PHP, где надо просто скопировать файлы.


    1. Coffin
      28.07.2016 08:42
      +30

      Похоже, что вы так себе админ.


    1. VolCh
      28.07.2016 08:44
      +2

      Вы, наверное, мало встречались с современными PHP-приложениями. Навскидку при деплое обычного веб-приложения (в предположении, что среда исполнения развёрнута) надо:
      0. Включить maintenance mode
      1. Залить файлы
      2. Настроить конфиги
      3. Установить зависимости (composer install)
      4. Прогреть кэш генерируемых php-файлов
      5. Прогнать миграции базы данных
      6. Установить зависимости для фронта (часто npm install)
      7. Сбилдтить всё для фронта (webpack например)
      8. Включить production mode


      1. Gugic
        28.07.2016 08:45
        +2

        Все это можно сложить в один gulp build:prod


        1. VolCh
          28.07.2016 08:57
          +6

          Или команду консоли симфони, или баш-сценарий, или плэйбук ансибл, или рецепт шефа — суть не меняется, шаги остаются


          1. Gugic
            28.07.2016 09:04
            +1

            Но это уже не будет касаться админа.

            Ну и да, в список еще клиетнские зависимости надо добавить (которые через bower install) и что-то, что из разберет по нужным папкам.


            1. VolCh
              28.07.2016 09:41
              +1

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

              6. Установить зависимости для фронта (часто npm install)
              7. Сбилдтить всё для фронта (webpack например)


              1. Gugic
                28.07.2016 12:56

                Тут где-то должен быть водораздел. Разработчик должен написать сборку (точно шаги 6, 7 и вполне вероятно шаги 3, 4, 5 из вашего списка), с учетом всех нюансов работы в dev/prod/stage режимов, девопс должен написать все остальное и интегрировать в CI систему.

                Через npm как правило ставят зависимости именно для сборки фронтенда. Сторонние библиотеки, которые используются непосредственно в работе клиента (типа jQuery или Angular) подтягиваются через bower как правило.


                1. Fesor
                  31.07.2016 19:54

                  подтягиваются через bower как правило.

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


                1. VolCh
                  01.08.2016 07:58

                  Всё зависит от квалификации как девопса, так и разработчика, по-моему. «Чистый» разработчик может просто не знать какие окружения будут в dev/prod/stage режимах. Я вот посылаю к админам фронтендеров и дизайнеров, когда они хотят развернуть проект локально под виндой. Я кое-как автоматизировал развёртывание в прод и стейдж с предположением, что на сервере стоит не просто та же ось, но и тот же дистрибутив той же версии, что и у меня на ноуте, а всё остальное не моё, как разработчика, дело, по-моему. А во многом и так чужую работу делал.


            1. Igogo2012
              28.07.2016 13:25

              Зависимости bower и npm можно устанавливать используя composer


              1. Gugic
                28.07.2016 13:28

                Тут ветка пошла на второй круг. ("… команду консоли симфони, или баш-сценарий, или плэйбук ансибл, или рецепт шефа ..." (с) )


          1. LastDragon
            28.07.2016 09:15
            +3

            По своему небольшому опыту взаимодействия с рельсами (а конкретно периодическое обновление redmine) могу сказать что почти любой проект на PHP гораздо легче поднять чем на рельсах — последний раз особенно доставил переезд на centos 7 — вроде и окружение очень похожее, но все равно пришлось помучиться несколько часов — bundler отказался грузить зависимости из-за конфликтов/ошибок, а гугл как обычно оказался пуст :( И это реально проблема — любую нестандартную ошибку практически невозможно нагуглить, redmine у меня где-то с 2010 наверное и я бы не сказал что стало сильно лучше (обновляю раз в год/два), разве что bundler появился, до него всё еще печальнее было...


            1. drakmail
              28.07.2016 09:34
              +1

              У Redmine, на мой взгляд, не самая лучшая архитектура. Ну и обычно rails приложения деплоят одной командой Capistrano.


              1. VolCh
                28.07.2016 09:42
                +2

                Который нередко используется и для деплоя php-приложений. По крайней мере до появления докеров и ансиблей.


                1. imgen
                  28.07.2016 11:35

                  и после их появления capistrano смотрится не хуже, мы до сих пор используем capistrano и только рады.


                  1. VolCh
                    28.07.2016 12:20
                    +1

                    Для capistrano, как правило, нужен уже подготовленный сервер, сценарии с шагами типа «apt-get install php» писать и поддерживать тяжело. Готовить его удобно с помощью того же ансибля или аналогов, и он же хорошо справляется с задачами деплоя — зачем плодить сущности? Сейчас капистрано остался только на старых проектах, переводить специально смысла нет, но нет и смысла начинать новые симфони/сайлекс/… проекты с капистрано.


                1. grossws
                  28.07.2016 22:25

                  Мы деплоили через него статику и шаблоны для java-приложений, довольно универсальная штука, в общем-то. С сильным перекосом в сторону ruby-мира (поддержка того же rvm и рельсов), но это естественно.


            1. varnav
              28.07.2016 11:09

              Похоже, мы с вами оба так себе админы.


      1. BoBRoID
        28.07.2016 18:49

        мой алгоритм развёртывания php приложения на yii2:
        0. maintenance mode on
        1. git pull (svn export)
        2. composer update
        3. ./yii migrate
        4. maintenance mode off

        зачастую это происходит по хуку с github'а при апдейте master'а, и выполняется автоматизировано

        p.s. если у кого проект не на vcs, то шаг 1 выглядит как выгрузка файлов по ftp


        1. bohdan4ik
          28.07.2016 21:40
          +5

          Для чего вы делаете `composer update`? При развёртывании нужно устанавливать ровно те версии зависимостей, с которыми разрабатывалось и тестировалось приложение, а они хранятся в composer.lock, который `update` перезапишет с новыми версиями. Нужно использовать `composer install` и хранить composer.lock в системе контроля версий.


          1. BoBRoID
            29.07.2016 10:45

            я, обычно, проверяю локально, чтобы приложение было совместимо со всеми последними версиями зависимостей, и только потом деплою
            ваше утверждение тоже верно, так как если я заброшу поддержку приложения, и вдруг обновятся зависимости, то всё упадёт, но я говорю про приложение, над которым ещё идёт (или в перспективе будет идти) разработка, и которое не упадёт в паблик для всех
            я просто не знаю: вдруг 90% разработчиков реально разрабатывают opensource для всех, тогда да, я не прав, но в большинстве случаев при обновлении зависимостей происходит исправление каких-то глюков этих самых зависимостей


            1. mayorovp
              29.07.2016 10:55
              +4

              Вот после локальной проверки и надо фиксировать composer.lock в репозитории, а при деплое — использовать composer install. В противном случае можно нарваться на выход новой версии в процессе деплоя.


              1. sl_bug
                29.07.2016 10:55

                да и composer install банально быстрее отработает, т.е. деплой будет быстрее


    1. Kane
      28.07.2016 08:49

      Из каких шагов состоит деплой RoR и PHP приложений?


      1. varnav
        28.07.2016 11:08
        -4

        Деплой приложения на RoR, согласно этой статье, из 20 с лишним шагов.
        Деплой приложения на PHP, ну например популярного Wordpress, согласно этой статье, из 5 шагов.


        1. sl_bug
          28.07.2016 11:10
          +4

          cap production deploy
          


          Один шаг. Всё остальное это настройка capistrano и подготовка окружения к первому деплою.


          1. varnav
            28.07.2016 11:16
            +2

            С таким подходом можно вообще любую задачу свести к одной команде. Типа:

            — Как развернуть информационную систему X, состоящую из 43 хостов, в т.ч. серверы приложений, кэша, веб-серверы, БД серверы, серверы мониторинга, обработки AMPQ, и так далее?
            — Одной командой, ansible-playbook deploy_x_system.yml


            1. sl_bug
              28.07.2016 11:22
              +2

              Ну тогда и в пхп нужно считать правильно, и не по вордпрессу. Деплой первого попавшегося приложение на yii2 + angular в нашей компании, судя по дженкинсу, состоит из 21-го шага.


              1. varnav
                28.07.2016 11:35

                А деплой первого попавшегося на RoR?


                1. sl_bug
                  28.07.2016 11:39

                  26


                  1. sl_bug
                    28.07.2016 11:46
                    +1

                    но прошу заметить тут как был 3 приложения. админка, апи, фронт. и все это multitenant.


          1. VolCh
            28.07.2016 11:20
            +2

            Не путайте команду с шагом.


    1. Fedcomp
      28.07.2016 11:14
      +1

      Что в php приложении что в типичном rails приложении (т.к rails практически монополист среди руби фреймворков) вы будете использовать систему деплоя, а это зачастую одна команда. Я уже не говорю о том что зачастую деплоить вообще должен CI из мастера, например.


      1. varnav
        28.07.2016 11:18
        +1

        Разумеется. Но там выше верно подметили: Все это можно сложить в один gulp build:prod Или команду консоли симфони, или баш-сценарий, или плэйбук ансибл, или рецепт шефа — суть не меняется, шаги остаются


  1. sumanai
    28.07.2016 09:11
    +10

    Ruby имеет возможность определить классные предикатные методы вроде admin?/access?, в PHP вы не можете использовать символ? в названии метода,

    Юникод позволяет делать страшные вещи на PHP.
    <?php
    
    define ('Да', true);
    define ('Нет', false);
    
    function лол?($лольность = Нет) {
        if ($лольность) {
            echo 'Лол!';
        } else {
            echo 'Не лол (';
        }
    }
    
     лол?(Да);
     
    

    Не повторяйте это в реальных проектах!


    1. Ch4r1k
      28.07.2016 11:56
      +5

      Юникод позволяет делать страшные вещи не только в PHP, но и в PostgreSql, видали имена столбцов в виде эмодзи?


      1. olshevskiy87
        28.07.2016 13:16
        +1

        видали имена столбцов в виде эмодзи?

        вы об этом? )


        1. Ch4r1k
          29.07.2016 07:42

          И об этом тоже!)


  1. DeLuxis
    28.07.2016 09:19
    -2

    Когда стоял выбор изучения следующего языка после РНР и JS, межу Ruby и Python, то из-за синтаксиса, возможностей и гибкости предпочел Python.


    1. itforge
      28.07.2016 13:14
      -2

      Аналогично.


    1. iqiaqqivik
      29.07.2016 08:16
      +2

      Ну синтаксис ладно, а расскажите, как вы определяете «возможности и гибкость» незнакомого вам языка?


      1. DeLuxis
        29.07.2016 08:42

        Библиотеки и опыт использования для различных целей у других людей. Читаю форумы и другие площадки. Как бы мнение не сложно сложить.


        1. iqiaqqivik
          29.07.2016 09:32
          +4

          Мнение-то сложить никогда не сложно. Вот только _правильное_ мнение так сложить практически невозможно.


  1. erlyvideo
    28.07.2016 09:41
    -7

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

    Это всё нытьё из серии «PHP не такая уж и дрянь как мы все считаем» и «смотрите, смотрите: в 2016 мы в PHP научились как в рельсах в 2006»


    1. develop7
      28.07.2016 13:11

      Всем известно, что развиваются только и исключительно технологии, за которыми целенаправленно следишь.


    1. Cryvage
      28.07.2016 13:20
      +6

      смотрите, смотрите: в 2016 мы в PHP научились как в рельсах в 2006

      Лично я, смысл статьи понял как «в 2016 в PHP можно делать так же, как в рельсах в 2016. Но при этом в PHP есть много фреймворков, и если rails-like фреймворк не подходит, то всегда есть выбор.» Рельсы вообще очень удачное название. Руби как на них встал, так теперь и не может свернуть, ведь именно рельсы задают направление. Было бы гораздо лучше, будь у рельсов хотя бы один конкурент.
      Отчасти я согласен, что все это больше похоже на нытье, но в то же время, имеют же люди право свое мнение высказывать.


      1. filipov_a
        28.07.2016 16:19
        +1

        Было бы гораздо лучше, будь у рельсов хотя бы один конкурент.

        Sinatra, Padrino, Hanami, Grape.

        Мы, например, отказались от Rails.


  1. AlexLeonov
    28.07.2016 09:47
    +5

    Ну что же. Большой респект и автору, и переводчику, рискнувшему выставить этот перевод на публику. Респект за смелость.

    То, о чем говорит автор, давно уже назрело. Просто не принято было говорить вслух. Все последние годы считалось среди программистов средней руки хорошим тоном на публику кричать «пых — говно, руби рулит!», а тем временем потихоньку пилить проекты на Wordpress и, прости господи, Битриксе ради булочки с маслом.

    Руби — мёртв. И уже поздно обсуждать, как его реанимировать, нужно понять — как же это получилось? Как так вышло, что PHP, язык «быдлокодеров» внезапно (sic!) оказался более гибким, более быстрым, более правильным в архитектурном смысле, расцвел в пышную экосистему множества отличных фреймворков, а «илитный» Ruby лежит и плохо пахнет?

    Имхо, анализ сводится к трем пунктам:

    1. Монополия. Рельсы убили Руби. RIP они оба. И не только в рельсах дело. Дело в монополии на всё — один (фактически!) фреймворк, один человек, отвечающий за сам язык, одна система пакетов. Нет конкуренции — нет развития.

    2. Отсутствие развития самого языка. И даже отсутствие внятных механизмов обсуждения такого развития! Сравните, например, переходы PHP 5 -> 5.3, 5.3->5.4, 5->7. Каждая новая версия — фактически новый язык. Что нового появилось в Ruby за те же годы? А?

    3. Сильная связность с окружением. PHP работает везде, на любой ОС, с любым веб-сервером и без него, не требуя ничего от окружения, кроме возможности запустить бинарник «php.exe» (условно). А еще php-fpm.

    PHP не пытается быть сервером приложений, он просто честно делает своё дело — принимает запрос, отдает ответ и умирает. Может быть пора перестать воспринимать это, как недостаток дизайна языка?

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


    1. VolCh
      28.07.2016 09:58

      он просто честно делает своё дело — принимает запрос, отдает ответ и умирает

      Вообще говоря, подобный подход уже давно редкость, разве что в неинтерактивных CLI-инструментах используется. С момента появления mod_php PHP старается быть именно сервером приложений.


      1. AlexLeonov
        28.07.2016 10:06

        Не работаю с Apache.

        Назвать php-fpm сервером приложений — имхо, неверное употребление термина. Это сервер рабочих процессов. Процессов, которые запускаются и умирают.

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


        1. sumanai
          28.07.2016 10:13

          Процессов, которые запускаются и умирают.

          Не замечал перезапуска процессов FPM при каждом запросе.
          И если честно, мне такой подход нравится больше, чем бесконечный цикл приложения.

          Такой подход безусловно проще, но не лучше. У меня всё в мечтах написать что нибудь полезное на неумирающем PHP, к примеру, с помощью Aerys.


          1. G-M-A-X
            28.07.2016 20:49

            >Не замечал перезапуска процессов FPM при каждом запросе

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

            Да Вы и сами констатируете отдельно наличие неумираемого PHP…


        1. VolCh
          28.07.2016 11:25
          +1

          Нет, запускаются и умирают они редко (по умолчанию, емнип, один раз на 500 запросов), на каждый запрос при использовании php-fpm происходит лишь очистка доступного разработчику окружения, прежде всего глобальных и суперглобальных переменных и непостоянных файлоподобных ресурсов. Это выглядит «изнутри» почти как «запустился и умер», но только почти, только почти.


          1. AlexLeonov
            28.07.2016 13:14

            Речь не про реализацию пула процессов и прочего. А про то, как оно выглядит для разработчика, да.


      1. sumanai
        28.07.2016 10:06

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


        1. VolCh
          28.07.2016 11:28

          Спасибо за объяснение, но оно излишне, я с PHP3 начинал, в том числе используя его через чистый CGI (переписывал приложение с Perl) и знаю разницу между «умирать» и «делать вид что умираешь».


    1. sl_bug
      28.07.2016 10:36
      +9

      Есть подозрение что про руби вы знаете только название…

      > Монополия. Рельсы убили Руби. RIP они оба.
      в чем это выражено?

      > одна система пакетов
      эрлангу это не мешает, или тоже мёртв?

      > Что нового появилось в Ruby за те же годы? А?
      читайте changelogs и удивляйтесь

      > Сильная связность с окружением.
      серьёзно? «ruby.exe» куда-то удалили? ruby не работает с apache/nginx/cowboy?

      > PHP не пытается быть сервером приложений
      а руби вот прям пытается…


      1. crmMaster
        28.07.2016 14:29
        -2

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


        1. iqiaqqivik
          28.07.2016 14:43

          Кстати, в последнее время на SO очень много людей пришли в руби рубрику явно из php, и я буквально каждый второй ответ начинаю с фразы «this is an attempt to write php with ruby syntax».


      1. MetaDone
        29.07.2016 22:38

        > одна система пакетов
        эрлангу это не мешает

        https://hex.pm/
        http://synrc.com/apps/mad/


    1. sharikov_d
      28.07.2016 11:55
      +12

      Руби — мёртв.

      А мужики-то и не знали, пойду расскажу!
      Как так вышло, что PHP, язык «быдлокодеров» внезапно (sic!) оказался более гибким, более быстрым, более правильным в архитектурном смысле, расцвел в пышную экосистему множества отличных фреймворков, а «илитный» Ruby лежит и плохо пахнет?

      более гибким, более быстрым, более правильным

      кроме мантры ничего не вижу, по существу можно?
      Никто не заставляет использовать ActiveRecord, никто не запрещает писать отдельно операции/обжекты. Более того, криворукий кодерок может написать говнокод абсолютно на любом языке.
      2. Отсутствие развития самого языка. И даже отсутствие внятных механизмов обсуждения такого развития! Сравните, например, переходы PHP 5 -> 5.3, 5.3->5.4, 5->7. Каждая новая версия — фактически новый язык. Что нового появилось в Ruby за те же годы? А?

      Вы вообще следите за руби-комьюнити? написали хотя бы тысячу строк? Просто какие-то толсто-зеленые тезисы без аргументов

      3. Сильная связность с окружением. PHP работает везде, на любой ОС, с любым веб-сервером и без него, не требуя ничего от окружения, кроме возможности запустить бинарник «php.exe» (условно). А еще php-fpm.

      Не знаю, никогда не работал под виндой, но часто ли вы встречали приложения которые в продакшене крутятся на винде?


      1. AlexLeonov
        28.07.2016 13:12
        -4

        На последний ваш тезис: да, встречал. Не вижу никакой проблемы.

        На всё остальное: имхо еще долго люди, вложившие 3-5-7 лет своей жизни в Руби будут сопротивляться очевидным фактам и ставить минусы в карму тем, кто констатирует давно понятный факт: Руби сдох, надо слезать…

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


        1. sharikov_d
          28.07.2016 13:34
          +3

          очевидным фактам

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


        1. iqiaqqivik
          28.07.2016 13:46
          +6

          давно понятный факт: Руби сдох, надо слезать

          Я, судя по вашему апломбу и глупости, постарше буду, поэтому позволю себе рассказать вам несколько интересных вещей. PHP сдыхал на моей памяти три раза: в 2006, когда рельсы стали похоже на продукт, в 2012 (кажется), когда нода стала похожа на продукт, и в 2014, когда все хором заявили, что теперь заживем в вебе на го. И ничё, живет, пованивает конечно, но умирать не собирается.


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


          Многие профессиональные рубисты недолюбливают рельсы. Я не пишу на рельсах принципиально, работая в крупном финтехе. Пишу на руби. Много у вас там вокруг программистов, которые пишут на PHP, но принципиально не работают с фреймворками? Сомневаюсь, и могу рассказать, почему: язык слишком бедный.


          Ну и, наконец, мы-то переходим с руби: внутрь эрланговой виртуальной машины, используя написанный рубистами синтаксический сахар к эрлангу под названием Elixir. А куда пойдут похаписты, когда оно окончательно сдохнет? Ой, не знаю.


          1. VolCh
            28.07.2016 13:54
            +3

            А куда пойдут похаписты, когда оно окончательно сдохнет?

            Не дождётесь :) А если серьёзно, то, имхо, если сохранится тренд развития последних лет, то логичным будет переход на Java/C#. С другой стороны многие пехепешники неплохо знают JavaScript, причём с последними трендами не только клиентский, но и серверный. Например, для среднего миддла ) не должно составить труда написать на javascript веб-сокет сервер, который будет шарить сессии с http-сервером на PHP и дергать его как API.


            1. iqiaqqivik
              28.07.2016 14:41

              :)


              Ну не все же настолько всеядны, чтобы на js переходить без анестезии. C# только кажется простым, идеологически он гораздо извращеннее php, так что не уверен. Java — про другое совсем, поломать внутри все паттерны не так-то просто (а многим еще и неохота).


            1. G-M-A-X
              28.07.2016 21:00

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

              Вряд ли. У серверного JS совсем другая философия, как мне показалось.
              Говнокодинг не в счет.


              1. VolCh
                29.07.2016 02:02

                У серверного JS совсем другая философия, как мне показалось.


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


          1. G-M-A-X
            28.07.2016 20:58
            +1

            >Я не пишу на рельсах принципиально, работая в крупном финтехе. Пишу на руби.

            Уважаю.

            >Много у вас там вокруг программистов, которые пишут на PHP, но принципиально не работают с фреймворками?

            Мало. Я один из них :) С фреймворками не работаю не то что принципиально, просто они унылые.

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

            Не знаю, мне язык не показался бедным. Библиотека PHP, наверное, самая богатая.
            Недавний пример. Тут у нас у клиента на Java сломался парсер JSON, там он по ходу пишется вручную каждым программистом. :) В php же для этого всего одна функция: json_decode().


            1. iqiaqqivik
              28.07.2016 21:13
              +1

              Я не про библиотеку, я про средства выразительности самого языка. Самые выразительные, разумеется, LISP и (с небольшим отставанием) Erlang. Ну вот например задача: средствами языка написать логгер, который включается только в dev-режиме, а в продакшене не добаляет ни единой лишней инструкции процессора (high-load, то-сё). На руби у меня это получилось в 20 строчек.


              Даже на Java с AspectJ это гораздо более громоздко и менее интуитивно. Боюсь, что на PHP это совсем заковыристая задача.


              Ну и руби позволяет писать функциональный код, а функциональный map-reduce банального массива в PHP — это же трэш и угар, натурально.


              1. saggid
                28.07.2016 21:36

                функциональный map-reduce банального массива в PHP — это же трэш и угар, натурально.

                https://laravel.com/docs/5.1/collections#method-map
                https://laravel.com/docs/5.1/collections#method-reduce


                1. saggid
                  28.07.2016 21:43

                  А также нативные методы array_map и array_reduce.


                  1. sl_bug
                    28.07.2016 22:17

                    и лапша из скобок в виде array_merge(array_map(array_something_else))))


                    1. saggid
                      28.07.2016 22:51

                      Даже если у вас эта ненависть к функциям в скобках — возьмите класс коллекций из ларавел (он легко забирается в любой другой пхп проект, так как не имеет почти никаких зависимостей) и пишите все в стиле вызовов методов к массивам. Я дал ссылки наверху на пример же, каким образом вы смотрите на мои сообщения? Просто чтобы поспорить и «пошпынять php» в очередной раз?


                      1. sl_bug
                        28.07.2016 23:16
                        -1

                        Нет, не пошпынять. Просто частичное ФП в пхп очень плохо реализовано. и это факт.

                        Да до реальных ФП с пайпами ему далеко, но вещь в виде

                        some_var.map(&:method).inject(&:method).something(&:method)
                        


                        можно было бы придумать


                        1. saggid
                          28.07.2016 23:29
                          +1

                          PHP по другому смотрит на объекты и примитивы, это разница в идеологии и философии программирования. И при желании, вы можете использовать что-нибудь вроде вышеупомянутого мною класса коллекций из Ларавел. Никто вам этого не запрещает. Тогда вполне можно писать код в таком стиле, например:


                          $jsonUsersFilteredAndGroupedByCity = collect($usersArray)
                            ->filter(function ($user) { return $user->age > 20; })
                            ->groupBy('city_id')
                            ->toJson();


                          1. sl_bug
                            29.07.2016 00:22

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


                            1. saggid
                              29.07.2016 01:06
                              +1

                              Всё-таки видно, что пришли поспорить, а не к истине придти. Мне вам доказывать теперь, что ООП — это хорошо?) Пожалуйста, пользуйтесь чем хотите, но в мире программирования, отличии от мира реального, нет Единственной Истинной Религии, если вы своими комментариями пытаетесь претендовать на это.


                              1. sl_bug
                                29.07.2016 01:16

                                погодите, все началось с map-reduce в пхп без фреймворков. без споров. покажите как это сделать красиво и читабельно в пхп


                                1. saggid
                                  29.07.2016 01:18

                                  Я же кидал ссылки на красивые решения в своём комментарии выше :)


                                  1. sl_bug
                                    29.07.2016 01:21

                                    ну я и привел пример — как там внутри красиво использовать внешнюю переменную? (и да я в курсе что это не совсем functional way). и советую потом видео все-таки досмотреть


                                    1. sl_bug
                                      29.07.2016 01:25

                                      особенно внимание обратить на инкапсуляцию image


                                      1. saggid
                                        29.07.2016 01:51

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


                                        Картинка мало относится к PHP, если честно. Там не так уж часто объекты зависят от состояния друг друга, так как его логика работы слишком простая: получил запрос — вернул ответ, умер. Объекты если и шарятся между компонентами, их состояние не изменяется каким-то кардинальным образом.


                                        как там внутри красиво использовать внешнюю переменную?

                                        Именно так, как вы и сказали — через добавление use конструкции к объявлению анонимной функции. Опять же, не вижу особых причин для обсуждения этой части PHP: это не сильно мешает при разработке.


                                        1. sl_bug
                                          29.07.2016 08:29

                                          Вы не поняли посыл видео. ООП не работает нигде в том варианте как было задумано. То что вы называете ООП есть не ООП


                                          1. iqiaqqivik
                                            29.07.2016 08:31
                                            -1

                                            Это тоже ерунда. Посмотрите на Hadoop-и-все-вокруг. Там настоящее ООП.


                            1. VolCh
                              29.07.2016 02:04
                              +3

                              Это просто такой синтаксис замыканий. Явное лучше неявного типа.


                              1. sl_bug
                                29.07.2016 08:30

                                Белое лучше красного


                              1. iqiaqqivik
                                29.07.2016 08:30
                                -3

                                Ну да, такой синтаксис, конечно.


                                Да, можно привыкнуть. Но «явное лучше неявного», вы уж меня великодушно простите, это просто вообще не про php. Не нужно пытаться из табуретки сделать велосипед. Можно привыкнуть к тому, что ноль целых ноль десятых равен символу нуля, но они по разному себя ведут под ифом, можно. Но вот не надо после этого костыль (use) называть «таким синтаксисом», ладно?


                                1. saggid
                                  29.07.2016 09:30

                                  Сорян, я запарился спорить с вами. Займитесь делами, пишите на чем хотите, я не ваш пастух в любом случае.


                                  1. iqiaqqivik
                                    29.07.2016 09:37
                                    -6

                                    Вы не пастух, разумеется; вы просто недалекий, невнимательный и невежливый джуниор.

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


                1. iqiaqqivik
                  29.07.2016 08:26
                  -6

                  Вы сами себе и ответили.


                  Если в ответ на реплику о (заострите все ваше внимание, на секундочку, пожалуйста) средствах выразительности самого языка, вы сами же приводите ссылки на стороннюю библиотеку, значит с синтаксисом языка все очень плохо. И это не экзотика какая-нибудь, это map-reduce.


            1. Source
              30.07.2016 01:25

              А, кстати, вопрос про стандартную библиотеку: её хоть с выходом PHP 7 причесали в плане консистентности? Или такой же бардак как в 5.1 по-прежнему?


              1. sumanai
                30.07.2016 05:02
                +2

                Самую малость. Убрали замшелое старьё типа mysql_ функций, а так всё по старому.
                В 7.1 немного улучшат в плане строковых функций, но тоже не критично.
                В угоду совместимости никто не будет выкидывать беспорядочный ворох функций.
                Если кому-то хочется использовать консистентно функции строк и массивов, то советую расширение, позволяющее делать вот так:

                $string = "abc";
                var_dump($string->length()); // int(3)
                var_dump($string->startsWith("a")) // bool(true)
                


                1. Source
                  30.07.2016 12:03

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


                  1. VolCh
                    30.07.2016 14:26
                    +2

                    Подобное расширение языка потребует введение стандартных типов String, Int и т. п. к которым неявно будут преобразовываться строки, числа и т. п. в объектном контексте и обратно в скаляры в скалярном. Либо делать все переменные объектами изначально, что довольно накладно. Это возможно, наверное, но довольно трудозатратно и сильно изменит язык (сильнее чем тот же скалярный тайпхинтинг). С другой стороны мало есть смысла просто перебрать существующие функции, улучшив их сигнатуры — работы много, польза небольшая.


    1. kir_vesp
      28.07.2016 11:56
      +2

      1. Монополия — ну, фрэймворки есть и иные, просто никто ими не занимается. Проблема кмк в том, что многие прогеры считают руби "несерьёзным и хипстерским", хотя при этом недостаточно хорошо осведомлены о его реальных возможностях(а ведь можно и небольшие десктопные приложения ваять). А рельсы убивают руби тем, что большинство на этом и останавливается, хотя у языка достаточно и иных возможностей. Например, при обработке текстов и парсинге страниц я предпочитаю короткие скрипты на руби с его Nokogiri.

      По остальным пунктам сказать нечего, всё так.


      З.Ы. Занимаюсь разработкой на yii и сайд-проектами на RoR. Последнее время единственным legacy стал считать проекты на RoR, ибо там такое бывает, что просто умереть не встать)


    1. youlose
      28.07.2016 13:16
      +4

      Ох уж эти пророки… Вроде бы живём в информационный век, а Ванги не перевелись…
      Языки программирования не могут умереть, есть мера интереса общественности к ним. Судя по рейтингу TIOBE интерес к Ruby растёт http://www.tiobe.com/tiobe_index, причём динамика резвее чем у PHP. Так что о чьей либо смерти говорить совсем преждевременно. Да и PHP уже не в тренде, в тренде Java и Javascript, последний из которых упрямо лезет в нишу пхпни и успешно вытесняет её оттуда, а вот нишу Ruby никто из них занять не может (быстрая разработка с понятным и поддерживаемым кодом).
      Про «илитность» Ruby, говорят в основном PHPшники с узким кругозором, которые только на хпх и умеют говнякать. Я вот лично имею проекты и на Ruby и на PHP (даже Python и Golang присутствует) и ни о какой элитности ни одного из языков не вижу в принципе, у каждого есть своя ниша, свои задачи и даже свои клиенты с определёнными особенностями психики…

      Про пункты глупости написаны:
      1. Вот вы гвозди чем забиваете? Всё ещё молотком? Фи… Монополия… Надо выдумать какой-нибудь «шмолоток»?
      На руби, если изволите поинтересоваться, кроме рельсов есть и другие фреймворки (Grape, Sinatra, Jekyll, это только те, которыми лично я пользуюсь параллельно с рельсами), известность рельсов обусловлена тем что они очень грамотно и качественно сделаны, бурно развиваются и имеют уникальные фичи и технологии (те же Turbolinks и ActiveRecord (в PHP модно кричать что мы реализовали AR, но там даже десятой доли того что есть в рельсах не реализовано, попробуйте выполнить подзапрос с фильтрацией в любом PHP ORM, например), подобия которых в php фреймворках нет и непонятно будут ли.
      2. И что же добавили в PHP в этих версиях? Исправили кривое ООП на Java стиль? У Руби с этим проблем не было давно. По сути суть изменений PHP это вычищение deprecated авгиевых конюшен и борьба за улучшение производительности, потому что выяснилось что «крутые» и разнообразные ООП фреймворки на PHP жутко тормозят =).
      В Руби, как ни странно обновления также выходят с завидным постоянством и переходить между версиями НАМНОГО легче чем у PHP, у меня, к примеру есть сервер со старыми CMS и php 5.2 и обновляться он уже никогда не сможет. А настроить разные среды с разными версиями в пределах одного сервера для PHP нетривиальная задача.

      3. Тут вообще художественный свист, откуда же тогда берутся подобные говнотворения http://www.denwer.ru/ и люди мучаются разбираясь с ними днями?
      Из нескольких десятков пхпшников что я знаю ни один не сможет поднять php-fpm (упомянутый выше) хотя бы за один день.
      Про бинарник php.exe, я предлагаю попробовать, а потом уже разглагольствовать.
      При всём при том, что на рубях все фреймворки умеют просто и изящно работать локально (для разработки) из коробки. Простые проектики на php действительно разворачивать в продакшн обычно проще, но в средних и больших проектах у PHP сказывается отсутствие инструментов (или их зачаточное состояние) на скорость и удобство деплоя.

      Про сервер приложений, автор вообще не особо понимая что пишет написал судя по всему…


      1. atc
        28.07.2016 13:27

        >В PHP модно кричать что мы реализовали AR, но там даже десятой доли того что есть в рельсах не реализовано, попробуйте выполнить подзапрос с фильтрацией в любом PHP ORM, например, подобия которых в php фреймворках нет и непонятно будут ли.

        Простите, а в чем проблема? В среднестатистическом AR (для примера возьмем тот, что в Yii2) с подзапросами работать более чем удобно, любой relation легко фильтруется в анонимных функциях, просто приведу пару строк из документации:

        $customers = Customer::find()->joinWith([
        'orders' => function ($query) {
        $query->andWhere(['>', 'subtotal', 100]);
        },
        ])->all();


        1. G-M-A-X
          28.07.2016 21:11

          Это наверно будет не подзапрос, а JOIN.

          П.С.
          Данная конструкция JOIN-ит сущность 'orders' с дополнительнім условием «subtotal > 100»?


          1. atc
            28.07.2016 21:20

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


      1. VolCh
        28.07.2016 13:30

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

        PHP сам умеет работать для разработки из коробки. php [options] -S : [-t docroot] Всё, даже фреймворки не нужны.
        но в средних и больших проектах у PHP сказывается отсутствие инструментов (или их зачаточное состояние) на скорость и удобство деплоя.

        capistrano, puppet — зачаточные? )
        Про сервер приложений, автор вообще не особо понимая что пишет написал судя по всему…

        Как я понимаю, он имел в виду, что в PHP для создания типового сервера не нужно писать ни строчки кода, серверные функции берёт на себя среда исполнения, а приложение (для разработчика) работает по CGI, а на Ruby обычным является написание сервера на Ruby или использование написанного другими типа Thin.


      1. VolCh
        28.07.2016 13:47

        в PHP модно кричать что мы реализовали AR

        В PHP модно кричать «AR — отстой, DM — наше всё», имея в виду Doctrine 2.


        1. G-M-A-X
          28.07.2016 21:16

          Мода для людей без вкуса и ума. :)

          DM — это Doctrine\ODM\Mongo?
          Mongo та еще фигня на нагрузках говорят :)


          1. VolCh
            29.07.2016 02:06

            DataMapper ORM


      1. atc
        28.07.2016 13:48
        +1

        Ну и про «несколько десятков php-шников, неспособных установить php-fpm за день» — у вас явный логический провал, особенно если учесть, что сам процесс установки — всего лишь несколько консольных команд. Из чего можно вывести следующие варианты:
        1) им не нужен php-fpm и они его никогда его не устанавливали
        2) не знают linux и не имеют опыта работы в окружении, отличном от shared хостинга
        3) новички, не умеющие в чтение документации и английский язык

        Все три пункта совершенно невозможны для php программиста, пишущего под тот или иной фреймворк, следовательно ваше утверждение в принципе некорректно.


        1. G-M-A-X
          28.07.2016 21:18

          Разве программист должен заниматься установкой серверного софта?
          Может, но не должен. :)


      1. script88
        28.07.2016 13:51

        Я даже больше вам скажу, большая часть PHP разработчиков не в состоянии определить, в каком режиме работает PHP.
        По старинке пишут реврайты, php_value, etc в .htacess, два часа дебажат и в конечном итоге узнают то, что проект поднят на PHP-FPM.


        1. atc
          28.07.2016 13:54
          -2

          PHP разработчики не в состоянии посмотреть в конфиг вебсервера или в хедеры в ответе сервера? Я не знаю таких людей, которые при этом писали бы с использованием любого php фреймворка.


          1. script88
            28.07.2016 13:56
            +2

            Увы, а я знаю.


            1. atc
              28.07.2016 14:01
              -1

              Расскажите, как это возможно? В данный момент все современные php фреймворки используют composer (пакетный менеджер), что предполагает активное использование консоли, как на этапе разработки, так и на этапе деплоя. Самостоятельно деплоить проект и не знать, как настроено окружение? Что-то тут не сходится, уж простите.


              1. mayorovp
                28.07.2016 14:13
                +1

                На этапе разработки консоль не нужна (особенно если не отлаживать), а деплой и автоматизировать можно.


                1. atc
                  28.07.2016 14:17
                  -1

                  Как устанавливать\удалять composer пакеты без использования консоли? Почему автоматизицией деплоя и настройкой инфраструктуры\проекта под неё занимаются разные люди?


                  1. mayorovp
                    28.07.2016 15:02

                    Зачем устанавливать и удалять composer пакеты при разработке? Неужели отсутствие пакета помешает открыть Блокнот и поправить пару файлов?


                    1. sumanai
                      28.07.2016 15:09

                      А вы никогда при разработке не добавляли новых пакетов?


                    1. atc
                      28.07.2016 15:10

                      Библиотеки тоже в блокноте писать? Давайте не углубляться в демагогию.

                      Смысл в том, что у аудитория этой статьи (людей, перед которыми может встать выбор Rails\условный Symfony) в любом случае имеются навыки как работы с консолью, так и настройки окружения, это просто повседневная задача.
                      Потому меня слегка удивляют утверждения, что человек продолжительное время использующий cli для разработки и деплоя что-то там не может настроить на сервере.


                      1. mayorovp
                        28.07.2016 15:49

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


                        И речь шла именно о том, что полно PHP-кодеров, которые не используют cli для разработки и деплоя.


                        1. foxmuldercp
                          28.07.2016 23:39

                          Средние погромизды — это вообще печаль — говорю как имеющий опыт в несколько лет работы в хостингах, от саппорта до хостмастера. Наваять 100кб+ .hhtaccess, даже без удаления комментариев со стековерфлоу, где-то у себя под denwer'ом, и потом доставать техподдержку «почините ваш хостинг, он говно, в нём мой суперсайт не работает».


                          1. script88
                            28.07.2016 23:46

                            У меня пока рекорд — это находка .htaccess размером в 2.4МБ.


                            1. foxmuldercp
                              29.07.2016 13:59

                              … и в нем весь код сайта?


                              1. script88
                                29.07.2016 14:15

                                301 редиректы :)


                    1. iqiaqqivik
                      28.07.2016 15:17

                      Спасибо, это прекрасно.


                      Не хотел портить вам статистику по тем, кто воспринимает все за чистую монету, но не смог сдержаться, простите :)


              1. script88
                28.07.2016 14:26

                Погодите, с чего вы взяли, что речь идет исключительно о frameworks и compser? В PHP мало проектов которые не используют composer?! Поверьте, таких проектов очень много, как больших так и маленьких.
                Деплой у нас был через CI(Bamboo). Разработчику нужно было закоммитить изменения git repo и написать миграции для БД.


                1. atc
                  28.07.2016 14:35

                  Статья о сравнении Rails с фреймворками из мира PHP, цмс и подобные системы учитывать смысла не имеет — потому что ruby как платформа практически не предоставляет альтернатив. Следовательно композер в предполагаемом php проекте — обязательный элемент.

                  Относительно деплоя — трогать .htaccess или настраивать проект под окружения должен именно тот — кто конфигурировал CI, остальных разработчиков эта задача не должна затрагивать от слова совсем. Если допустить, что незнакомый с особенностями используемой инфраструктуры человек идет что-то перенастраивать — он как минимум должен внимательно прочитать readme, где будет русским по-белому написано «используется php-fpm».

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


                  1. mayorovp
                    28.07.2016 15:11

                    В файле .htaccess, по сути, в виде modrewrite-правил записываются основные входные точки для приложения — а потому заниматься им должен именно что разработчик.


                    Просто потому что проще самому написать эти самые правила, чем объяснять админу их на словах.


                    Ничего общего с настройкой проекта под окружение это не имеет — потому что эти правила будут одинаковы во всех окружениях.


                    1. atc
                      28.07.2016 15:16

                      А если на сервере php-fpm? Выше рассматривается именно этот момент.
                      Если человек пишет какой-то зависящий от окружения код или конфиги — он должен быть в курсе этого окружения. Если рассматривать ваш пример (с админом) — то последний должен был выкатить подробное readme, что делает невозможным вышеописанный случай.


                    1. VolCh
                      28.07.2016 15:33

                      В файле .htaccess, по сути, в виде modrewrite-правил записываются основные входные точки для приложения — а потому заниматься им должен именно что разработчик.

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

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


                      1. mayorovp
                        28.07.2016 15:54

                        Бывает, что на проект взяли нового разработчика, который вообще не в курсе, что существуют какие-то окружения кроме "дефолтного" apache + mod_php — а потому не видит необходимости спрашивать.


                        Если разработчик адекватен, а коллеги не ленятся объяснять — то эту ошибку он сможет допустить ровно 1 раз в жизни. Но от одного раза не застрахован никто :)


                        1. VolCh
                          28.07.2016 16:07

                          По хорошему это даже не он должен спрашивать, а ему сообщить на этапе вхождения в проект без всяких напоминаний. Я обычно именно так начинаю: «наш проект крутится на хапрокси+нжинкс+пхп-фпм+постгрес+редис+раббит+нода+плюс несколько бинарников на си — со всем встречался?»


                          1. mayorovp
                            28.07.2016 16:15

                            … и он отвечает: "да", потому что его прошлый проект и правда использовал nginx и php_fpm… между которыми стоял apache! :)


                            1. VolCh
                              28.07.2016 16:17

                              хорошо, буду добавлять в будущем «и больше ничего кроме ОС — знакомая связка?» :)


                  1. script88
                    28.07.2016 15:26
                    +1

                    Окей, давайте пойдем по другому, есть такой продукт как CMS\CMF Bitrix. Composer в Bitrix проектах используется редко, особенно в тех проектах, где разработка началась 2-3 года назад.

                    Если допустить, что незнакомый с особенностями используемой инфраструктуры человек идет что-то перенастраивать — он как

                    Он не перенастраивает, а добавляет и проверяет свой функционал, который крутил у себя в dev окружении

                    он как минимум должен внимательно прочитать readme, где будет русским по-белому написано «используется php-fpm»

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

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

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

                    Вот еще один момент вспомнил, когда разработчик хранил cache, php сессии в memcached(Не спрашивайте, зачем он это делал, но это было так), очищал его (memcflush --servers=localhost:11211) искренне удивлялся тому, что у него слетала авторизация в локальном проекте.


                    1. VolCh
                      28.07.2016 15:35

                      Он не перенастраивает, а добавляет и проверяет свой функционал, который крутил у себя в dev окружении

                      Кто ему поднимал это дев-окружение? Почему оно оказалось отличным от продакшена? Если сам, то на основании чего? Устаревшей документации?


                      1. script88
                        28.07.2016 15:41

                        Кто и при каких условиях поднимал, не знаю. Но подозреваю, что сам.


                    1. atc
                      28.07.2016 15:41

                      Bitrix это хорошо, но он находится вне контекста данной статьи, потому что он:
                      а) не является фреймворком общего назначения
                      б) не является альтернативной rails

                      Да, вполне возможно описанные вами проблемы могли возникать, но это другой мир с другими программистами и совершенно иными типами проблем. Для аудитории статьи сложности в вопросах настройки «php-fpm» просто нехарактерны, о чем я и писал выше.

                      > Он не перенастраивает, а добавляет и проверяет свой функционал, который крутил у себя в dev окружении
                      Которое должно автоматически развертываться и быть одинаковым для всех разработчиков.


                      1. script88
                        28.07.2016 15:51

                        Должно, но мы живем не в идеальном мире. Везде есть своя специфика и нюансы и эти проблемы свойственны в любой среде.


                        1. atc
                          28.07.2016 15:54
                          +1

                          Совсем нет, придуманы сотни инструментов, ansible, puppet, vagrant, docker, системы непрерывной интеграции и деплоя, если при таком гигантском инструментарии все еще продолжают возникать проблемы — то пенять нужно явно не на квалификацию программистов, а на того, кто организует рабочий процесс.


                          1. script88
                            28.07.2016 16:07

                            Вы уходите совершенно в другое русло. Ситуации бывают разные, нет идеальных работников. Если разработчик компетентен во многих вопросах, то он смело может ткнуть носом adm\devops в то место и аргументирует свое решение.


                            1. atc
                              28.07.2016 16:18

                              Вернемся выше:
                              > Я даже больше вам скажу, большая часть PHP разработчиков не в состоянии определить, в каком режиме работает PHP. По старинке пишут реврайты, php_value, etc в .htacess, два часа дебажат и в конечном итоге узнают то, что проект поднят на PHP-FPM.

                              Почему не в состоянии?
                              1) сервер настраивал нехороший человек, который не утруждался документированием
                              2) деплой настраивал не менее плохой человек
                              3) при этом на разработчика повесили задачу, зависящую от окружений, ни о чем не уведомив

                              Это не является ни проблемой программиста, ни его косяком, и тем более — такое не стоит приводить в пример, как типичную ситуацию.


                          1. VolCh
                            28.07.2016 16:13

                            Да даже не в инструментарии дело, в конце-концов для новых участников проекта должна быть инструкция по разворачиванию хотя бы дев-среды. Из пары команд типа git clone… && vagrant up или длинный талмуд со скриптами на 5 языках, но должна быть. А если нет, то пенять нужно, да, на того, кто организует процесс, на того, кто не поставил задачу задокументировать процесс разворачивания.


        1. sumanai
          28.07.2016 14:31
          +2

          Я вас разочарую, но PHP-FPM можно поднять и на Apache, реврайты будут прекрасно работать.


          1. script88
            28.07.2016 15:33

            Спасибо капитан. Пойду пацанам расскажу, а то они не знали.


      1. G-M-A-X
        28.07.2016 21:08

        >«крутые» и разнообразные ООП фреймворки на PHP жутко тормозят

        Согласен. Я это постоянно говорю. Но илита загоняет меня в минуса и ридонли :)

        >А настроить разные среды с разными версиями в пределах одного сервера для PHP нетривиальная задача.

        Я руками с исходников себе ставил.
        Или пользуйтесь шаред хостингом.

        И обновлялся практически бескровно 5.2-5.3-5.4-7.0

        >Из нескольких десятков пхпшников что я знаю ни один не сможет поднять php-fpm (упомянутый выше) хотя бы за один день.

        На винде оно какое-то кривое стало с 2009 года, поэтому пользуюсь OpenServer. Я в 2008 как новичек все сам поднимал без проблем.

        П.С.
        Пробовал также и руби, ставил редмайн. :)


        1. MetaDone
          29.07.2016 23:24

          >«крутые» и разнообразные ООП фреймворки на PHP жутко тормозят

          Согласен. Я это постоянно говорю. Но илита загоняет меня в минуса и ридонли :)

          http://govnokod.ru/19878
          Ваше мнение и гроша ломанного не стоит, т.к. вы некомпетентны совсем, или же уже 3 аккаунт тупого тролля (не жирного, именно тупого, который показывает недостаток наличия аккаунтов без инвайта с возможностью что-то комментировать)


          1. G-M-A-X
            30.07.2016 00:55
            -2

            О-хо-хо.

            Вы сидите в тьюринговой трясине: https://habrahabr.ru/post/139535/
            :)


      1. sumanai
        29.07.2016 01:35
        +1

        А настроить разные среды с разными версиями в пределах одного сервера для PHP нетривиальная задача.

        Я пользуюсь вот этим репозиторием, установка версий 5.6 и 7.0 была элементарной.


        1. saggid
          29.07.2016 02:25

          Да, подтверждаю. В системе после установки появляются разные бинарные файлы: php5.6 и php7.0, что полностью решает все проблемы с запуском различных версий PHP на одной машине.


    1. thousandsofthem
      28.07.2016 15:12
      +1

      Ruby/Rails таки еще не мертв но перспектив развития особо нет и через какое-то время умрет

      Про то, что rails плох — пусть хотя-бы один пхп фреймворк будет настолько плох и он станет лучшим пхп фреймвоком из существующих. Серьезно, планка поднята очень высоко и не смотря на серьезные архитектурные проблемы rails все еще живее всех живых

      Да даже упомянутый asset pipeline — какие фреймворки из коробки имеют настроенный сборщик ассетов? Ведь оно все равно надо а настраивать это не так тривиально (нужные разные правила для разных окружений, надо уметь hot reload в дев, source maps etc) — зачем тратить тысячи человекочасов на повтор такого раз за разом. Рельсы берут такими вот мелочами — когда за тебя решены вопросы которые все равно придется решать

      Про то, что переходить некуда — уже есть. Зовется Phoenix (язык — elixir). Делают люди из команды rails. И таки разработчики на него уже переходят т к все основные проблемы рельс успешно решены. Всячески рекомендую.


      1. iqiaqqivik
        28.07.2016 15:20

        Хосе — не «люди», и он никогда не работал в «команде rails».


        1. thousandsofthem
          28.07.2016 15:57

          Jose Valim — http://contributors.rubyonrails.org/ — #5 по количеству коммитов.
          Пусть будет не "в команде" а core contributor тогда


          1. iqiaqqivik
            28.07.2016 21:18

            Contributor — это безусловно. Просто там же очень много политики, как раз вокруг Elixir’а, и мне показалось, что на этом имеет смысл заострить внимание.


            В смысле, я про идеолога DHH и его свиту :)


            1. sl_bug
              28.07.2016 22:24

              т.е. команда = dhh?

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


              1. iqiaqqivik
                29.07.2016 07:03

                Нет. DHH — это и есть команда рельс. И именно поэтому, в частности, мы имеем то, что имеем: Elixir, придуманный не от хорошей жизни (насколько мне известно, перед Хосе не стояло никакой практичесой задачи), Solnica, воюющий с ветряными мельницами, плодящиеся адовые коллбэки в AR, откровенные костыли в корке, GFY в твиттере и т. д.


                Почитайте любой тред с участием DHH.


        1. develop7
          28.07.2016 15:58

          вы сами найдёте #5 на https://github.com/rails/rails/graphs/contributors или скриншот залить?


  1. amstr1k
    28.07.2016 09:52
    -1

    с релизом .net core многое изменится. Скоро будут посты PHP vs .NET


  1. hippoage
    28.07.2016 10:06
    +11

    Очень много всего в кучу собрано, немного прокомментирую.

    Rails в 2016 году уже далеко не инновационный фреймворк:
    1) всё самое интересное реализовали и другие (и это хорошо)
    2) многим проектам на rails уже по многу лет (тому же basecamp),
    тут не до экспериментов уже, скорость адаптации новых идей значительно снижается
    3) веб за это время поменялся, rails зафейлил поддержку этих изменений:
    3.1) веб-сокеты — поддержка заявлена, но лично у меня не взлетело за несколько дней, когда было нужно, пришлось по другому делать
    3.2) api-only server side — только сейчас выпускают rails 5 с этим, но оно какое-то ущербное
    3.3) микросервисы — вроде бы не мешает, но памяти есть слишком много, если дробить на микросервисы

    Если хочется инновационности, то это все же в строну ECMAScript (Meteor.com например) и Golang, PHP тут не при чем.

    Что все еще хорошо в rails?
    1) ActiveRecord — как раз в противоположность твиту выше. Хорошо, когда можно начинать с простого (всё в одном классе), а при необходимости уже рефакторить и выделять новые классы.
    2) Синтаксис руби — всё-таки он один из самых чистых/читабельных. Можно долго рассуждать про IDE, но это помогает скорее в наборе кода, а не читабельности.
    3) Определенный уровень матёрости. Сейчас уже выработаны best practicies и куча библиотек, много материалов для обучения. Все руби библиотеки хорошо работают с rails, проблем в подключении нет. Проблем с поиском библиотеки под задачу не встречал.

    Есть давно известные проблемы:
    1) производительность ruby — они всегда были, с нулевых версий rails, но никогда особо не считалось важным
    2) сложность установки — сейчас при наличии ансиблов с шефами и докерами острота снизалась
    3) острота ножей — требуются лучше, чем хорошие программисты
    4) добавьте свое

    Приоритет рейлс — дать лучшим программистам лучший (приятный и острый) инструмент для производительной (с точки зрения фич) серверной разработки. Рейлс не подходит для «промышленной» разработки (когда команда состоит из одного регуляра и кучки юниоров). Исходя из отдельных фраз, с чем-то подобным столкнулся и автор статьи (например, не должно быть большого количества манки патчей, что-то они явно не так делали).

    Раньше было практически невозможно найти программиста на php (в смысле, именно программиста), а в rails стекались лучшие из php и java. Сейчас уже не так: и в php научились программировать, и в рейлсах слишком много курсов «программист за неделю».


    1. Comedian
      28.07.2016 13:18

      3) веб за это время поменялся, rails зафейлил поддержку этих изменений:
      3.1) веб-сокеты — поддержка заявлена, но лично у меня не взлетело за несколько дней, когда было нужно, пришлось по другому делать

      Какой-то странный аргумент, а у меня сразу все взлетело :)

      3.2) api-only server side — только сейчас выпускают rails 5 с этим, но оно какое-то ущербное

      А почему ущербное? И вообще, только API на рельсах можно было писать и до выхода rails 5

      3.3) микросервисы — вроде бы не мешает, но памяти есть слишком много, если дробить на микросервисы

      Из всех этих утверждений согласен только с 3.3, хотя тут тоже зависит от реализации


  1. slonopotamus
    28.07.2016 10:20
    +3

    Summary: еще один программист посмотрел на мир за пределами своего одного язычка и понял что Ruby ничем существенно не лучше PHP. Но в общем-то и не хуже, поэтому он не готов агитировать за переход на PHP. Если бы он посмотрел немного дальше, то обнаружил бы, что к той же группе относятся Python, Perl и всякие модные node.js.


  1. Stan_1
    28.07.2016 10:25
    +4

    Я в свое время перешел на Rails с PHP по следующим причинам:
    1. Удобство поддержки. Жестко определенная структура папок проекта, нейминга дало мне возможность не только быстро анализировать чужие коды, но и вспоминать через полгода «что ж я тут понаписал». В случае с PHP — развитие моих девелоперских навыков мешало мне понять старый код и требовало времени и усилий разобраться в нем.
    2. Более чистый синтаксис. Видеть User.firstname мне гораздо приятнее и проще для восприятия чем $user->firstname()
    3. Удобное из коробки разделение на среды: development, test, production
    4. Очень четкая и прозрачное разделение на контроллеры, модели, виды.

    Меня периодически друзья просят посмотреть MODx, сайты на Symphony, но для меня это каждый раз сильный стресс. Нет ощущения — что сейчас полезу в проект, и буду знать, где какие части найти. Ну и плюс каждый раз после такого опыта радуюсь, что имею возможность писать именно на Rails или на чистом Ruby (есть собственный framework для CLI-приложений, не использующий Rails).


    1. Assada
      28.07.2016 11:10

      Жестко определенная структура папок проекта,

      Ну не знаю… Кто то диктует вам структуру папок в вашем проекте?

      Более чистый синтаксис. Видеть User.firstname мне гораздо приятнее и проще для восприятия чем $user->firstname()

      Дело привычки же. Да и скобки лишние. А IDE сделает все за вас.

      Очень четкая и прозрачное разделение на контроллеры, модели, виды.

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


      1. Fedcomp
        28.07.2016 11:25

        > Мне кажется в любом языке четкое разделение. Тем более это разделение можно организовать как угодно и тем более это не проблема языка.
        Вы это про inline код в php? многие даже почему то считают это best practices. Мол нам шаблонизатор не нужен, у нас php шаблоны! быстро же!


        1. atc
          28.07.2016 11:47

          А какая разница, на какой технологии выполнен view слой, если речь именно о разделении? Или вы про потенциальную возможность его нарушить, путем написания inline php в шаблонах? В таком случае — это возможно и на шаблонизаторе, достаточно написать хелпер-другой.


        1. noder
          28.07.2016 12:29
          +1

          А в Rails в ERB шаблонах разве не inline ruby код?


          1. kir_vesp
            28.07.2016 13:03

            В ERB — да, но тут скорее речь о том, что логика должна разделяться и для ERB существуют именно хэлперы. Т.е. там изначально предоставлен механизм шаблонизации. Пихать туда логику и кучу кода дело сугубо личное(ну нравится некоторым обмазываться), но порицаемое.


      1. VolCh
        28.07.2016 12:17

        Мне кажется в любом языке четкое разделение.


        Скорее ровно наоборот, ни в одном (мэйнстрим) языке нет такого разделения. Разделения вносят (если вносят) фреймворки, а чаще вообще соглашения разработчиков типа: «пишем по MVC, контроллеры туда, вьюшки сюда, модельки там лежат».


      1. Stan_1
        28.07.2016 16:34

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


        1. MetaDone
          29.07.2016 23:35

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

          в php-проектах так будет с simfony — все будет на своих местах + интерфейсы на каждый чих, что позволит быстро и безболезненно реализовывать кастомный функционал


          1. VolCh
            30.07.2016 14:28

            Справедливости ради, в Symfony настраивается практически всё, включая файловую структуру проекта :)


  1. maxru
    28.07.2016 11:51

    У меня ощущение жёсткого дежавю. То ли перевод этой статьи уже публиковался на хабре, то ли я оригинал читал.

    upd. действительно, читал оригинал


  1. iqiaqqivik
    28.07.2016 11:55
    +5

    Вы должны сначала создать прочную ООП конструкцию, а уже потом упрощать её с помощью DSL.
    Конечно, весь мир в последние 10 лет как раз работает над упрочением ООП конструкций.

    Я сначала хотел надергать очень смешных цитат, но потом решил, что тогда придется каждое предложение из заметки комментировать.


    Поэтому скажу главное: если вглядеться в то, что сейчас делает Piotr Solnica, многократно цитируемый в статье, то это (сюрприз) не переход на PHP. И не переход на Node/Go/Rust/Buzz. И даже не на Elixir, который, надеюсь, постепенно вытеснит рельсы — не потому, что такой прямо ух, а потому, что запускается внутри бима. Так вот, Петр — отчаянный руби-евангелист, и приводить его тезисы против рельс (а часто — и те, кто в теме, прекрасно это знает, — лично против DHH) в качестве аргумента в пользу «руби уже не торт» — может либо очень глупый и несведущий профан, либо злонамеренный подтасовщик. Автор заметки, судя по всему, из первых.


    Руби код в 20 раз лаконичнее и выразительнее подавляющего большинства современных языков. Конкуренты у него в этой области — разве что эрланг и отчасти лисп. И поэтому большинство успешных проектов, которым нужно было быстро взлететь без заметных инвестиций его выбирали. Он не лучше, не хуже, он короче.


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


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


    1. sl_bug
      28.07.2016 12:16

      На тему «прочного ООП» и т.д. есть отличное видео


    1. G-M-A-X
      28.07.2016 21:36

      > Для высоконагруженных систем не годятся ни руби, ни пхп.

      А что годится? Сайты на с++? :)


      1. iqiaqqivik
        29.07.2016 07:05

        Зависит от типа хайлоада. Java годится, если уметь ее готовить. Эрланг, если нет серьезной математики. Микросервисы с очень хорошо продуманной архитектурой.


  1. usawal
    28.07.2016 11:56

    Сложилось впечатление, что автор статьи совсем-совсем новичок в RoR.


  1. G-M-A-X
    28.07.2016 11:56
    +2

    > Разработчики начинают использовать Rails. Обучаются только рельсам. Не могут сделать шага без них. Не могут отличить, что является чистым Ruby, а что является рельсовым монки-патчем. Они не видят чего-то лучше этого, да и не хотят ничего лучше.

    То же самое и с разработчиками на PHP-фреймворках…


    1. VolCh
      28.07.2016 12:24
      +1

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


      1. kir_vesp
        28.07.2016 13:07

        Но это ведь проблемы не языка, а сообщества. Рельсы инструмент, написанный на Руби. Если сделали кривой молоток, то проблема не в стали, а в инструменте и его производителе.


        1. AlexLeonov
          28.07.2016 13:08

          Видимо сообщество всем довольно и ему больше ничего не нужно?
          Чем еще объяснить фактическую монополию Рельс?


          1. kir_vesp
            28.07.2016 13:32

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


            1. VolCh
              28.07.2016 13:55

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


  1. Yeah
    28.07.2016 12:06
    -2

    Та ну вас нафиг, я не буду тут писать комменты


  1. Ogra
    28.07.2016 12:30
    +2

    Раньше все ругали ПХП и думали, что же придет ему на смену — Питон или Руби?
    И никто не угадал — на смену PHP идет JS (скажите спасибо node.js). Я вот даже не знаю, что по этому поводу можно сказать, потому что JS, на мой взгляд, гораздо хуже PHP, как язык.


    1. AlexLeonov
      28.07.2016 12:42
      +1

      Да ничего ему на смену не идёт. На ближайшие лет пять (а это как раз и есть средний срок жизни платформы в IT) PHP прочно занял первое место в вебе (и рвётся в не-веб). Это стало очевидно после выхода PHP 7.

      А лет через пять посмотрим.


      1. iqiaqqivik
        28.07.2016 13:51

        PHP прочно занял первое место в вебе (и рвётся в не-веб)

        Среди кого?


    1. Gugic
      28.07.2016 14:03
      -1

      Со всевозможными штуками, которые дает связка из TypeScript и ES6, javascript становится очень и очень приятным в работе. (Правда мне js и без них нравился)


    1. yul
      28.07.2016 15:55

      Я бы так прямо не сказал, что хуже PHP4-5 (7-й уже не имел возможности заценить), к тому же есть целая тьма языков, компилируемых в js, на любой вкус. Но я больше склоняюсь к elixir как к следующему языку.


    1. saggid
      28.07.2016 23:55
      -1

      Node.js требует более высокого порога входа всё-таки. Асинхрон, сложности с пониманием и продумыванием архитектуры проекта, с которой до сих пор не сложилось каких-то "лучших практик". Нода штука прикольная, но туда просто так залезть, как на территорию PHP — просто не выйдет.


  1. avost
    28.07.2016 13:47
    +6

    >class Foo
    > MINUTES = 5
    >def bar
    > MINUTES.minutes.ago
    > end
    >end
    > Обратите внимание на избыточность, которая содержится в указанном мною моменте в то время когда я назначаю значение переменной.

    Вы серьёзно? Сначала неправильно назвали константу, а потом, внезапно, удивились избыточности. Вам эти MINUTES для чего? Что они означают, для чего вы их используете? Вот так и незывайте. И тогда, сурпрайз(!), ваша программа заговорит (а может запоёт). От VERY_IMPORTANT_DELAY.minutes.after до, в конце-концов, FEW.minutes.ago

    >Так каков же правильный путь для того чтобы сделать 5.minutes.ago в Ruby? Использовать библиотеку Time и сделать это через TimeMath.minutes.decrease(Time.now, 5).

    Лопни мои глаза! А чего ж ваши MINUTES не подставили? Получилось бы вообще зубодробительно — TimeMath.minutes.decrease(Time.now, MINUTES).


  1. craft37
    28.07.2016 15:12
    -1

    Есть надежды на альтернативу Rails, в особенности ActiveRecord.


  1. q1t
    29.07.2016 04:46

    Где то в 2006 первый раз попробовал RoR после покупки книжки по Ruby, с одной стороны все было очень чудесно и волшебно( да же слишком :) ), к сожалению не смог тогда разобраться в самом коде рельс, но свою задачу как фреймворк этот проект выполнял и выполняет на отлично. После было затишье с вебпроектами и затем нужно было переписать PHP проект — я выбрал Го на тот момент, и как мне кажется многое зависит от кода, а не от фреймфорка и/или языка, проект успешно переписал на Го так как был написан отлично, даже с учетом того что я никогда не писал/читал PHP. Хотя вот с Го и вебом не сложилось, видимо привык к full-featured batteries-included™ веб фреймворкам. Опять же сейчас, ради фана так сказать, делаю пару проектов на нынешние популярном Elixir/Phoenix, хотя он тоже уже потихоньку обрастает макросами — хотя код еще пока понятен, по крайней мере для меня. Так же довольно заинтриговал BEAM. В общем к чему все это, PHP Ruby Elixir отличные языки, многое просто зависит от того кто пишет код + для меня лично еще важно сообщество и то что я могу зайти в IRC, Slack, Mailing List и задать свои глупые вопросы и скорее всего найдутся те, кому это не безразлично и помогут. После этого и самому хочется помогать и не холиварить :)


    1. iqiaqqivik
      29.07.2016 07:09

      хотя он тоже уже потихоньку обрастает макросами
      Макросы Elixir — это чистый AST, и это его основная killer feature. Макросы не могут сделать код эликсира менее читаемым по определению. И, для вашего сведения, 95% основных операторов в эликсире (включая case, и unless — макросы.)


      1. q1t
        29.07.2016 07:34

        И, для вашего сведения, 95% основных операторов в эликсире (включая case, и unless — макросы.)

        Да, это вроде бы не секрет, на сайте у них в Getting started про это упоминают, и так же
        Macros should only be used as a last resort. Remember that explicit is better than implicit. Clear code is better than concise code.

        Да и сам фреймворк Phoenix старается быть более явным в этом плане (web/web.ex), есть некоторые моменты которые сложны лично для моего понимания и написаны они с помощью quote unquote. Скорее всего просто у меня мало опыта с этим.


        1. iqiaqqivik
          29.07.2016 08:20

          А я не говорю, что это секрет, я просто удивился фразе «потихоньку обрастает макросами».


          Macros should only be used as a last resort.

          А вот это — чистая защита от нубов. Точно так же, как про руби все пишут: «не используйте манкипатчинг!», а на деле — основной смысл руби в манкипатчинге, просто его нельзя давать в руки обезьянам :)


          В эликсире всегда свежая актуальная версия utf-8 именно потому, что Валим принял гениальное решение: он макросами парсит актуальные файлы консорциума с описанием глифов.


          Для понимания макросов лучше всего не полениться и прочитать Metaprogramming Elixir Криса Мак Корда (создателя Финикса). Все вопросы отпадут.


  1. sl_bug
    29.07.2016 17:52

    Человек который 1.5 года посвятил руби ради рельсов это ни разу не специалист. Я примерно то же самое могу сказать про C# например. Он не очень


  1. kirilloid
    02.08.2016 12:49
    +3

    Привет из мира JavaScript:
    плюрализм это хорошо, говорили они
    будешь учить по фреймворку в неделю, говорили они