После года разработки представлен релиз языка программирования PHP 8.4. Новая ветка включает серию новых возможностей, а также несколько изменений, нарушающих совместимость...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62269
Чем-то он уже напоминает C#.
Слишком много денежного фетишизма в синтаксисе языка.
Еще убрать немного лишнего, и будет красиво.
C$ ?
> C$ ?И лозунг make C great again!
Так это ещё с перла пошло называть переменные так.
Когда то и верить в плоскую землю было нормой.
А раз уж все равно совместимость поломали, делая шаг вперед, так не мелочились бы. Похерили бы и рудитменты. И написали б конвертер исходников, на php же подобное элегантно можно написать.
> это ещё с перла пошло такВ начале был баш!
> Еще убрать немного лишнего, и будет красиво.Не будет.
из обычного, простого языка сделали какое-то недоразумение, изменения ради изменений
Сделали нормальный язык, а не мама, я сделяль сайт.
Как будто его переориентировали на другие задачи. Он и раньше был относительно нормальным для своих задач.
есть опыт написания DHCP сервера на PHP
Есть) Отлично работает и на 5 версии, и на 7 и на 8) но другой вопрос зачем использовать то, что не нужно использовать.
На брейнфаке тоже можно написать.
Но зачем?
> мама, я сделяль сайтЧто в этом плохого? В то время можно было в одиночку целый сайт сделать и даже зарабатывать на посетителях, причем хотя его на бесплатном хостинге. Знал чела, который в 13 сделал сайт на пхп как раз, кажется в году 2006, в 2010 там посещаемость была уже сотни тысяч, сайт называть не буду, но многие около айтишники хоть раз да натыкались на него.
anime.su?
Ты форумом ошибся кажись.
>Что в этом плохого?То, что код тех сайтов является кучей костылей, где вёрстка перемешана с логикой, простейшие вещи переизобретаются на каждой странице, и целой пачке уязвимостей.
>В то время можно было в одиночку целый сайт сделать и даже зарабатывать на посетителях, причем хотя его на бесплатном хостинге.А в чём проблема сейчас, на современном php вместе с фреймворками сделать в одиночку целый сайт? Сейчас, даже проще, учитывая, что на php можно писать не только веб формочки, но и высоконагруженные сервисы.
Это простота и была главной фичей PHP. Как "нормальный" язык у него нет будущего, сейчас ченжлоги выглядят как ченжлоги питона 10-летней давности или ченжлоги джавы 20-летней, это просто смешно. Все чем они сейчас занимаются это пытаются удержать существующую базу пользователей от перехода на другие языки, но это тупиковый путь.
Да пусть ломают к херам !
Чес быстрее всех задолбают своим сахаром, тем быстрее появиться новый РНР
так у нас есть уже один C#, и вот - чо?
у пхп уже есть своя ниша, в которой он хорош, так же как существующие другие языки, которые занимают свои ниши. Соперничать с ними, переусложняя язык ненужным синтаксическим сахаром - плохая идея. Своими действиями они отталкивают часть прежних пользователей языка и не дают ничего нового потенциальным новым пользователя.в итоге есть шанс остаться у разбитого корыта.
>у пхп уже есть своя ниша, в которой он хорош, так же как существующие другие языки, которые занимают свои ниши. Соперничать с ними, переусложняя язык ненужным синтаксическим сахаром - плохая идея.Ниша php это сайты, и для них он подходит всё лучше и лучше. А вот сайты на старых версиях пхп трогать страшно, они разваливаются от малейшего чиха.
работает? не трогай!
так видимо в этом и цель !а учитывая то, что и другие языки уродуются тем же "сахаром",похоже на то что все яп-ы подгоняются под ОДИН, универсальный, причём слабо понятный для человека, но прекрасно понимаемый ИИ
Вообще-то новые версии практически не мешают писать в стиле РНР4. Другое дело, что написанный в таком стиле сайт, скорее всего, будет нежизнеспособен или, как минимум, непригоден к развитию.Пых за последние годы нахватался практик у соседей и стал, как Кресты, мультипарадигменным.
Хочешь - говнокодь. Хочешь - выстраивай вменяемую, поддерживаемую, безопасную архитектуру.
Это совершенно нормальное развитие вслед за изменяющимися требованиями среды, в которой язык может быть применен. Обеспечивающее Пыху высокую популярность вопреки вою хейтеров.
Говно он был. Сейчас становится более-менее нормальным. А из-за строгих типов даже лучше Пайтона в этом отношении.
Это обычная ситуация для любого языка, который продолжает развиваться. Он начиается обрастать сахаром и доп.функиционалом. Из-за этого кажется монструозным.
это ошибочный взгляд, что если в язык не добавляют новых фич - он умирает. Но из-за таких взглядов и происходят эти изменения ради изменений.
Всё ради того, чтобы не улучшать питон или не заниматься фриганством.
PHP десятилетиями хоронят, а он не просто жив, но и развивается.
Это не развитие. Это отчаянные попытки вернуть тех, кто сваливал с него на протяжение последнего десятилетия. Типа "смотрите, у нас теперь тоже есть get/set-обработчики свойств, все как у больших дядей; вернитесь позязя... -_-"
Представьте себе, есть проекты, которые живут и развиваются десятилетиями, без ежегодного переписывания всего кода на язык, который сегодня в тренде. Вот для тех, кто по тем или иным причинам лет 10-15 назад выбрал PHP (а для ряда проектов это было вполне разумное решение), это всё очень полезно.Сейчас, конечно, начинать новый проект на PHP я не знаю зачем.
А на чём стоит начинать и почему? Под проектом конечно же подразумевается очередной сайтик. PHP вдруг стал плохо подходить для очередного сайтика?
> Представьте себе, есть проекты, которые живут и развиваются десятилетиями, без ежегодного
> переписывания всего кодау меня для вас хреновая новость:
включает серию новых возможностей, а также несколько изменений, нарушающих совместимость.и такая дребедень - каждый день. А ваш php5.4 (несовместимый с 5.3! Про историю с 5.2 замнем за давностию лет) не поддерживается. И 7 не поддерживается. И скоро с нытьем про нехватку рук, энтузиазма и туалетной бумаги - перестанут и 8.0-8.3
Ну и как себя чувствует проект который десятилетие нужно именно что ежегодно переписывать чтоб вообще работало - на том же самом (но не совсем) языке?
Переходить на 5.4 с 5.3 в свое время за отсутствием хорошего инструментария было болезненно. Современные IDE и линтеры это всё упрощают - можно на 99% проанализировать на совместимость статически и исправить несовместимости (часто даже автоматическим рефакторингом, как в случае с ?Type = null), а остальное словится при запуске test suite. Сравнивать это с переписыванием на другой язык даже не смешно.
угу-угу, астролябия ж сама все меряет.А по факту у тебя проект десятилетнего возраста (то есть уже пару поколений разработчиков пережил и никто из живущих не в курсе, что там и зачем) который проще переписать заново чем поштучно выковыривать все несовместимости. И да, при этом по сути будет все равно, на тот же язык или на отдаленно похожий. Все равно это реверс требований и рефакторинг с нуля.
Даже проще на совсем другой инструментарий, поскольку делать это ты очевидно будешь - по частям. А два php всяко хуже чем php и какая-нибудь нода.
Старый проект на старом смарти старыми гвоздям прибитый к старому пхп (как раз типа 5.3) и старому центосу проще обмазать сурикатой и оставить как есть, чем что-то переписывать. особенно если проект приносит стабильный доход и перспектив роста у него нет. IMHO.Каждая новая версия пхп - это боль для поддержки. Имхо, новости надо компоновать не так. Сначала надо писать про объявленные устаревшими, сломанные и пр. изменившие своё поведения функции, а потом про всякое ненужное.
ну вот, хоть один тут в курсе.Но я тебе хуже историю расскажу - у меня проект прибитый к "старому" php. Аж 7.4 - вот какому старому. (перенос кода с 5.4 на 7 потребовал несколько месяцев полной загрузки команды, но это в блаженные до...э...свошные годы. Когда у конторы был запас прочности, не говоря уже о запасе банально денег, т.е. проблемы закидали телами.)
Перспектив рос... я хз что там может расти, а требования бизнеса - они появляются постоянно. И разработчики, вот ведь удивительно - по уши заняты их реализацией (иначе хрен бы кто расщедрился на их зарплаты). Вот так вот взять и пол-годика не поработать... в смысле, как раз ударно потрудиться но бизнес-задачам отвечать "не время еще, подождите", разумеется, не поймут-с, и как бы не уволили всю стаю и не закрыли отдел целиком, "раз они не делают там нифига".
> Каждая новая версия пхп - это боль для поддержки.
угу.
Поэтому выбор этой платформы не для одноразовых поделок сдал-получил-снял с карты и заблокировал симку - был ошибкой еще в 2005м (та самая история с foreach в minor update) а в 2024м это хуже чем ошибка - это фатальная глупость.
Ну хз. А где иначе? На старой яве плюс-минус такое же. Т.е. вроде есть у нас уже стабильная как кость мамотнта 8LTS, но недавно я узнал что u345 - это последнее с чем работает наш такой же стабильный как кость мамонта проект. Что-то деприкейтнули :) На новой яве всё веселее.Питон? Ну как-бы то же самое всегда и везде. Просто оно всё в тренде. Было же фейковое интервью Страуструпа главным выводом которого было то что экосистема должна быть такой, чтобы люди со скиллами всегда были в чести и в небольшом дефиците. Поэтому кобол нафиг, а сиплюсплюс в массы.
А разговоры о том что фронт можно написать на чем угодно скриптовом а бэк на чем угодно нормальном - это же очень общие разговоры. Потому что фронт от чего-то пишется на amgular, cocoon или еще какой забористой дури с другого полюса типа react native, а бэк пишется так что проблемы от чего-то не решаются.
Так может пхп5.3, смарти 3 и суриката - не такой уж плохой вариант? Это даже не имхо, это скорее иллюстрация того что серебряной пули нет.
> Так может пхп5.3, смарти 3 и суриката - не такой уж плохой вариант?у тебя есть для начала хотя бы просто список cve (и уязвимостей не оформленых как cve потому что всем до ...) в этой 5.3? А если найдут? А патчить без конца ты сам собираешься?
Писки твоего суриката - кто должен слушать, может - разработчики? (МВАХАХАХАХА!)
Или этот, как его... девляпс, во?!Это даже для хобби-проекта не годится из-за пункта 1 (я не хочу вечно патчить хобби-проект). А для промышленной эксплуатации - чур без меня, чур.
> Писки твоего суриката - кто должен слушать, может - разработчики? (МВАХАХАХАХА!)
> Или этот, как его... девляпс, во?!Ну, от школьников суриката/снорт вполне себе защищает в автомате.
> Это даже для хобби-проекта не годится из-за пункта 1 (я не хочу
> вечно патчить хобби-проект). А для промышленной эксплуатации - чур без меня,
> чур.Это зрелый копро.. корпоративный сервис. Закопать нельзя отключить. Ресурсы есть только на "редактора портала" и сурикату. О поддержке речи не идёт - я подпорочку поставил и ушел.
А, ну такой и поломают - не жалко. Восстановишь с дискеточки и дальше поедешь, а суриката через месяцок обновит свои правила и оно может даже перестанет так быть ломабельно. И вроде ты даже герой а не наоборот.А вот повторить судьбу mts-cloud или кивятника (а ведь эти еще - профессионалы именно в IT и из лучших) - так себе этап в карьере.
> А, ну такой и поломают - не жалко. Восстановишь с дискеточки и
> дальше поедешь, а суриката через месяцок обновит свои правила и оно
> может даже перестанет так быть ломабельно. И вроде ты даже герой
> а не наоборот.Так да, всё так. А писки сурикаты слушает тот же специалист что и писки заббикса. В итоге более или менее нормальный бека план и более или менее адекватный анализ атак позволяют эксплуатировать зрелое корпоративное решение. И ладо бы только пхп, он хотя бы новый есть. А ведь есть много всего, чего нового нет.
>перенос кода с 5.4 на 7 потребовал несколько месяцев полной загрузки командыЕсли у вас так много кода или он так ужасно написан, то необходимо закладывать в смету бюджет для поддержки всего этого в актуальном состоянии.
>Вот так вот взять и пол-годика не поработать... в смысле, как раз ударно потрудиться но бизнес-задачам отвечать "не время еще, подождите"Бизнес не умеет программировать. И ваша же задача донести до бизнеса, что проект нужно актуализировать. Поскольку бизнес, если его не предупреждать, может и лампочки не закупать, и в один день офис погрузится во мрак. Это не говоря уже про то, что в современных условиях обновлением можно заниматься параллельно с разработкой, периодически синхронизируя ветки.
> Если у вас так много кода или он так ужасно написан, то необходимо закладывать в смету бюджет
> для поддержки всего этого в актуальном состоянии.мы - расходная статья для бизнеса. Мы не можем транжирить его деньги просто так, без объяснений на что.
> Бизнес не умеет программировать.
Так он нанял тех кто умеет. И теперь говорит им - "программирывовай!" - то, что он хочет.
> что проект нужно актуализировать
кому нужно-то? Вот именно...
И хорошо если прокатит "Все так делают!"
А вдруг кто-то умный попадется? И спросит - зачем ты выбрал инструмент который на пустом месте без конца "актуализируешь", вместо работы (подразумевая- на него)? И нельзя ли нанять вместо тебя такого который выберет что-то надежное?
> перенос кода с 5.4 на 7 потребовал несколько месяцев полной загрузки командыМожно примеры проблем, штуки три-четыре? Кроме уже упомянутого foreach?
Почему спрашиваю? Есть гипотеза (без обид), что все (ну подавляющее большинство) несовместимости вызваны стремлением не задачу решить, а впендюрить в проект максимальное количество только что реализованных в последней версии похапе возможностей (для резюме, для собеседований).
У меня есть относительно небольшой проект (не сайт), пишу в стиле 5.3, тестирую на php 7.4 (только из-за библиотек композеровских, требующих не ниже, а так раньше работало и на 7.1), в проде работает на 8.1-8.3. Багов, вызванных несовместимостями последних версий по сравнению с предыдущими, пока не было вообще. Когда оказалась, что сборка 8.3 в дистрибутиве кривая, совершенно без проблем даунгрейднулись до 8.2.
Но пишу по-человечески. Не побегу внедрять "асимметричное управление видимостью свойств объектов, отдельно для операций записи и чтения" только потому что "раз появилась верёвка - значит надо повеситься". Трейтами не пользуюсь. Типами не пользуюсь. Геттерами/сеттерами не пользуюсь. С классами не извращаюсь: создаю объекты, вызываю методы, никакого динамического добавления методов в классы и прочей нечитабельный ерунды.
>который проще переписать заново чем поштучно выковыривать все несовместимостиВы в начале запустили проект(есть ли у вас те же тесты?), а теперь жалуетесь, что путь длиной в десять лет нужно пройти за пару месяцев.
>Даже проще на совсем другой инструментарий, поскольку делать это ты очевидно будешь - по частям. А два php всяко хуже чем php и какая-нибудь нода.Нет, не хуже. Поднимается рядом новый микросервис, который проксирует обращения к старому коду, и понемногу начинает перетягивать запросы на себя. Часть кода вообще можно будет скопипастить из одного места в другое.
>>который проще переписать заново чем поштучно выковыривать все несовместимости
> Вы в начале запустили проект(есть ли у вас те же тесты?), акак тесты (КАКИЕ тесты?) могут помочь если версия языка перестала быть совместимой?
>>Даже проще на совсем другой инструментарий, поскольку делать это ты очевидно будешь - по частям. >>А два php всяко хуже чем php и какая-нибудь нода.
> Нет, не хуже. Поднимается рядом новый микросервис, который проксирует обращения к старому
> коду, и понемногу начинает перетягивать запросы на себя. Часть кода вообще
> можно будет скопипастить из одного места в другое.теперь у тебя миллион микросервисов (бюджет разработки отлично попилен) и "мы не выбросили пончики, они так с нами и летят" - дырявые версии не только остались с нами, но их теперь еще и не одна.
>и такая дребедень - каждый день. А ваш php5.4 (несовместимый с 5.3! Про историю с 5.2 замнем за давностию лет) не поддерживается. И 7 не поддерживается. И скоро с нытьем про нехватку рук, энтузиазма и туалетной бумаги - перестанут и 8.0-8.35.4 вышел лет девять назад. За это время если не портировать на новую версию, то с нуля уже можно было успеть переписать.
>Ну и как себя чувствует проект который десятилетие нужно именно что ежегодно переписывать чтоб вообще работалоХорошо себя чувствует, поскольку развивается. А вот те, кто застрял в конце девяностых/нулевых, тем да, сложно
>на том же самом (но не совсем) языке?Покажите язык, на котором можно нормально писать программы, а не играть в перловые головоломки, и при этом с обратной совместимостью лет на десять, с нормальными библиотеками, например с возможностью использования RabbitMQ. А теперь скажите, какие из них являются популярными.
> 5.4 вышел лет девять назад. За это время если не портировать на новую версию, то с нуля уже можно
> было успеть переписать.три раза.
Сколько раз тебе нужно переписать проект с нуля чтобы сообразить что ты выбрал совершенно феноменально кривой инструмент?
>Сколько раз тебе нужно переписать проект с нуля чтобы сообразить что ты выбрал совершенно феноменально кривой инструмент?На каком языке переписывать не надо, вот как написали в условные нулевые, так и по сей день работает? На питоне, с его переходом с второй на третью версию? За годы, прошедшие с момента релиза, уже можно было бы в фоновом режиме перейти если не с 5.3 на 8.4, то хотя бы на условный 8.0, скоратив отставание. А у вас технический долг только копится.
>>Сколько раз тебе нужно переписать проект с нуля чтобы сообразить что ты выбрал совершенно феноменально кривой инструмент?
> На каком языке переписывать не надо, вот как написали в условные нулевые,
> так и по сей день работает? На питоне, с его переходом
> с второй на третью версию? За годы, прошедшие с момента релиза,ну пля... ну понятно что притча во языцех, но они глобальную подставу всем сделали все же только ОДИН раз! (получилось эпично просто потому что ну что на том пехепе такого... мега общественно значимого и без бюджетов писалось.. считай, ничего)
> уже можно было бы в фоновом режиме перейти если не с
> 5.3 на 8.4, то хотя бы на условный 8.0, скоратив отставание.э... как бы это... в общем, скажи спасибо что на 7.3 удалось. Те трудозатраты - они настолько памятны всем, что уговорить повторить еще разок (чтоб через год понадобилось снова!) - ну хз кому удастся.
> Ну и как себя чувствует проект который десятилетие нужно именно что ежегодно переписывать чтоб вообще работало - на том же самом (но не совсем) языке?Я как раз любитель свежих и новых версий, и мои проекты ещё со времён PHP 5.3 практически полностью совместимы и с php 8.4. В 8.3 1 строку в Mysql обёртке поменял, в 8.4 избавился от ping() которая мне была и не нужна, и все изменения.
Но вы тут написали откровенную лажу!
Бывают крупные наследуемые проекты, обычно на новой работе или подряде, с кучей кода, без документации (ни разу не доводилось мне принимать документированный проект), которые то на falcon 3 (php 7.3) то на какой-то редкой cms, например отечественной umi-cms (php 5.6), и с этим приходится работать, хочешь ли ты этого или нет.
На переписывание уйдут годы, которые мне никто не будет оплачивать! А проблемы, коих немеренно, нужно исправлять и новый функционал добавлять и чтобы на проде ничего не отвалилось.
Это прямо каждый 2-ой проект такой на работе у php-програмиста!Переписывать под новую версию ничего не нужно!
Решается или виртуалкой/контейнером, в зависимости от сложности проекта.
Или я в одном проекте на phalcon 3, просто собрал php 7.3 так, чтобы он и его бэкенды и расширения не конфликтовал с основным свежим php, и их можно использовать одновременно.https://build.opensuse.org/project/show/home:13ilya:php73
Способы работать над протухшим лигаси есть, я вот даже свой придумал, лишь бы руки были прямые.
А спрос на поддержку тухлятины, как бы мне не хотелось, только растёт! :-(
> Или я в одном проекте на phalcon 3, просто собрал php 7.3со всеми багами и уязвимостями, начиная с приснопамятного phar и заканчивая remote exec в fpm? Ну молодец, чо.
> https://build.opensuse.org/project/show/home:13ilya:php73
Извини, лень даже открывать чтобы убедиться что ты не догадался хотя бы скопировать современные (+- пару лет) патчи из какого-нибудь LTS дистрибутива (впрочем, именно с 7.3 а не 4 надо сильно трудиться такой еще и найти)
И так у этих самоучек без мотора примерно все.
> Способы работать над протухшим лигаси есть
сидеть и молиться чтоб на метасплойте не лежало что-то готовое к запуску, о чем ты не в курсе.
(ну или быть никому ненужным неуловимым джо, как в твоем случае)
>> Или я в одном проекте на phalcon 3, просто собрал php 7.3
> со всеми багами и уязвимостями, начиная с приснопамятного phar и заканчивая remote
> exec в fpm? Ну молодец, чо.
>> Способы работать над протухшим лигаси есть
> сидеть и молиться чтоб на метасплойте не лежало что-то готовое к запуску,
> о чем ты не в курсе.
> (ну или быть никому ненужным неуловимым джо, как в твоем случае)Я вам про работу программиста, вы мне про работу сисадмина.
Заказчик нанимает программиста исключительно для задач программиста!
Мне плевать что там у него на бою и как там будет, это головная боль заказчика и его сисадмина!
А также мне напливать про уязвимости протухшего софта, которые установлены на моём локалхосте для разработки и тестирования, и дальше него они не выйдут!
> Я вам про работу программиста, вы мне про работу сисадмина.какой такой сисадмин?
Этот ненужный хлам выкинули за борт еще в 2015м году.
> Заказчик нанимает программиста исключительно для задач программиста!
> Мне плевать что там у него на бою и как там будет, это головная боль заказчикав принципе, да, если он такое г-но вместо программиста нанял - пусть у него голова и болит.
Проблема что я-то в некоторой степени и есть тот самый заказчик. Поэтому из трех предложенных решений выбрал то что на .net (по сумме факторов, конечно, но адекватность "программистов" там тоже присутствует среди учитываемого)
> А также мне напливать про уязвимости протухшего софта, которые установлены на моём локалхосте
> для разработки и тестирования, и дальше него они не выйдут!а вот это крайне наивно.
Я размещаю стремный софт в ВМ, ВМ не на том локалхосте на котором у меня банковский софт и пароли от всего, и даже сегмент сети у того локалхоста отдельный без прямого доступа к другим локалхостам. И все равно не чувствую себя уверенно. Потому что именно в такие, оставленные надолго без присмотра казалось бы хорошо изолированные системы и любят изредка забрести асоциальные элементы. А забыть что-то выключить после очередного теста, увы, легко.
>Сейчас, конечно, начинать новый проект на PHP я не знаю зачем.А на чём делать - на питоне, который объективно хуже php как по быстродействию, так и по типизации? Или на ноде, с её тоннами пакетов, тормозами и уязвимостями?
ну да, ну да, в пехепе нет ни тонн пакетов (причем начиная от нимодна-нимодна-запритить-запритить но все еще критично необходимого pear, и продолжая компостером тянущим компост со всего интернета) ни уязвимостей (вот эти вот два десятка cve за прошедший год мне померещились, видимо)и напомни, пожалуйста, когда нода ломала совместимость с уже написанным кодом?
.NET и Java
Там вам и быстродействие и типизация. А если серьёзно, то какой сайт? Single Page Application?Ну если вам не нравится Node.js и PHP, то бекенд пишите на чём угодно.
Вон даже .NET Blazor есть, который вам даже фронтенд нарисует на C# через WebAssembly.Типизируйтесь на здоровье =)
Как там в яве с ненулабельными типами? А типы union/intersect типы тоже есть?
>.NET и JavaТам нужно гораздо больше boilerplate, практически без выгод. А так же перезагружать приложение, с потререй состояния, когда изменил несколько строк, ибо горячая перезагрузка работает не всегда.
>Там вам и быстродействие и типизация.Там будут постоянные приведения типов, от Object и обратно.
>не всегдазачастую работает.
по крайней мере, в .NET
Как не откро. какой фрилансерский сайт так там постоянно полно объявлений связанных с PHP. Богомерзкий Node.js тоже есть, но поменьше.
> Как не откро. какой фрилансерский сайт так там постоянно полно объявлений связанных
> с PHP. Богомерзкий Node.js тоже есть, но поменьше.потому что наколенных поделок имени Васян и сыновья, которые некому поддерживать - полно.
А на node.js чаще делают уже нормальные разработчики, а не найденый на сайте неведомый программизд из Черновцов.
>Это отчаянные попытки вернуть техДоля PHP в вебе - 75%.
Доля "ближайшего" конкурента Ruby - всего 6%.Отчаянные попытки, ага.
Эти проценты за счёт мусорных сайтов на вордпрессе из 2010х, и вообще, сайты уже давно в прошлое уходят, останутся мессенджеры в и пара соцсетей с маркетплейсами. Живи с этим теперь.
Тебя как почитать, то складывается впечатления что после 2010 года сайтов больше не делают, раз PHP, то значит мусорный сайт.
> Тебя как почитать, то складывается впечатления что после 2010 года сайтов больше
> не делают, раз PHP, то значит мусорный сайт.И не php - он же. С наибольшей вероятностью это так, увы.
вон, переписываюсь сейчас с менеджером. Сайт у них есть, да. Можно даже "сделать заказ" - на самом деле это email менеджеру. Когда-нибудь он тебе ответит. А можешь сразу писать в ватцап. Тогда ответит сразу и даже уточнит детали заказа.
Ну когда уйдут окончательно, расскажете. А то я это лет десять уже слышу.
"Ничего не будет. Ни кино, ни театра, ни книг, ни газет – одно сплошное телевидение" (с) 1980
> "Ничего не будет. Ни кино, ни театра, ни книг, ни газет –
> одно сплошное телевидение" (с) 1980"газета мне нужна тогда, когда я - в туалете!" (c)
т.е. примерно так и получилось. Газеты я использую как техническую бумагу. Что-то застелить или промокнуть. К счастью, их еще зачем-то печатают.
> т.е. примерно так и получилосьПо айтишникам не стоит судить о населении. Например, только в подписном каталоге Почты России на следующий год - больше 5 тысяч наименований. Того, за что люди готовы платить деньги, да еще и при этом претерпевать сервис Почты России...
Но главным образом я имел в виду предложить посмотреть, где теперь то телевидение ;)
> По айтишникам не стоит судить о населении. Например, только в подписном каталоге
> Почты России на следующий год - больше 5 тысяч наименований. Того,
> за что люди готовы платить деньги, да еще и при этомнет, того за что люди еще надеются эти деньги спилить. Надежды оправдаются не у всех.
> претерпевать сервис Почты России...
у кого-то кроме этого сервиса на оленях ничего не бывает. Но проблема в том что оплата ягелем почтой не принимается.
> Но главным образом я имел в виду предложить посмотреть, где теперь то
> телевидение ;)там же - у тех же.
Хоронили php - порвали джва баяна \
Мне сегодня можно, я сегодня пьяный \Но да, имело бы смысл заморозить php на крайней версии 7 и делать уже нормальный php 8 через транспилятор.
Первая версия тоже крайняя. На ней замораживать?
> Первая версия тоже крайняя. На ней замораживать?просто опоздавшие родиться не помнят эпика с foreach. Когда выяснилось что разработчики нескучного языка настолько альтернативно одарены, что могут сломать совместимость даже просто в minor release. И да, разумеется предыдущий никто даже и не думал поддерживать.
Т.е. пойти по пути перла? план просто грандиозный :-)))
Да, перл его настолько успешно прошёл, что даже язык переименовали
Ну...да? Хотя тут больше бы подошла опупея с питон2 -> питон3. Тоже бкгали с горящим задом, но ничего, перешли, даже много где пистон2 уже надо собирать в чем-то типа аура, а не лежит в репах.
> пёрлПустили переход на пёрл 6 на самотёк, оно так и вышло.
Достаточно было начать с популярных фреймворков, остальные ради совместимости бы подтянулись с г-ноязыка на нормальную версию языка.
> Ну...да? Хотя тут больше бы подошла опупея с питон2 -> питон3. Тоже
> бкгали с горящим задом, но ничего, перешли,куда перешли-то - в гроб? Ну да, ну да. Помним, скорбим. hg, trac, кто там еще.
Хоть что-то сравнимое _успешно_ пережившее "апгрейд" назвать сможешь?
> Пустили переход на пёрл 6 на самотёк, оно так и вышло.
поэтому git так до сих пор и работает. А не переписывался-переписывался да и сдох.
Это не развитие, это уже овер инжиниринг.
оверинжиниринг — это второе имя PHP ;)
Сегодня может быть, но для меня пыха закончилась на 4й версии, потом туда начали навязывать ООП, которое для вэба как раз является сферическим овер инжинирингом.
На процедурном подходе далеко не уехать. Нужно либо в ООП, либо в ФП, либо и туда и туда идти.
Я так за 15 лет не понял где грань между процедурным стилем и ООП!
Если под ООП обязательно имеется ввиду вызов new, то в большинстве случаев веб-задач это совершенно не нужно!Но можно просто использовать статические классы, со статическими константами, свойствами и методами и пространства имён, если нужно.
Именно так я и делаю и это удобно писать, рефакторить, аудировать и это быстро работает.Это, без new через ClassName::, уже ООП или ещё процедурный стиль?
1. Как при вашем подходе создать несколько инстансов ClassName? Например, ORM. По себе знаю, в 95% случаев можно обойтись без этого (без нескольких инстансов), но всё же?
2. Как при вашем подходе тестировать и мокать часть интерфейсов? В случае с объектами просто подставляем мок вместо реального объекта. Я пишу тесты лишь "по нужде" (то есть практически никогда), но даже мне это требовалось.
3. Как при вашем подходе, например, отрендерить на странице блок, притом что для каждого типа блока (новость, календарь, заголовок) свой метод рендеринга? Через свитч?Но, честно говоря, мне просто некомфортно иметь что-то в глобальной области видимости, а ваши имена функций типа ClassName::functionName() это по сути глобальные функции. Учили же в школе не пользоваться глобальными переменными, так что мне до сих пор это причиняет дискомфорт.
1 Никак! В синглтоне аналогично!
В веб-задачах, где скрипт запускается максимум на несколько секунд динамическое выделение памяти из куча только вредит производительности и отжирает лишнию память и приводит к фрагментации кучи!
2 Я не использую интерфейсы там, где это не нужно.
Интерфейсы (заголовочные файлы) нужны в C++, где это ускоряет компиляцию и перекомпиляцию.
В php это зачем?
При условии, конечно, что я не делаю публичную библиотеку, или api или специально расширяемый класс?
С тестированием не связан, не совсем понимаю что значит заменить объект мокапом и зачем это нужно делать, но подстраиваться под специфические шаблоны тестирования, например передовать кучу параметров из метода в метод, только для того чтобы их мог протестировать unit-скрипт, и делать все методы открытыми для этого и прочее считаю недопустимым, если нет такого ТЗ или правила разработки изначально.3 У меня отдельная во view дирекория для блоков, создаю блок, и подключаю через require.
В блоке все переменные начинаю с подчёркивания, а в конце блока их все разом удаляю unset-ом.4 Класс или пространство имён и должны быть в глобальной области видимости, чтобы вызвать его из любой точки коду по ClassName или \Name\Space\ClassName.
А иногда и константы, например с конфигом или APP VIEW APP ACT ID и прочие, которые необходимы в любой части кода, часто и желательно с короткими именами.
Не вижу тут дискомфорт.
Спасибо за ответы!> Интерфейсы (заголовочные файлы)
В моём сообщении "интерфейс" - это не Interface, а просто интерфейс класса, который (класс) предполагается протестировать. У любого класса есть "интерфейс" - список методов, полей, "выставляемых наружу". Прототип функции (название, список параметров, возвращаемое значение) - это тоже интерфейс. Интерфейс - это, по сути, описание того, как взаимодействовать с какой-то сущностью (объектом, функцией, модулем, ...). То есть это не "зачем это в php?", это всегда есть, как бы вы и что бы вы ни писали.
> не совсем понимаю что значит заменить объект мокапом и зачем это нужно делать
Предположим, у вас есть функция рендеринга блока новостей типа такой:
function renderNewsList () {
$ret = '';
$news = \Db\fetchAll('news');
foreach ($news as $new)
$ret .= \Render\NewsBlock\item($new);
return
\Render\NewsBlock\start() .
$ret .
\Render\NewsBlock\end();
}Если вы захотите её протестировать, то вам в каждом тесте придётся полноценно наполнять бд перед вызовом функции, а также сравнивать результирующий монструозный html на выходе.
Если же вы используете объекты:
class NewsList {public function __construct ($db, $render) {
$this->db = $db;
$this->render = $render;
}function render () {
$ret = '';
$news = $this->db->fetchAll('news');
foreach ($news as $new)
$ret .= $this->render->item($new);
return
$this->render->start() .
$ret .
$this->render->end();
}То при тестировании вместо объектов, работающих с реальной бд, и выдающих реальный html для сайта, вы передаёте заглушки (моки).
Мок для работы с бд будет вместо запроса к бд возвращать фиксированный (статичный) список новостей. В результате во время тестов даже не потребуется соединения с бд, а сам тест будет изолирован от ошибок работы с бд и будет проверять только логику работы рендеринга списка.
Мок для рендеринга новостей будет возвращать не полный html-код, а, например, только заголовок новости. В результате сравнивать результат с ожидаемым будет проще.
Это слишком упрощённый пример и в реальности часто проще использовать реальную (но тестовую) бд, а результат сравнивать не посимвольно, а, скажем, просто сравнивать длину в символах ожидаемую и полученную. Но даже при таком развитии событий сам подход иногда оказывается полезным (например, для того, чтобы замокать какой-нибудь внешний сервис, с которым взаимодействует сайт).
Благодарю за ответы!Я понял что вы подразумеваете под интерфейсами, и ваш подход к тестированиию.
Согласен, что он вполне имеет место быть при некоторых сценариях.
Мне подобное делать не приходилось, я при необходимости тщательного тестирования развёртываю или на виртуалке/контейнере или на своём хосте БД с боя и провожу с ней полноценные тесты.
Тестировщики делают так постоянно и для этого есть автоматизированные инструменты, которые и я иногда использую.Но всё же делать все методы динамическими, только из-за того, что возможно какой-нибудь из них будет удобнее так протестировать, и тем более чтобы угодить PSR, я не считаю нужным.
он еще мертв, но уже давно на пенсии во всех смыслах
Интересно, что и как у хейтеров порвётся когда они узнают про swoole 🤔
От IR порвались видимо расшифровали тот ллвм
А что к этой китайской поделке уже сделали вменяемую документацию?
Почему "поделке"? Какой вообще смысл сейчас, в 2024 году, писать под платформу, не предоставляющую встроенной асинхронности?По опыту со свулом понадобилось написать небольшое приложение, с асинхронностью в некоторых моментах. Сильно не заморачивался, но документацию где-то нашёл. Размер приложения не самый маленький, но вся требуемая "зависимость" от свула сосредоточена в одном файле на 50 строк.
Вот в самом php документации много, и сильно это помогает? Расписано всё до мелочей, но стоит написать код с расчётом на эти мелочи, так в ближайшие три релиза получаешь гарантированную несовместимость и необходимость переписать (и перетестировть) код под новую версию.
Вот бы увидеть как вы неработоспособность $_session и глюки, когда переменные в глобал улетают, обошли. Или уже поправили это?
Когда-то, во времена 4й версии, это был действительно нормальный язык, заточенный под конкретную область. Сегодня это монстр, который сложнее джавы и сишарпа вместе взятых, да и смысла в нем нет, веб давно уже на микросервисах.
Да, как язык был норм. Только все названия функций приходилось смотреть в доках, ибо они все именовались по-разному, и набор параметров в разном порядке у похожих функций был. Плюс, дикие тормоза были.
Не знаю какие там у тебя тормоза были, у меня на 3 пне с 512 мб "денвер" летал, когда занимался разработкой, причем разрабатывал серьезные сайты, а не одностраничники, ну и не говори что сейчас ты научился кодить без гугла и без открытого мануала.
Некоторые под "php" подразумевают продукты типа Битрикса или ещё какой-нибудь Магенты (и в чём-то даже правы по-своему).
Ты чего несешь? Нормальным языком PHP стал с версии 8.0, а 4.x было недоразумением.
Сам по себе ЯП значит немного в случае с пыхом. Там главное - это всевозможные фреймворки и модули с изучением которых порой страданий больше чем с самим ЯП.
А тот факт что какие-то доработки самого ЯП выходят - совсем не означает что их непременно нужно применять и знать. Нередко они вообще ничего не значат, пока не ломается обратная совместимость. Но никто и не заставляет регулярно переходить на новую версию ЯП для уже существующего проекта.
Так ведь на пхп и микросервисы пишутся легко и приятно.
Он никогда не был нормальным.
Всё равно что сделать нормальному языку лоботомию (Personal Home Page не должен быть сложным!), а потом годами навёрстывать то что выкинули. Всё через жопу прямо с самого начала.
> единый для всех архитектур бэкенд и генерирует промежуточное представление (IR), которое затем дополнительно оптимизируется и преобразуется в машинные инструкции для нужной целевой платформы.LLVM напоминает.
Добавления новых функций и упрощение написания сложных конструкций приветствуется, но вот усложнение с повышением монструозности кода, это вообще лишнее. С каждым релизом что-то да выпиливается. Да оставь те вы для совместимости и всего делов.
> Да оставь те вы для совместимости и всего делов.Да не юзай ты его и делов то :)
> Добавления новых функций и упрощение написания сложных конструкций приветствуется, но
> вот усложнение с повышением монструозности кода, это вообще лишнее. С каждым
> релизом что-то да выпиливается.это называетса вжопп секурити или как-то похоже.
Короче, у тебя до пенсии будет работа по переписыванию одного и того же кода, без конца.
Давно свичнулся, но продолжаю следить за PHP.
И после такого: "function save(?Book $book = null) {}" Ни разу не пожалел.PHP реально уже не актуален. Админки и CRUD, где PHP был идеален, уже пилят на TS/JS + json backend на любом языке.
ХЗ где его применять.PHP с каждой версией все больше напоминает франкинштейна, тело которого собрано из частей Perl, C++, Java, и упаси Боже - JS.
>Админки и CRUD, где PHP был идеален, уже пилят на TS/JS + json backend на любом языке.Например, на js + php. С учётом фреймворков, вполне удачно.
Имеется в виду REST/GraphQL
да даже на php, любой rest api. Фишка в том что все это быстро заменяется на что-то более подходящее в современных реалиях, а смысл было начинать? Почему бы сразу не написать на чем-то лучшем? Kotlin/Java, TS/JS, Python... Что не возьми, все в чем-то лучше PHP.
Какое преимущество у PHP? Да ни какого.JIT? Так у JS v8 побыстрее будет. Java опять же со своей VM.
Синтаксис? После Python смотреть тошно.
Многопоточки? Через костыль, типа файберов. У того же Kotlin отличные корутины.
Низкий порог входа? Посмотрите на синтаксис 8.4. У любого новичка крыша съедет, прежде чем понять как что-то там работает. Особенно учитывая любовь PHP к магии.Единственное что его сейчас спасает, это то что нельзя на других технологиях нажатием одной кнопкой развернуть у себя аналог WP, Joomla или какого-то интернет магазина на PrestaShop или OpenCard (и Битрикс, lol).
Как только что-то появится схожее - всё, приехали.
С# ещё.
Про Go намеренно молчу.
Кстати! Даже у яндекса есть к C++ OpenSource фреймворк, с помощью которого можно легко и понятно для новичка писать rest api на плюсах.
> да даже на php, любой rest api. Фишка в том что все
> это быстро заменяется на что-то более подходящее в современных реалиях, а
> смысл было начинать? Почему бы сразу не написать на чем-то лучшем?А какие они эти современные реалии? Python, Java и много чего ещё появилось не вчера и почему–то PHP как был востребованнее так и остался. Node.js даже хуже.
>Низкий порог входа? Посмотрите на синтаксис 8.4. У любого новичка крыша съедет, прежде чем понять как что-то там работает. Особенно учитывая любовь PHP к магии.В условном C# магии как бы не больше. Тут разве что golang, в котором вместо магии километры исходников.
> Единственное что его сейчас спасает, это то что нельзя на других технологиях
> нажатием одной кнопкой развернуть у себя аналог WP, Joomla или какого-то
> интернет магазина на PrestaShop или OpenCard (и Битрикс, lol).ну и вот спросим себя, почему на jango каком-нибудь - один джанк, а на жабке-ква - монстры атсас....атлассиана которых все ненавидят?
> Как только что-то появится схожее - всё, приехали.
не дождемся. Ушла эпоха.
Даже твой битрикс уже на 70% - ass in servise или как там это правильно пишется.
> Давно свичнулся, но продолжаю следить за PHP.
> И после такого: "function save(?Book $book = null) {}" Ни разу не
> пожалел.
> PHP реально уже не актуален. Админки и CRUD, где PHP был идеален,
> уже пилят на TS/JS + json backend на любом языке.
> ХЗ где его применять.
> PHP с каждой версией все больше напоминает франкинштейна, тело которого собрано из
> частей Perl, C++, Java, и упаси Боже - JS.А зачем манять шило на мыло и тащить ЯваСцэнарий на сервер?
>Предложена новая реализация JIT-компилятора, построенная на базе IR Framework. Ключевое отличие в том, что старый JIT напрямую генерировал машинные инструкции на основе байткода и с использованием разных бэкендов для архитектур x86_64 и AArch64, а новый JIT использует единый для всех архитектур бэкенд и генерирует промежуточное представление (IR), которое затем дополнительно оптимизируется и преобразуется в машинные инструкции для нужной целевой платформы.Лишь бы LLVM не использовать.
>Добавлена поддержка прикрепления обработчиков свойств (property hook), позволяющих добавить дополнительную логику, выполняемую при изменении или доступе к свойствам объектаПревращаются брюки ... брюки превращаются ... в ASP.Net!
Ну действительно, там и JIT от C# из коробки, и ЯП нормальный, и куча либ...
>и ЯП нормальныйM$ сейчас усиленно f# портит, а вы их изначальный ужас - c# нормальным называете. К C# всё большим количеством изоленты прикручивают всё большее количество фич, они так и c++ перегнать смогут. О том, как это всё сочетается и вместе работает - мелкомягкие не думают, гланое чтоб количество фич было больше, чем у конкурентов.
Long live! Кормит
> КормитОбычно такие словечки используют те, кто не развивается , освоив один какой-то воркфлоу и одну технологию какой-то определенной версии и завис на ней на годы, обслуживая какой-то древний легаси проект. Параллель с рабочим с совкового завода, который стоит на линии и точит какую-то детальку десятилетиями.
Будто что-то плохое. Минусы будут?
Плохая параллель. Такое мог привести только человек, не шарящий за то, как точат. У станков, знаете ли, есть износ. Чтобы заточить одну и ту же деталь на одном и том же станке, надо не слабо так разобраться в подготовке и эксплуатации станка. А это важные и ценные навыки даже сами по себе.А ещё измерительным инструментом надо уметь пользоваться в процессе. Что тоже важный навык, который останется с рабочим. Даже когда точить придётся новую деталь.
А с софтом хуже. Там можно не только окуклится в привычном инструментарии, но и в подходах застрять, которые применялись в тех проектах, которые тебя кормили годами. Что равносильно деквалификации до уровня придатков этих проектов.
Если кто не заметил — теперь в PHP есть рабочий (теоретически) HTML-парсер.
> теперь в PHP есть рабочий (теоретически) HTML-парсертеперь в PHP зачем-то есть рабочий (теоретически) HTML-парсер.
Угу, и «зачем-то» люди до этого вынуждены были использовать чисто скриптовый парсер `Masterminds/html5-php`. ;-)
И не просто HTML парсер, а отечественная разработка!
Фтопку вместе со всем пыхом.
>>> Добавлены новые функции mb_trim(), mb_ltrim(), mb_rtrim(), mb_ucfirst(), mb_lcfirst(), bcceil(), bcdivmod(), bcfloor() и bcround(), pcntl_getcpu(), pcntl_getcpuaffinity(), pcntl_getqos_class(), pcntl_setns(), pcntl_waitid(), http_get_last_response_headers(), http_clear_last_response_headers(), fpow()Stop, please, stop!
Горшочек, не вари! 🤣
https://avatars.dzeninfra.ru/get-zen_doc/2749135/pub_60d0136...
а динамически к бд, аль на страницах подгружать, так и не научили пых? без жс всё ещё не сделать никак?есть пара старых удачных проектов, осовременить бы)
чего, никто не знает что ли? jquery прикручивать надо?
Как ты JavaScript-библиотеку к PHP прикручивать собрался?
да как и везде - в шапку ссылку с гугл-облака прибиваешь и потом внутри жаваскриптишь.прост проектик вылизанный, никакой процедурки, всё по шаблончикам, примитивными незамудрёнными классами, всё по пээсэрочки... но, сук, как же бесит, что выглядит как каменный век, когда поработаешь в приложухе с динамическим обновлением на сокетах. хоть садись и жс учи и переписывай начисто.
так что в этом плане я тут согласен, что пхп тащит много всего, не буду рассуждать насколько именно всё это ему необходимо, но, не иметь возможностей джейквери _искаропки_ для _языка для сайтов_ - это просто зашквар какой-то. хотя, не исключено, пых задумывался/подразумевается как нечто иное, а я и не вкурсе, да и использую неправильно. сейчас с нуля пхп учить - ну вот прям совсем нет. плюсы, жс - смотря что хочешь.
Во всех подобных обсуждениях, начиная со времени популяризации Node.js, есть невысказання, или высказанная, претензия (или даже что–то типа обиды) на трон короля — PHP. Мол JavaSript лучше, быстрее и верстальщикам не надо учить какой–то другой язык и они могут писать серверные скрипты сразу. Лучше ли JavaScript очень большой вопрос. На PHP есть вагон и маленька тележка CMS которые, как оказалось, почти идеально подходят для сайтостроительства и вокруг которых, как мне кажеться, всё и крутиться. Сместив PHP явасцэнаристы превратятся в похапэшников и погрузяться в то чем сейчас занято большинство похапэшник со всеми вытекающими последаствиями в виде перерождения в неких мастеров CMS робота которых будет состоять из подкручивания как самой CMS так и плагинов к ней, натягивании вёрстки на Joomla.js и правке шаблонов что сметёт последние остатки некой элитарности.
Окей нейросеть назови мне полный аналог wordpress на javascript.
ЖСжс не имеет возможностей всё это исполнить, или просто ещё никто не сделал? Интересуюсь, с жс мало знаком.
Это у нодеров - элитарность? Толпа студентов, которая постоянно "хватается за новые инструменты вместо того, чтобы научиться пользоваться старыми" (с) 1950 Брэдбери
> Это у нодеров - элитарность? Толпа студентов, которая постоянно "хватается за новые
> инструменты вместо того, чтобы научиться пользоваться старыми" (с) 1950 БрэдбериНо они считают иначе. Божественная асинхронность и лучший в мире JavaScript.
Вспомнил что одно время много писали о том какой же Python прекрасный и что надо бросать PHP и переходить на Python. Потом такое же было с Ruby и Ruby on Rails.
Кто-нибудьфоркните PHP 5 !!!!этим лапшесинтаксисисом скоро задавят :(
1 Зачем!?
2 Кто вам запрещает использовать старый синтаксис?
3 Вы вообще пишете на php или вы только глупые комментарии писать умеете?
Это у тебя глупый комент, нормальные опытные люди понимают что приходится разбираться, поддерживать и развивать не только свой код
Много копий сломано, по факту же есть бенчмарки которые совершенно точно не говорят в пользу использования питона или go в вэбе. Тут ещё не нужно забывать удобство разработки. ну и конечно swoole - корутины, все виды сокетов, таймеры, шаред мемори и тд. на php можно написать практически что угодно, кроме фронтенда конечно, хотя со статикой поиграть вам никто не запрещает.
Лайк за упоминание свул. Имхо в нынешних реалиях оно должно быть в ядре php, а не на задворках композеровского репозитория.
да, благодарю, приличное решение - миничатик, в отдельном, вообще легко завелось. осталось парсер в фон приклеить и дивы на поводок посадить. думаю что расширением и без кода жс встанет - просто имба получится
Можно краткий ликбез зачем нужна вся эта асинхронность? Десяток лет делаю сайтики на пыхе и не возникало ещё потребности в чем-то подобном, может я не вижу чего-то очевидного
а какие сайтики? статику? где нужно постоянно страничку в браузере по кнопке обновлять, что бы изменения увидеть или данные отправить?представь что твой сайтик, ну например приложение кастомер релайшн менеджмент, и вот ты заходишь на страничку проекта, данные обновить, и одновременно туда же заходит другой юзер с той же целью. продолжить?
как вот на пых-сайте динамичное обновление сделать, без сокетов и жс?
Забавно читать вскукаретиков, которые каждый год хоронят PHP, на его место предлагая питон, или прости господи, нодежс.Нормальные же люди, просто пишут готовый конечный продукт, используя удобный для этого язык программирования.
Ну вот например пока хейтеры ПоХаПе страдают в гномо-кедах, рассказывая каким должен быть ЯП, кто-то пользуется шустрой, красивой, удобной DE, написанной им же, на самом лучшем языке программирования, 8.4-я версия которого недавно вышла.
> Нормальные же люди, просто пишут готовый конечный продукт, используя удобный для этого язык программирования.Нормальный человек пых использовать не будет.
Так Цукербергу \ Дурову и скажешь.
Сцукенберг (точнее, его рабы, сам он ни на каком инструменте не играет) были вынуждены написать СВОЙ интерпретатор, так что это давно уже не php.
(и да, это в том числе гарантирует им отсутствие необходимости переписывать весь код потому что "мы выпустили новую несовместимую версию и перестали поддерживать старую")Но у тебя нет столько денег и столько рабов.
Без разницы.Сырцы пыха доступны - я же переписываю то что мне нужно ;) Пока вы скулите.
> Так Цукербергу \ Дурову и скажешь.Они и не используют их :D Они управляют галерой
В этой версии есть проблемы с imagick :( Он тупо не работает. поэтому все ворпдрессы с прочие CMS пока не надо заводить на php8.4Как обычно, надо ждать 8.4.1 🤣
после 18 обычно уже не замечаешь версии с парой точек и нулей на конце)))
Было бы прекрасно, если бы вернули совместимость со старым драйвером mysql.
Или бы сделали режим совместимости в настройках.
Тащат что ни попадя. Это уже реально java-подобный Франкенштейн получился, потому и стагнирует. Раньше порог входа был минимальный, сайты пилились на include'ахКак на этой рыготине можно что-то нормальное писать? А главное зачем? Лучше взять Ruby или Python и то приятнее будет
Не поверите, они и сейчас прекрасно пишутся на инклюдах, значительно помогая циклами,функциями и тп.И никто не мешает прикручивать свои расширения на том, что удобнее.
> Добавлена возможность асимметричного управления видимостью свойств объектов (public, private, protected), отдельно для операций записи (set) и чтения (get)Это у них про безопасность, или они так типизируются с непрерывной интеграцией?
NodeJS будет жить, PHP уже не сможет себя отмыть от синтаксической грязи.