Ну и про «несколько десятков php-шников, неспособных установить php-fpm за день» — у вас явный логический провал, особенно если учесть, что сам процесс установки — всего лишь несколько консольных команд. Из чего можно вывести следующие варианты:
1) им не нужен php-fpm и они его никогда его не устанавливали
2) не знают linux и не имеют опыта работы в окружении, отличном от shared хостинга
3) новички, не умеющие в чтение документации и английский язык
Все три пункта совершенно невозможны для php программиста, пишущего под тот или иной фреймворк, следовательно ваше утверждение в принципе некорректно.
>В PHP модно кричать что мы реализовали AR, но там даже десятой доли того что есть в рельсах не реализовано, попробуйте выполнить подзапрос с фильтрацией в любом PHP ORM, например, подобия которых в php фреймворках нет и непонятно будут ли.
Простите, а в чем проблема? В среднестатистическом AR (для примера возьмем тот, что в Yii2) с подзапросами работать более чем удобно, любой relation легко фильтруется в анонимных функциях, просто приведу пару строк из документации:
Автор делает реверансы в сторону функциональных языков программирование (именно такой язык получится, если от среднестатистической java отпилить «лишние возможности»), но забывает рассказать о минусах функциональных языков. Статья очевидный наброс.
А какая разница, на какой технологии выполнен view слой, если речь именно о разделении? Или вы про потенциальную возможность его нарушить, путем написания inline php в шаблонах? В таком случае — это возможно и на шаблонизаторе, достаточно написать хелпер-другой.
Можно сделать .then внутри метода и вернуть promise, с точки зрения читабельности кода это ничего не испортит. Очевидно, что никакая декомпозиция полностью не спасет от callback\promise в асинхронном коде, но по крайней мере при должном уровне декомпозиции — они не доставят проблем.
Одно простое ветвление можно аккуратно поместить в тернарник, а все что сложнее — наверное заслуживает располагаться в именованом методе\функции, что позволит так же отдельно тестировать этот участок кода и иметь в нем синхронный вход.
Попробовал представить случай — где потребовались бы размещать относительно сложный код в анонимных фунциях внутри promise — и не смог, при нормальной декомпозиции системы это кажется редким случаем.
Вообще в объектной парадигме большое количество ветвлений — частый признак не слишком хорошей декомпозиции задачи и предполагается, что таких мест с обилием ветвлений и тем более асинхронщиной — должно быть исчезающе мало. Вариант с рефакторингом кажется в этом смысле вполне логичным.
Им весьма непросто пользоваться по нескольким причинам, первая из которых — отсутствие стрелочных функций (js или java, подойдет любой вариант), вторая — невозможность аккуратно выстраивать цепочки для обработки потока данных.
Наверняка имеются соответствующие библиотеки\инструменты, но все же это не так удобно, по сравнению со стандартными средствами языка.
Я не сомневаюсь, что со всем этим можно жить (хотя бы потому что сам долго пишу на js), но с современным пониманием ооп — javascript имплементация стыкуется слабо, эдакая «неизвестная земля» на фоне имплементаций в остальных языках.
> но вечные нападки неосиляторов со статическим ООП(как будто JS отменял ООП или невозможно прибить все типы гвоздями при необходимости
Так JS не предоставляет почти никаких инструментов, так характерных для ооп языков. Просто пройдусь по списку:
1) Автоматический рефакторинг — нет или очень слабый (для этого IDE должна хорошо понимать код)
2) Инкапсуляция — private\protected в es6 классах можно реализовать только окольными путями
3) Полиморфизм — интерфейсов нет и единственное что мы можем — это намекнуть на структуру ожидаемого объекта другому программисту в jsdoc
4) DI\IoC — никаких constructor injection, только хардкор
5) Возможность не держать в голове типы всех переменных в области видимости — тоже ожидаемо нет
6) Grasp паттерны:
* отделение асинхронного кода от синхронного (контроллер) — сложно и часто не имеет смысла, потому что асинхронно все
* слабое зацепление — сложно, потому что в большинстве случаев слишком многие подробности объекта доступны извне
* устойчивый к изменениям — нет, потому что у нас отсутствует интерфейс, где мы можем задекларировать api
Вот и получается, что ооп как-бы есть, но одновременно его как-бы нет.
Асинхронная работа доступна сейчас практически на любых платформах, будь то php\phython\java\langname, достаточно затянуть в проект очередной reactphp\akka. То есть с этой точки зрения js\node ничего исключительного на данный момент времени предложить не смогут.
С другой стороны js\node могут привлекать существенно лучшим дизайном языка в мелочах, чем у того же php: те же map\reduce, методы строк и массивов существенно упрощают жизнь по сравнению с развесистыми циклами и преобразованиями на php.
Вот про дебаг не скажите, скорость нахождения очень сильно зависит от знания внутренностей используемых библиотек\фреймворков и платформ и от умения пользоваться специализированными инструментами или подходами. Кто быстрее найдет ошибку, опытный человек с grep\awk\sed и знаниями о внутреннем устройстве системы, или сферический человек с высоким IQ? Что-то мне подсказывает, что именно первый, ибо знания помогают срезать углы и не заниматься интеллектуальным брутфорсом.
Аргумент, что большее IQ в большинстве случаев означает большие проф. знания принять не смогу, так как уровень и набор навыков сугубо индивидуальны даже среди разработчиков на одной платформе\стеке. При чем существенное влияние на этот уровень оказывают такие факторы как интерес к теме\мотивация, например как можно сравнивать двух соискателей, один из которых интересуется конкурентными системами, а второй на защитном программировании?
Предвидя финал нашего спора — каждый останется при своем мнении. Я думаю, что этот абстрактный коэффициент не имеет особого\решающего значения при таком обилии крайне значимых факторов.
Вот видите, а предполагается, что это необходимо решать на собеседовании, в нервной недружелюбной обстановке.
Вопросы по технической части\задачи на кодирование — на мой взгляд куда адекватнее отражают реальное положение дел по сравнению c iq тестами\загадками про круглые люки, они по крайней мере привычны и понятны любому специалисту.
Это все весьма относительно, пока мы с вами спорили — ради интереса посмотрел два IQ теста, первый выдал 20, второй 40 баллов. Вероятно я клинический идиот, или просто не умею решать эти тесты. Выберите по вкусу.
Не уверен, что корректно приводить в пример человека с IQ 85 (у которого явно существуют какие-то проблемы), когда вопрос был задан скорее про небольшие колебания IQ (в пределах 20 баллов) + индивидуальные особенности\навыки\склад ума, которые внезапно могут быть более приоритетны для конкретной вакансии.
Вполне логично, что человек с высоким IQ (который символизирует скорость\способность к вычислением\сопоставлению\логике) более чем успешно справляется с математическими задачами, но не все из подобных задач состоит. Например есть ли связь в умении предугадать, в каких местах и как система должна в дальнейшем расширяться и IQ. А у способности быстро и точно находить информацию или писать максимально понятный окружающим код? Если бы IQ был действительно важен — при чем напрямую, а не в косвенных проявлениях — мы бы видели его упоминания в каждой первой вакансии или статье, но это не так.
В общем я за проверку теорий практикой и точно первое не сходится со вторым.
Ну и относительно бухгалтера, существуют программисты\администраторы, не способные решить задачу Эйнштейна в уме, но почему-то задача «разобраться в софте X» для них не является вызовом (подобные задачи они решают регулярно).
Получается, что важным в данном случае является не формальный IQ, а технический склад ума?
Тогда почему отсутствует статистика, что программисты-олимпиадники быстрее прочих решают текущие задачи, не связанные напрямую с алгоритмизацией\оптимизацией? Либо другая подобная статистика.
Те факты, что вы привели в пример — невозможно принять за доказательства, так как самыми успешными в данном случае могли оказаться, например брюнеты. Теоретически это возможно, но стоит ли из этого делать выводы, что брюнеты в целом лучше справляются с работой?
Если эффективность программиста на самом деле привязана к IQ — то почему последний не является главным параметром по приему на работу? Почему архитектором\тимлидом становится более опытные, а не те, чей IQ длиннее?
Вообще это было бы забавно, обращаешься к копании-аутсорсеру и арендуешь 3000 единиц IQ на работу над стартапом.
1) им не нужен php-fpm и они его никогда его не устанавливали
2) не знают linux и не имеют опыта работы в окружении, отличном от shared хостинга
3) новички, не умеющие в чтение документации и английский язык
Все три пункта совершенно невозможны для php программиста, пишущего под тот или иной фреймворк, следовательно ваше утверждение в принципе некорректно.
Простите, а в чем проблема? В среднестатистическом AR (для примера возьмем тот, что в Yii2) с подзапросами работать более чем удобно, любой relation легко фильтруется в анонимных функциях, просто приведу пару строк из документации:
$customers = Customer::find()->joinWith([
'orders' => function ($query) {
$query->andWhere(['>', 'subtotal', 100]);
},
])->all();
Попробовал представить случай — где потребовались бы размещать относительно сложный код в анонимных фунциях внутри promise — и не смог, при нормальной декомпозиции системы это кажется редким случаем.
А у вас есть чему поучиться, спасибо за отличную метрику качества кода.
Наверняка имеются соответствующие библиотеки\инструменты, но все же это не так удобно, по сравнению со стандартными средствами языка.
Так JS не предоставляет почти никаких инструментов, так характерных для ооп языков. Просто пройдусь по списку:
1) Автоматический рефакторинг — нет или очень слабый (для этого IDE должна хорошо понимать код)
2) Инкапсуляция — private\protected в es6 классах можно реализовать только окольными путями
3) Полиморфизм — интерфейсов нет и единственное что мы можем — это намекнуть на структуру ожидаемого объекта другому программисту в jsdoc
4) DI\IoC — никаких constructor injection, только хардкор
5) Возможность не держать в голове типы всех переменных в области видимости — тоже ожидаемо нет
6) Grasp паттерны:
* отделение асинхронного кода от синхронного (контроллер) — сложно и часто не имеет смысла, потому что асинхронно все
* слабое зацепление — сложно, потому что в большинстве случаев слишком многие подробности объекта доступны извне
* устойчивый к изменениям — нет, потому что у нас отсутствует интерфейс, где мы можем задекларировать api
Вот и получается, что ооп как-бы есть, но одновременно его как-бы нет.
С другой стороны js\node могут привлекать существенно лучшим дизайном языка в мелочах, чем у того же php: те же map\reduce, методы строк и массивов существенно упрощают жизнь по сравнению с развесистыми циклами и преобразованиями на php.
Аргумент, что большее IQ в большинстве случаев означает большие проф. знания принять не смогу, так как уровень и набор навыков сугубо индивидуальны даже среди разработчиков на одной платформе\стеке. При чем существенное влияние на этот уровень оказывают такие факторы как интерес к теме\мотивация, например как можно сравнивать двух соискателей, один из которых интересуется конкурентными системами, а второй на защитном программировании?
Предвидя финал нашего спора — каждый останется при своем мнении. Я думаю, что этот абстрактный коэффициент не имеет особого\решающего значения при таком обилии крайне значимых факторов.
Вопросы по технической части\задачи на кодирование — на мой взгляд куда адекватнее отражают реальное положение дел по сравнению c iq тестами\загадками про круглые люки, они по крайней мере привычны и понятны любому специалисту.
В общем я за проверку теорий практикой и точно первое не сходится со вторым.
Получается, что важным в данном случае является не формальный IQ, а технический склад ума?
Те факты, что вы привели в пример — невозможно принять за доказательства, так как самыми успешными в данном случае могли оказаться, например брюнеты. Теоретически это возможно, но стоит ли из этого делать выводы, что брюнеты в целом лучше справляются с работой?
Вообще это было бы забавно, обращаешься к копании-аутсорсеру и арендуешь 3000 единиц IQ на работу над стартапом.