Comments 53
Cимволично: комментариев нет - обсуждения тоже: PHP вышел - совсем. Вышел в никуда похоже.
Если звёзды зажигают - значит это кому-то нужно (с) Какое-то развитие идёт, значит и спрос есть?
Но, конечно, фронтенд и гошка у пыхи откусили огромные куски. AI, которые позволяют быстро склепать что-то простое, вообще не зная языка, тоже отняли эту нишу.
А что осталось?
Минорное обновление, с небольшими изменениями, что тут обсуждать 🤷♂️
PHP занят, Интернет крутит
Ничего не произошло
Лучше бы конечно порядок в именах функций навели, да от проклятого $ избавились
Все еще тешу себя надеждой дожить до момента когда это https://wiki.php.net/rfc/namespace-visibility попадает в релиз...
Когда завезут многопоточность и асинхронность?
И еще вопрос: это правда, что php в резюме - это чаще всего черная метка для работодателей?
reactPhp, threading, workerman, fibers, swoole, Laravel Octane... Да уже больше десятка способов как сделать многопоточность в PHP. Вам мало? :)
Что до "черной метки" - вы либо говорите про поиск джуна в стартап, где ещё нет выбранного стэка, либо не понимаете, о чем пишете.
Зависит от того, кого хочет работодатель. Если это что-то связанное с разработкой сайтов - это на мой взгляд, та база, без которой человек в принципе не может считаться вэб разработчиком.
Недавно как раз встретился такой молодой "архитектор" одной известной компании. Когда услышал, что что-то написано на PHP, прямо загоготал, сказал, что думал, что на нём уже никто не пишет, что это не модно. Хотя сам технически был дуб дубом.
В таких компаниях это да, чёрная метка
Кроме того, у каждого языка своя ниша. Для каких прикладных задач вам понадобилась многопоточность и асинхронность?
И еще вопрос: это правда, что php в резюме - это чаще всего черная метка для работодателей?
Не знаю на счет метки, но по опыту могу сказать, что код PHP программистов хуже, чем у Java или C#.
Связываю это с отсутствием строгой типизацией и то что PHP прощает больше ошибок.
Использование картинок для передачи текстовой информации - зло.
Как же они достали уже обратную совместимость ломать. Причём её даже настройками вернуть нельзя.
Не, я, конечно, рад, что теперь у меня постоянно есть новая работа. Но я уже немного замучался переписывать лаконичные сравнения с пустотой, на портянки проверок на наличие массива, индекса в массиве, массива в элементе родительского массива и наличии индекса в подмассиве (повторить несколько раз для каждого уровня вложенности). Причём все эти приседания от кода не зависят, так как данные выдаёт Битрикс и там может быть что угодно.
Так надо уходить от массивов в сторону объектов с типизированными свойствами, тогда и не надо будет 100 проверок.
Далеко не всегда это можно и удобно
Проблема в том, что Битрикс переходит на "новое" ядро с объектами уже скоро 11ый год как. И до сих пор старое апи работает лучше, а использовать его удобнее и код получается короче и нагляднее.
Ну и объекты не спасут вас от бесконечных проверок на null, тогда как в "устаревшем" php я мог сознательно написать if($a=="") и было пофик что там внутри $a - строка, число, null или вообще объект.
А сегодня код падает даже на банальном count($a) потому что переменная, внезапно, not countable - потому что где-то в недрах ядра cms что-то пошло не так и оттуда прилетела какая-то фигня.
Не то чтобы я прям призывал именно так кодить... Но на фоне строгой типизации в других языках это было удобно - особенно в контексте постоянной работы со строками и непредсказуемыми данными (потому что php для этого и создан).
Имхо, сейчас разработчики просто убивают все те преимущества языка, которые и сделали его популярным.
Null coalescence в помощь. Вообще, говоря о развитии php надо иметь в виду, что он популярен в первую очередь благодаря Wordpress. Но в то же время развитие языка идёт за счёт всяких штук вроде Symfony. Вот и получается, что симфони и её производные применяют все новшества языка. А вордпресс и иже с ними изо всех сил пытаются придерживаться старых принципов, лишь добавляя минимальную совместимость с новыми версиями php. Тут очень показателен пример Drupal. Когда они в 8 версии перешли на композер и ООП, начался повсеместный вой, мол как сложно, и популярность его очень сильно стала проседать. Я застал этот переход. И могу сказать, что всё это лишь во благо. Сложные системы стало проектировать намного проще. Популярность падает, растёт качество. И растёт очень сильно. Но основная масса пхпшных сайтов это не использует. И вот глядя на новые фичи языка, а потом глядя на код какого-нибудь Wordpress или Bitrix, я понимаю, что и вордпресс и битрикс — это просто позор индустрии. Они просто взяли в основу старые принципы и ни в какую не хотят развиваться.
Я согласен с тем, что для сложных систем и ООП, и строгая типизация - нужны. Проблема в том, что в значительном количестве мест, где сейчас используется php, это всё просто не нужно. Вообще не нужно. Там, иногда, даже код на функции разбивать - уже избыточно.
Ну и у Wordpress'а те же самые проблемы, что и у Битрикса - всё те же постоянные приседания вокруг null и типов.
Просто потому что php работает с внешними данными, которые вообще неизвестно откуда и как в этот код прилетели. И там может быть что угодно - числа, строки, массивы, объекты, base64, json. И в огромном количестве случаев всё это просто пролетает через код дальше - туда, где оно и будет реально обработано и проверено перед выводом (чтобы всякие CSRF-ошибки не словить).
И без строгой типизации все это довольно красиво программилось. А теперь каждое обращение к любым данным надо огораживать заборчиком из кучи условий и проверок.
Вот конкретно в Битриксе, раньше я мог тупо проверить факт наличия пути к картинке и вывести тег img. А теперь мне надо проверить, что массив - это массив, что он не пуст. Что в нем есть соотв. индекс. Что по этому индексу лежит не пустой массив. И только потом я смогу эту несчастную картинку вывести. А всё потому что картинка эта лежит на третьем-четвертом уровне вложенности в массиве. И может там просто отсутствовать. Или быть кривой и в момент ресайза картинки мы вместо пути к файлу получили что-то не то (null или там пустоту - не суть). И там, где я раньше писал "если элемент массива не пуст, то" - теперь надо делать какую-то огромную КУЧУ приседаний, просто чтобы код внезапно не умирал с концами.
Мало того, что не удобно и раздражает - так оно еще и дико многословно получается. Т.е. там, где была 1 сточка длиной в 10-15 символов - теперь это 5-6 строк, которые в ширину даже на экран не всегда влезают (потому что элементы массивов - строковые и длинные).
Всё это дополнительно посыпано "удобствами" в текстовых редакторах, которые до сих пор с трудом с php работают - особенно, если сравнить с тем же c#.
Но ведь isset($a['b']['c']['d']['e']['f']) отлично работает, независимо от того, на каком уровне вложеннлсти оборвётся цепочка.
Неа. На практике теперь в php 8.1+ оно чаще всего просто падает с ошибкой обращения к несуществующему элементу массива. Причем, так как у нас много уровней вложенности - то проверять на существование теперь надо их все. И нельзя просто так проверить только самый последний в цепочке даже через какой-нить isset() или empty() - потому что оно тоже падает, если на предыдущем уровне нужного элемента массива тоже нет.
Поверх всего это ещё висит вечная ошибка с "Warning: count(): Parameter must be an array or an object that implements Countable" которая напрочь блокирует любой старый код (все версии php ранее 8.1), где в условиях писали что-то типа if(count($a) && ...);.
Самую мякотку сюда добавляет еще и уникально-php-шная работа функций empty() и isset(), которые возвращают разные результаты в зависимости от того, что там внутри переменной - значение, объект, null или явно заданное false. И это тоже надо перепроверять доп. условием, иначе count() после isset() опять-таки может уронить всю страницу сайта...
В общем, я это всё к тому, что в текущем виде получилась как-то неудобная фигня. И определенно нужен какой-то особый синтаксический сахар вводить, чтобы это всё было как-то более удобно писать в коде.
Ненене, это в js оно подобным образом падает, а в php именно isset работает отлично. Вот пример https://onlinephp.io/c/70129
Вообще, чем хорош ООП с автозагрузкрй: находясь в методе объекта у тебя определены только аргументы метода и $this, и всё. Соответственно, тебе не может "прийти что угодно". А когда мы по старинке работаем с инклюдами, то остановив приложение на брейкпоинте, можно увидеть несколько сотен переменных. Так я пришёл к выводу, что в Битриксе xdebug практически бесполезен, т.к. он показывает сразу несколько сотен переменных, и почти все они начинаются с $ar. Пока там что-то найдёшь, уже база отвалится по таймауту.
Ну я ж говорю - это всё замечательно, пока вы работаете с php так же, как вы работаете в других языках, типа того же С#. Т.е. полноценная среда разработки, отладчик и всё такое.
По факту же, как-то так выходит, что когда мы работаем с cms типа того же Битрикса - там не то что про отладчик речи не идет, там даже полноценное автодополнение кода не работает обычно. И про все крутые фичи работы с классами в IDE можно тоже смело забыть. И вообще замечательно, если хотя бы ftp есть, а не приходится файлы править во встроенном редакторе...
Ну т.е. это всё по удобству получается где-то на уровне как если код в Notepad++ править. Подсветка синтаксиса есть, что-то из текущего файла в автодополнении иногда работает - и это всё.
И когда на вот это вот всё притягиваются ещё и классы и, не дай боги, работа с orm - это просто больно. Потому что кодить это приходится вообще на ощупь. И отладчик не подключить - его нет, он выключен. И даже банальный print_r в Битриксе раньше выкидывал хоть и большой массив, но его хотя бы можно было глазами прочитать - а теперь он выкидывает дамп объекта, у которого часть полей рекурсивно ссылаются сами на себя, а часть требуют геттеров-сеттеров, причем неизвестно каких (потому что даже в документации ничего нет - Битрикс вообще очень не любит обновлять свою документацию). И еще он тебе вываливает портянку мегабайт на 30 чистого текста, от которой даже браузер на мощном компе офигевает. У-удобство.
Вот пример https://onlinephp.io/c/70129
Что касается вашего примера, то сломать его легко и просто:
$a = new DateTime();
var_dump(isset($a['b']['c']['d']['e']['f']));
*Fatal error: Uncaught Error: Cannot use object of type DateTime as array in /home/user/scripts/code.php:3*
Просто, в отличие от "полноценных" приложений на том же c# - мы, в общем случае, в принципе никак не контролируем, что там к нам в код прилетает. Особенно когда у нас это всё завёрнуто в большую cms.
И там, где раньше php был толерантным к кривым данным и просто работал, теперь необходимо делать кучу проверок. И это, ну, неудобно. Потому что, они, ну, не очень-то и нужны - за правильность данных отвечает сама cms, там точно ничего страшного не прилетит. А если тип будет не тот, то php сам автоматом это сконвертирует туда-сюда правильно в большинстве случаев - ну т.е. конвертировал. А теперь надо делать это тоже самому, вручную.
Ну собственно поэтому мне и хватило одного раза поработать с Битрикс. Больше ни за что в жизни.
аналогично. Купил, попробовал, протрахался пару дней, пытаясь сделать довольно простые вещи, положил на полку и больше никогда не возвращался.
А что скажете про NuSphere PhpED? Вроде достойная среда и дополнения работают и поиск определения и отладчик свой встроенные. Правда сама среда только windows но отладчик бежит удаленно буквально везде.
Что касается вашего примера, то сломать его легко и просто:
Как говорится "Cдуру можно и Си сломать". Если вам так нравится анархия классического php, то зачем обновляетесь? А если обновляетесь, то почему не пишите правильный код и не изолируете свои части кода?
А для говнокода и веселья всегда можно поставить error_reporting(0) и глупо хихикать.
Как говорится "Cдуру можно и Си сломать".
Ну так проблема не в том, что "сдуру", а в том, что никакого контроля за тем, что выдаст cms у нас нет. Сегодня там одно, завтра они что-то поменяли, мы битрикс обновили и сайт лёг - причем иногда вообще весь.
Если вам так нравится анархия классического php, то зачем обновляетесь?
Обновляемся не от хорошей жизни, а потому что Битрикс обновлять надо. А его обновлять надо, потому что уязвимости + он безальтернативно теперь требует конкретные версии php и выбора, что ставить, уже по сути и нет.
А если обновляетесь, то почему не пишите правильный код и не изолируете свои части кода?
Потому что это Битрикс. Потому что там ВЕСЬ код вот так писался уже лет двадцать подряд - то есть у нас огромная куча унаследованного кода, который физически невозможно корректно переделать. Вы вообще объемы представляете? Базовая установка магазина на Битриксе - это 80 ТЫСЯЧ файлов. Плюс ещё сам шаблон сайта - это тоже несколько сотен, если не тысяча файлов, равномерно размазанных по всему диску.
И когда после обновления сайт ложится (весь или частично), то ко мне прибегает очередной клиент с криками "всё пропало!!!" и надо это вот как-то чинить, причем срочно. А там, бонусом, поверх битрикса еще какой-нить шаблон могли накатить, типа Аспро (а он сам по себе размерами как ещё один Битрикс), который потом несколько лет дописывали сами - и его теперь невозможно обновить, потому что вообще никто уже не помнит и не знает что там и где в нём дописывалось. И там старый код, который падает просто везде - в самых неожиданных местах. Причем одна страница товара работает нормально, а другая - падает, потому что там картинки нет. Или какое-то поле не заполнено было - причем необязательное.
И таких сайтов, замечу - большинство. Не, ну может где-то и есть нормальные - но такие ко мне не приходят, приходят вот эти.
А для говнокода и веселья всегда можно поставить error_reporting(0) и глупо хихикать.
Разработчики php теперь умные и теперь грохают всё сразу, а не как раньше - "пищит, но работает".
А при чем здесь язык? Вы написали плохой код на одной из самых проблемных CMS. При этом звучит так, что не хотите поддерживать продукт.
Да, быстрый и дешевый MVP, не требует ресурсов на старте, но потребует больше на будущие апдейты и поддержку.
А можно сразу попытаться создать более устойчивую архитектуру и надежный код, тогда миграция с 5.4 до 8.5 пройдет легче.
Ну или можно просто забить на обновления, значит язык продукта это не php, а его подмножество, версии 5.4.
Стоп. Этот плохой код написал не я. И написан он был очень давно - 5, иногда даже 10 лет назад. Еще во времена php 5.4-5.6 или 7.х. И в то время этот код был полностью в рамках той версии языка.
А теперь это всё, внезапно, разработчики языка просто взяли и сломали - причем даже не оставив возможности как-то вернуть "как было" хотя бы даже и на время.
Вы никогда не правили огромный старый код (который вы раньше даже в глаза не видели!) в режиме ошпаренной кошки и когда "надо еще вчера"? Попробуйте, просто незабываемые ощущения.
А можно сразу попытаться создать более устойчивую архитектуру и надежный код, тогда миграция с 5.4 до 8.5 пройдет легче.
Можно, да. Но тогда надо или полностью всё самому писать - или брать какой-то фреймворк. Но лет через 10 вы всё равно придёте к тому же самому - "чтобы обновить на новый php надо переписать вообще всё".
Ну или можно просто забить на обновления, значит язык продукта это не php, а его подмножество, версии 5.4.
И потом к вам прилетит очередная вирусня и будет ещё хуже.
А теперь это всё, внезапно, разработчики языка просто взяли и сломали
Не "внезапно". От объявления того, что какой-то механизм языка будет в будущем удалён, до его фактического удаления проходит более чем достаточно времени. И если правки в любой проект не были внесены вовремя, виноваты в этом не разработчики PHP, а разработчики, занимающиеся развитием проекта и не пожелавшие вовремя внести небольшие изменения в код. Последней же версией, при переходе на которую могла потребоваться радикальная переделка старого кода, была PHP 5.4 (отказ от совместимости с PHP 4).
P.S. Пример JavaScript, в котором "совместимость" возвели в религию, показывает, что это приводит лишь к бессмысленному раздуванию языка и тиражированию низкокачественного кода.
P.P.S. В современном мире несовместимости между версиями языка - не исключение из правил, а норма. С которой приходится сталкиваться даже в предельно стабильном Go.
И если правки в любой проект не были внесены вовремя, виноваты в этом не разработчики PHP, а разработчики, занимающиеся развитием проекта и не пожелавшие вовремя внести небольшие изменения в код.
Ну да. В идеальном мире, в больших проектах. А если это типичный "магазинчик на Битриксе", то там иногда даже постоянных разработчиков нет. Просто раз в полгода-год кого-то находят, он реализует накопившиеся желания клиента (чаще всего - максимально через одно место) и на этом про код все опять забывают.
Естественно, что в один "прекрасный" момент клиент решает обновиться - его же Битрикс предупреждает постоянно, что пора. Переключает версию php, нормально обновляется - он же в админке, там всё хорошо. И тут-то и наступает ж... - потому что публичная часть уже перестала нормально работать, а откатывать обновления Битрикс не умеет до сих пор (молодой же проект, всего 20 лет ему!). Бэкапов тоже обычно нет как класса.
И вот тут прихожу я - буквально к руинам...
Последней же версией, при переходе на которую могла потребоваться радикальная переделка старого кода, была PHP 5.4
Ага. Старый код переставал работать при переходе
5.4 -> 5.6
5.6 -> 7.0
7.1 -> 7.2
7.2 -> 7.3
7.3 -> 8.0
8.0 -> 8.2
Тут уже буквально можно на пальцах одной руки посчитать те версии, которые не ломали старый код :)
Пример JavaScript, в котором "совместимость" возвели в религию, показывает, что это приводит лишь к бессмысленному раздуванию языка и тиражированию низкокачественного кода.
Если люди хотят писать некачественный код - они будут это делать на любом языке несмотря на любые ограничения. Ладно бы php/js были бы компилируемыми - сделал раз и оно будет работать всегда...
В современном мире несовместимости между версиями языка - не исключение из правил, а норма.
Это печально все-таки. Ну я понимаю что прогресс и всё такое. Но как-то всё-таки хотелось бы иметь соотв. настройки, чтобы совместимость не ломалась бы. Потому что даже в C++ проблемы, если взять код, которому лет 10-20 и попытаться его собрать на свежей версии компилятора.
rector php вам в помощь
Тут очень показателен пример Drupal. Когда они в 8 версии перешли на композер и ООП, начался повсеместный вой, мол как сложно, и популярность его очень сильно стала проседать. Я застал этот переход. И могу сказать, что всё это лишь во благо.
+/- такая же история с Joomla. Без знания ООП в Joomla 4 - Joomla 6 уже никуда. Без IDE уже никуда, в Notepad++ можно написать что-то только зная наизусть половину неймспейсов или зная откуда их вытащить )
PHP всё больше тянется к «современному синтаксису» с одной стороны, а с другой список BC-ломающих изменений снова напоминает, сколько у всех легаси на старых версиях. Очень интересно, приживётся ли pipe в кодстайлах крупных команд или останется нишевой игрушкой энтузиастов.
ИМХО, pipe станет более востребован, когда в 8.6 появится частичное применение функций https://wiki.php.net/rfc/partial_function_application_v2. А до тех пор каналы (или трубы?) безусловно упростят код в некоторых случаях, но не станут повсеместно используемым механизмом.
добавлен оператор "|>" (pipe)
П - приоритеты
работал с довольно большим количеством интересных и не очень проектов. По скорости разработки с пхп не сравнится ничто. ближайший аналог - нода, страдает от детских болячек и незрелого комьюнити джава скрипт программистов, функциональный подход откровенная слабость. тайп скрипт нелепая попытка подражать шарпам, хотя сам js меня вполне устраивает. пхп за последние годы вбирает в себя лучшие практики и при этом остаётся верен старшему брату, эталону - крестам. есть асинхронность, мультитрединг, параллелизм, корутины. я писал парсеры логов для хайлоад систем которые работали быстрее аналогов на Go и при этом были несравнимо проще. но вот с популярными cms в работе я никогда не сталкивался, возможно поэтому я свободен от негативных коннотаций. а вот с битриксом работать приходилось, и это зло, так даже японцы не издевались. и ещё кое что - за последнее десятилетие в разных языках и стеках конкретно на пхп я ниразу не столкнулся с проблемами с обратной совместимостью, разве что переход на PDO с mysql. задумайтесь над тем что вы делаете. возможно причина не там где вы её ищете.
Вышел PHP 8.5