Комментарии 164
Есть и другой интересный вопрос — почему в 2025 году всё ещё находятся люди, мечтающие похоронить тот или иной язык :)
потому что проще верить, что "это лыжи не едут язык неправильный, а не я тупой мне базу надо прокачивать" :)
а эд-тех еще и культивирует эту мысль в массах..
[минутка токсичности от нанимающего менеджера]
Видимо, какие-то детские комплексы из разряда: "мой язык круче твоего языка". И в 2075 будет то же самое.
По моей скромной статистике вероятность что PHP проект ужасен в сопровождении гораздо выше чем C# проект. Но всякое бывает, да...
Напрашивается вопрос, а почему он должен быть убиваемый?
Да что же вы каждый раз, когда речь заходит про PHP приводите в пример Вконтактик, который по сути написал полностью свой интерпретатор и от PHP там разве что синтаксис, да и то, отставший от мейнстрима.
Примеры использования языка тут совсем другие, выше по тексту. А вконтактик приведён как пример гибкости экосистемы. Так себе пример, но и комментарий у вас, прямо скажем, не первой свежести.
Это точно мне ответ? А то я выше по тексту не увидел примеров использования.
У меня у самого пыха основной язык, и его популярность реально связана с великолепной экосистемой, а также с божественной Симфой и почему-то всеми любимым Ларавелем :-) Ну и композер и прочие PSR истории. Наконец-то спустя много лет в пыхе есть стандартизация и можно бить вонючими тряпками тех, кто пишет не по канону.
Но, боги, ВКонтактик? Я, конечно, давно туда не лазил, но ребята написали по сути свою пыху во времена 5.3, когда PHP был еще медленным, а кодовая база у них была уже огромная. И это тогда казалось нормальным компромиссом для конкретной задачи. Но это чисто вещь в себе, которая не очень относится к экосистеме в целом, ибо никто в здравом уме не будет использовать KPHP в своих проектах.
Вам-вам. Статья, конечно, халтурная, но ваш предыдущий комментарий тоже так себе. Я, кстати, и сам часто сталкиваюсь с этим - в голове самому себе всё ясно, а когда напишешь, то получается ерунда. Особенно когда читаешь по диагонали, а думаешь о своём.
В статье не предлагается использовать КРНР в своих проектах. Там предлагается использовать в своих проектах РНР, для логистики или крипты например. А Вконтактик привешен действительно не пришей собаке хвост, как не очень понятный пример "развития экосистемы". Хотя этому примеру уже сто лет в обед, и сейчас как пример стоило бы приводить скорее JIT.
А это хорошо или плохо? Просто ВК реально тормозная поделка сейчас. Нажимаешь на сообщения или на группы, тишина, секунд 5 иногда не происходит перехода.
А это ни хорошо и ни плохо. Они в свое время родили KPHP, потому что обычная пыха была для них очень медленная, а кодовая база была большая и переписывать это все на другой более быстрый стек было долго, трудно и рисково. В принципе, с точки зрения проблема-решение вполне себе подход.
Но наличие KPHP не гарантирует, что все всегда будет быстро. Но то, что было медленно на PHP из-за скорости PHP (важно), на KPHP стало быстрее в разы.
То, почему оно сейчас медленно - там может быть миллион причин, вроде кривой архитектуры, проблем с сетевой связностью, да и просто высокой нагрузки на какую-нить базу данных.
К сожалению, навскидку не удалось найти свежих бенчмарков KPHP, но вот тут (https://vkcom.github.io/kphp/kphp-language/kphp-vs-php/benchmarks.html) пишут такое:
If we measure PHP 7.2 version and KPHP-compiled on the same server, for a random account, we get
vk.com/feed — PHP: 10.1 sec, KPHP: 0.95 sec
vk.com/im — PHP: 1.25 sec, KPHP: 0.46 sec
vk.com/ads — PHP: 0.73 sec, KPHP: 0.20 secIn general, for VK.com we have from 3 to 10 times average profit. Pretty much to suffer a bit, right?
Having a goal to optimize particular places, you can achieve even better results.
И у меня первый вопрос: что же вы там такого под капотом делаете, когда генерируете ленту, что уперлись в скорость интерпретатора, а не, например, в базу? Ну реально. Типа они там реально что-ли все выгружают в приложение а потом медленно и томно сортируют? Или там движок рекомендаций написан на пыхе, который матрицы перемножает.... Ну, т.е. у меня создается впечатление, что там реально есть что-то прям тяжелое для пыхи и это можно было вынести в отдельный компонент, написанный на чем-то быстром, а не переизобретать пыху, чтобы использовать везде на проекте оторванную от мейнстрима версию.
Насколько я помню - вообще не так было. Просто незадолго до, лицокнига выпустила свой хип-хоп, а в вк решили исправить его фатальный недостаток, но нишмагли. В итоге родилось это уродливое поделие kphp, которое покрывало только незначительную часть функционала пыха, в частности там вроде как ооп вообще не было. И я конечно не знаю как выгдялела кодовая база вк в то время, но что-то мне подсказывает, что искаропки на кпхп она не запускалась, и под кпхп надо было писать отдельный код. Так что вопрос был скорее не в большой кодовой базе, в имеющихся в наличии специалистах, которых проще переучить га кпхп, чем на другой язык. Ну и желании все комуниздить у лицокниги, конечно же, это скорее первым пунктом стоит называть.
Ну там за давностью лет причина и следствия могли сильно порасти травой. Но Facebook выпустил HHPHP с этой же целью. И у них тогда точно было много-много кода уже. То, что ВКонтакте запилили свое решение... Ну, не знаю. Может фатальный недостаток, а может реально что-то их не устроило.
Хип-хоп вроде довольно юзабельный был и умел в классический пхп почти полностью, там только declare(strict_types=1) по другому работали, ну может еще что, за давностью лет я не помню уже. А так же имел собственный диалект. потом они вроде только поддержку собственного диалекта и оставили.
Я не знаю что тестируют этот бенчмарк, но сам сайт (весь) VK работает из рук вон плохо. Попробуйте им попользоваться сейчас. Это просто невозможно.
Попробуйте на php сделать web3-проект)
Кто в чем варится, на том и работает. А вообще в IT нужно быть гибким. Сегодня работаешь на node, завтра можешь оказаться у того же laravel.
Поэтому я считаю тут нет четкой стороны которую нужно принимать как правильный путь.
А можете очень кратенько перечислить подводные камни при реализации web3-проекта на РНР?
Подключитесь к public ноде например формата EVM. С чего вы начнете ?
С того же, с чего начну любую незнакомую задачу - загуглю php public node EVM
Теперь я понял, что имею честь переписываться с умным человеком.
Ирония подразумевает, что поумничать хотели вы?
Так первые же ссылки в гугле выдают, как подключаться. Так что действительно было бы любопытно услышать про объективные минусы и сложности реализации такого проекта на php, раз вы так уверенно об этом заявляете.
А вы гляньте когда это SDK обновлялось последний раз (2 года назад). И посмотрите такой же на js: web3js
Не два, а полгода назад. Вы толком расскажите о проблемах, а не бурчите как обиженный пятиклассник.
https://github.com/web3/web3.js/commits/4.x/
Давайте-ка посмотрим, что там на самом деле обновлялось...
документация, документация, ридми, тесты, фикстуры, снова документация, чейнджлоги, предельно важные обновления версий пакетов (повысили минорную версию зависимости - предельно критичное обновление!)
даже "Release/4.16.0" свелся к обновлению документации.
А где серьезные изменения кода? Хм, самое позднее 13 ноября 2024?
Немножечко не сходится с вашим набросом "обновлялось последний раз полгода назад, А ВОТ НА JS..."
Тут другое.
Почему постоянные обновления за плюс считаются?
Как человек, пишущий преимущественно на js, на слово «обновление» уже нервно реагирую. И с каждым годом всё сложнее объяснять заказчикам, почему нужно делать эти сложные и долгие миграции на новые несовместимые версии фреймворков, когда вроде бы только-только всё отладили.
В этом смысле php весьма выгодно выглядит по крайней мере для бизнеса.
Ну, если следовать парадигме Semver, несовместимость фреймворков отражается изменением мажорной версии. Тут, понятно, обновления нужны (по крайней мере желательны). Но при смене минора или патча тогда, когда в файлах зависимостей меняется только это - на определение "обновление кода" это не тянет.
В этом смысле php весьма выгодно выглядит по крайней мере для бизнеса.
В PHP-экосистеме такое тоже встречается, к сожалению. Просто в данной конкретной ситуации мой комментарий - язвительное (надеюсь) опровержение наброса гражданина slbeat.
Для начала в вашем примере здорово изучить предметную область и после выбрать sdk на php. Уверен, что подход "поставить первую попавшуюся sdk и начать тыкать" без понимая предметной области и дальнейшего выбора не очень уместен для грамотной разработки. А если время позволяет и нет готового решения, удовлетворяющего разработчика, позволяет написать свой пакет и использовать его в своих нуждах.
Переход от PHP 4 к PHP 5 принес полноценное ООП, сделав язык удобным для коллективной работы. Версия 5.4 подарила неймспейсы и пакетный менеджер — PHP стал платформой для больших команд. PHP 7 произвел революцию в производительности благодаря работе Дмитрия Стогова из Core team.
Тут для полноты картины не хватает рассказа о достижениях PHP 6, который собственно и породил разговоры о том, что PHP своё отыграл, т.к. они так и не осилили поддержку Unicode добавить.
Ну и неизбывная особенность PHP - это процедурная стандартная библиотека с несогласованными функциями. Напр. str_split, но strpos (почему не str_pos?), зато у обеих строка идёт первым аргументом. Вроде логично, смотрим str_replace и внезапно основная строка - третий аргумент. О том, чтобы сделать это всё методами объекта String и речи не идёт. Так что никаким полноценным ООП в PHP не пахнет до сих пор.
А так, конечно, PHP не убиваем, столько сайтов на Wordpress, Joomla и Drupal, что если только их сложить уже больше 80% всех сайтов в мире получится.
P.S. Лично я перестал писать на PHP в 2009-м и ни разу не пожалел, в мире есть гораздо более приятные ЯП (и да, тут речь уж точно не про Go), так что не стоит зашориваться на чём-то одном.
Смотря что называть поддержкой. Где-то строка по умолчанию является набором кодовых точек юникода, а массив байт - это исключение. Где-то наоборот - строка по умолчанию это массив байтов, но в определённом контексте она трактуется, как набор кодовых точек юникода. И в том и в другом случае поддержка есть.
Про стандартную библиотеку довод валидный, но, прямо скажем, очень жиденький. Да - и это, и массивы - всё это объективные недостатки. Которые, тем не менее, совсем не тянут на причины смерти. А скорее на объективную критику из раздела "Языки бывают двух видов - те, которые все ругают и те, на которых никто не пишет".
В целом у вас вполне валидный комментарий на тему "почему лично я не люблю РНР". Но пост немного не об этом.
Смотря что называть поддержкой.
Например, успешное прохождение всех проверок из этой статьи: https://mortoray.com/the-string-type-is-broken/
Но пост немного не об этом.
А вот о чём, кстати, пост? По-моему он исключительно о том, почему Альберту Степанцеву нравится PHP. Причём с весьма слабыми доводами и натяжками.
На вопрос из заголовка ответа нет, нет даже доказательств, что PHP является "одним из самых востребованных". То, что в интернете есть куча home pages, которые когда-то были написаны на PHP, а так же миллионы развёрнутых CMS - это имхо не аргумент. Это только показывает, что когда-то он был востребованным.
Для начала бы определиться со скоупом. Востребованный для чего?
Чтобы вести свой блог? Когда-то да, Wordpress в 2 клика в админке хостера и погнали. Сейчас очевидно нет. Соцсети давно уже заняли эту нишу, и поднимать свой личный блог в 2025 году на Wordpress - это шиза.
Чтобы сделать сайт-визитку для компании? Когда-то да, заказали в веб-студии за 20 т.р., они подняли CMS, скин натянули и погнали наполнять. Сейчас очевидно нет. Для компании важнее хорошо оформить карточки в 2Gis и Яндексе, и вести профиль в соц.сетях.
Чтобы сделать свой интернет-магазин? Спорно, конкурентов у PHP тут хватало и 15 лет назад, но допустим. Заказали у веб-студии за 100-150 т.р. разработку и ok. Сейчас очевидно нет. Маркетплейсы полностью вытеснили мелкие интернет-магазины.
Вообще формат CMS потерял популярность, уступив место SaaS решениям. И считать, что 100 тыс доменов привязанных к Tilda == 100 тыс проектов на PHP - это тупо. Это 1 проект, сколько бы там доменов ни было.
А приводить в пример ВКонтакте, который выбрал PHP 20 лет назад и чтобы не загнуться от последствий такого выбора, был вынужден написать свой компилятор - такое себе. Имхо, выглядит как аргумент, почему выбрать PHP было для них ошибкой.
Например, успешное прохождение всех проверок из этой статьи
На всякий случай хочу напомнить, что корректная работа со строками возможно только при наличии идентификатора локали, зашитой внутрь каждой из строк. В большинстве случаев достаточно general, но не всегда (вспомнить случай со взломом Spotify через регистр логинов). Однако я не припомню языков, которые бы использовали привязку к локали. Получается, что в мире не существует ни одного языка, где бы была полноценная поддержка юникода, а какой-нибудь эсцет (ẞ) не вызывал проблем при конвертации регистра.
Верно я понял вашу мысль?)
Ну, эсцет `ß` допускает 2 варианта записи в верхнем регистре `ẞ` и `SS`. Если один из них срабатывает, то имхо норм. Хоть тут и возникает некоторая необратимость в преобразованиях регистра, но для немецкого это в норме вещей. Тем более, что эсцет выходил из широкого употребления ещё в начале нулевых.
iex(1)> String.downcase("ẞ")
"ß"
iex(2)> String.upcase("ß")
"SS"и поднимать свой личный блог в 2025 году на Wordpress - это шиза.
А оставлять личные посты в социальной сети, в которой тебя могут забанить в любой момент под любым предлогом и ты потеряешь доступ ко всей информации - это не шиза, да?
Для особо ценных мыслей есть https://jekyllrb.com/ и куча его последователей, ведёте все посты прямо в Git, реплицируете сколько душе угодно.
Или вы наивно полагаете, что если платите хостеру 200 рублей в месяц, то он не снесёт ваш блог на Wordpress вместе с базой, если кто надо попросит?
Для большинства людей всё это, правда, неактуально. Никому до них дела нет.
Лично мне маркдаун неудобен. Мне, пожалуйста, шашечки (загрузку фото одним кликом, таблицы двумя кликами, выравнивание текста одним кликом итд), я уже вышел из возраста, когда эта эзотерика приносила удовольствие. Я обленился, в плане "личного блога" я пользователь, я не хочу так морочиться.
И да, у меня был личный блог на самописной платформе, на эгее, на HEXO, на ghost и даже на вордпрессе. Самым удобным (для меня!) был таки вордпресс.
наивно полагаете, что если платите хостеру 200 рублей в месяц, то он не снесёт ваш блог на Wordpress вместе с базой, если кто надо попросит
Ну если вы так боитесь "кого надо" - можно же держать этот блог вне юрисдикции "кого надо"?
P.S. А гитхаб репозиторий точно не могут забанить?
Лично мне маркдаун неудобен.
Ну, это вопрос привычки. Согласен. Тем не менее, ценную инфу надо бекапить. Это можно и с обычной базой делать и скачивать бекапы за пределы хостинга. Но вести сам текст прямо в git тут самый простой и надёжный вариант.
Ну если вы так боитесь "кого надо" - можно же держать этот блог вне юрисдикции "кого надо"?
Не надо свои страхи на меня перекладывать. Вы же про бан и потерю доступа писали, не я. В другой юрисдикции сейчас есть также неиллюзорный риск потерять доступ чисто из-за гражданства.
А гитхаб репозиторий точно не могут забанить?
А вы точно программист? Как Git функционирует понимаете?
Если убрать из Вашего сообщения слово wordpress, то получится старый добрый спич, что личные сайты больше не нужны) Ведь есть маркетплейсы, соцсети, мессенджеры и т.д. Это примерно тоже самое, что больше не нужны магазины во двориках, номера такси в телефоне и банковские отделения. Утрирую, конечно, но всему этому тоже пророчат исчезновение не первый год.
А ведь Вы наверняка сами в гугле не только ссылки на соцсети и Озон выискиваете. Те же локальные магазины, скомпилированную простыню про актуальность пхп с неизвестного бложика, подробности, тарифы, условия с той самой визитки. Вы это не замечаете, а на той стороне вполне осмысленно заводят свои ресурсы. Перед покупкой на Озоне вполне себе гуглят производителя иши его цены без комиссии маркетплейсам.
Заводят свой магаз/блог/визитку не для того, чтобы не продавать в ВБ/не вести соцсети, не заполнять карточки в яндекс картах. Это делают в том числе для того, чтобы повысить охват и привлечь всю аудиторию за копейки.
А пока Вы пользуетесь гуглом, это никуда не денется и смысла не потеряет.
Даже чтобы завести личный сайт уже не надо писать его с нуля на PHP, или писать очередную CMS на PHP, как это было модно 20 лет назад.
Я скорее про то, что в контексте востребованности надо смотреть на то, что мы хотим создать сейчас и будет ли PHP для этого лучшим выбором. Оценивать востребованность по количеству доменов, даже не учитывая что там за сайт и в каком году его кодовая база обновлялась, это максимально странно. Вам так не кажется?
Нет) Все эти CMS поддерживаются и обновляются, даже наша DLE. Поддержка старых версий PHP прекращается. В том числе за счет развития самого PHP. А как уже говорили выше - на этих CMS пол интернета сидит и не парится. Другая часть пишет для них плагины, темы и пр. Пока третья выбирает новый фреймворк фреймворка, чтобы потом снова перейти на очередного убийцу всего. Что это, если не популярность?
Все эти CMS поддерживаются и обновляются
Вы, видимо, недавно на PHP. Какие все, их было несколько сотен, вы даже названий большинства не вспомните, какая уж там актуальная версия xD
на этих CMS пол интернета сидит и не парится
Это я не спорю. Я даже уверен, что из них 80% минимум лет 10 ни разу не обновлялись и не парятся.
Что это, если не популярность?
Инерция и безразличие.
Это я не спорю. Я даже уверен, что из них 80% минимум лет 10 ни разу не обновлялись и не парятся.
Есть же статистика, зачем что-то придумывать? https://w3techs.com/technologies/details/cm-wordpress/6
Ага, а если ниже пролистать, то они утверждают что ebay.com на Wordpress сделан. Я бы не доверял адекватности подобных исследований.
Такой себе аргументик)) Можете поискать другую статистику (wappalyzer например).
Эти поадекватнее, хотя бы такой список топ-сайтов на WP выдают:
топ сайты на WP
Есть ещё BuiltWith, по их данным около 21% из Top-1M сайтов используют WP. Но только 7% относительно регулярно обновляются. Другими словами, даже 2/3 топовых сайтов на WP забивают на своевременные обновления движка. Что уж говорить про какие-то личные бложики с аудиторией в пределах 10 человек.
Есть ещё BuiltWith, по их данным около 21% из Top-1M сайтов используют WP
А в топ-10 вообще нет WP. Смотрите общую стату. У них база CMS - 82 ляма, из них 34 - ВП.
Но только 7% относительно регулярно обновляются.
Обновляется абсолютное большинство, ибо ВП все важные обновы накатывает самостоятельно https://wordpress.org/about/stats/
Что уж говорить про какие-то личные бложики с аудиторией в пределах 10 человек.
Тоже самое, что и про всех других.
Я дал вам название хорошей статы, которая инфу собирает не из головы, а по факту посещения и проверки сайта пользователями расширения. Это если есть желание действительно разобраться в вопросе для себя. Мне не надо что-то доказывать)
Сейчас же это спор ради спора. Вы зачем-то пытаетесь доказать то, чего нет, хотя понимаете, что изначальный ваш комент чуть более, чем полностью - ерунда.
Мой изначальный комент был о том, что большинство сайтов в интернете давным давно заброшены, и считать по ним текущую востребованность какой-либо технологии - неразумно. И вы невольно это только подтвердили. Поскольку, раз WP накатывает обновы самостоятельно, значит, даже актуальная версия WP на сайте, ничего не говорит о том, что сайт до сих пор актуален.
Думал, веселее уже не будет)
Поскольку, раз WP накатывает обновы самостоятельно, значит, даже актуальная версия WP на сайте, ничего не говорит о том, что сайт до сих пор актуален.
Как у вас в голове смогла родиться эта гениальная логика?))
А что тут гениального? Вы никогда не видели блогов, где самый свежий пост был 7 лет назад опубликован?
Не припомню. Думаю, среди сотни миллионов вам не сложно будет привести десяток примеров?) Это так, ради интереса
Т.е. вы считаете, если на сайте нет новых постов, то он не актуален? Типа владелец просто так оплачивает хостинг и домен?))
Я вообще считаю, что востребованность ЯП надо оценивать по тому сколько на нём за прошлый год новых проектов начали.
Wordpress, безусловно, популярный движок. Но это всё равно лишь 1 проект, и вообще не важно сколько на нём сайтов развёрнуто. Точно так же как неважно, сколько сайтов работают поверх Tilda или Shopify. При этом все эти 3 проекта уже слишком давнившние, чтобы их учитывать в оценке текущей востребованности каких-либо технологий.
Я вообще считаю, что востребованность ЯП надо оценивать по тому сколько на нём за прошлый год новых проектов начали.
И вы наверно нашли статистику новых проектов, подтверждающих, что их сейчас нет? Нашли ведь?
Скажите, а x86 тоже умер? Ведь сейчас это только древние и Intel да AMD.
А Java/Kotlin когда умрет со своим Andriod'ом?
Swift помянем?
Мб линуксу пора на покой, т.к. там особняком стоят Убунту, Дебиан, да ЦентОС?
Но это всё равно лишь 1 проект, и вообще не важно сколько на нём сайтов развёрнуто. Точно так же как неважно, сколько сайтов работают поверх Tilda или Shopify. При этом все эти 3 проекта уже слишком давнившние, чтобы их учитывать в оценке текущей востребованности каких-либо технологий.
У вас явные проблемы с логикой, что очень странно для программиста. А в данном случае странно вообще для более менее смышленного человека.
Возраст проектов никак не связан с актуальностью, а в данном случае наоборот. Количество установок подтверждает, что до сих пор ничего более актуального в принципе нет.
Мы возвращаемся к началу:
на этих CMS пол интернета сидит и не парится. Другая часть пишет для них плагины, темы и пр. Пока третья выбирает новый фреймворк фреймворка, чтобы потом снова перейти на очередного убийцу всего
Тяжело с вами общаться. Вы вообще не понимаете, что такое востребованность технологии в конкретный момент времени.
По вашему определению и Кобол остаётся одним из самых востребованных языков в 2025 году. Системы на нём есть - есть. Актуальные - ну да, ими же пользуются. Всё, никаких критериев больше вы не в состоянии придумать?
Количество установок подтверждает, что до сих пор ничего более актуального в принципе нет.
Опять вы совершенно не понимаете, что в контексте обсуждения востребованности ЯП - целевой аудиторией являются программисты, а не заказчики. Да, большинство сайтов - это просто развернутые CMS. Есть ли у программистов интерес в таких проектах? На мой взгляд - нет. Чтобы установить CMS не надо быть программистом. И вот вы уже путаете актуальность для клиентов и для разработчиков. И на чём была написана CMS вообще не важно для оценки востребованности ЯП.
Для оценки актуальности, конечно, можно посмотреть сколько программистов работают над WordPress на данный момент:
8 человек сделали 10 или более коммитов за предыдущие 3 месяца
И примерно такая же ситуация будет с любой другой CMS. Вокруг ещё будет несколько десятков программистов, которые периодически пишут плагины. Но в основном так же вяло и не в качестве основной работы. Да и какие новые плагины можно придумать для WP в 2025 году? Чисто поддержка того, что уже давно написано.
Поэтому, когда я говорю, что WP можно считать за 1 проект, это я ещё отдаю ему дань уважения. По факту, в крупных проектах в десятки раз больше разработчиков участвует на фуллтайм занятости, чем тут на парт-тайм.
Можно вспомнить ещё о том, что CMS даёт работу веб-мастерам, которые их устанавливают, натягивают дизайн, добавляют плагины и т.п.
Но давайте всё-таки оставим веб-мастеров в покое, они не должны участвовать в оценке востребованности ЯП, потому что они не разработчики, а по факту продвинутые пользователи CMS.
И вы наверно нашли статистику новых проектов, подтверждающих, что их сейчас нет?
Я хотел её увидеть в этой статье. Но, к сожалению, в статье нет ровным счётом ничего, относящегося к её заголовку.
Тяжело с вами общаться. Вы вообще не понимаете, что такое востребованность технологии в конкретный момент времени.
Я не понимаю ваших критериев, это немного не тоже самое, что общепринятых) Тяжело? Ну вам да. Вы за все время спора так и не смогли ни одного аргумента придумать в защиту своей позиции. Везде после моих аргументов переключаетесь на новый, притянутый за уши, тейк, который двумя кликами в гугле обесценивается.
По вашему определению и Кобол остаётся одним из самых востребованных языков в 2025 году. Системы на нём есть - есть. Актуальные - ну да, ими же пользуются. Всё, никаких критериев больше вы не в состоянии придумать?
Мой главный аргумент - это ~80% всего интернета и ~60% всех CMS. Здесь, сейчас, каждый день, каждую минуту.
Опять вы совершенно не понимаете, что в контексте обсуждения востребованности ЯП - целевой аудиторией являются программисты, а не заказчики. Да, большинство сайтов - это просто развернутые CMS. Есть ли у программистов интерес в таких проектах? На мой взгляд - нет. Чтобы установить CMS не надо быть программистом. И вот вы уже путаете актуальность для клиентов и для разработчиков. И на чём была написана CMS вообще не важно для оценки востребованности ЯП.
Интерес программистов появляется от спроса ЯП. Один ВП дает почти половину мирового спроса. Начинаем по 3му кругу. Еще раз перечитываем:
на этих CMS пол интернета сидит и не парится. Другая часть пишет для них плагины, темы и пр. Пока третья выбирает новый фреймворк фреймворка, чтобы потом снова перейти на очередного убийцу всего
Для оценки актуальности, конечно, можно посмотреть сколько программистов работают над WordPress на данный момент: 8 человек сделали 10 или более коммитов за предыдущие 3 месяца
Это к чему вообще?)) Да хоть один человек запилил CMS и обновляет в ней только совместимость с версиями PHP раз в год. У вас явные проблемы с причинно следственными))
Вокруг ещё будет несколько десятков программистов, которые периодически пишут плагины.
Что-то опять из головы)) Над каким-нибудь yoast трудиться добрая сотня. С которой работают десятки тысяч прогеров. Я уж не говорю про тысячу форков, форков форков и т.д. А еще есть хуки)
Давайте повеселее.. Посчитайте, сколько продается тем под WP, сколько бесплатных. Сколько пишется под себя. Сколько для заказчиков. Сколько переделывается, рефакторится, расширяется, редизайнится, внедряется, подключается и пр.
И где-то целые студии поддерживают свой набор тем, организуют сообщество со своими магазинами плагинов для них, где варятся вообще третьи студии.
А еще Гутенберг есть.
10 прогеров, лол :D Математика для вас тоже небось устарела, кто-то придумал в лохматые и раз в десятилетие что-то новое придумывается)) Ну судя по вашим коментам, у вас свой актуальный фреймворк математики))
они не должны участвовать в оценке востребованности ЯП
Какая оценка? Вы о чем? Оценивает рынок и спрос. В том числе те самые вебмастера, которые ищут в команду прогеров. Или вы решили тут сами за всех оценить?
Я не понимаю ваших критериев, это немного не тоже самое, что общепринятых)
Ok. Давайте дадим точные определения.
Мы обсуждаем востребованность языка программирования (ЯП). ЯП применяется для создания программного обеспечения (ПО). При создании ПО есть этап первичного проектирования и выбора стека технологий, на котором лицо или группа лиц, принимает решение (ЛПР) о том насколько применение тех или иных технологий обосновано для решения задач, которые планируется решить при помощи ПО.
Востребованностью того или иного ЯП является процент ЛПР, которые сделают выбор в пользу данного ЯП, для решения стоящих перед ними задач. В виду этого, обсуждение востребованности ЯП неразрывно связано со скоупом задач.
Вот со скоупом у нас и разночтение. Вы считаете создание сайтов на базе CMS - созданием ПО, а я не считаю. В контексте CMS, я считаю только создание самой CMS (ну и плагинов для неё) созданием ПО.
Дальше определимся с тем, что означает "востребованность в 2025 году". Это то, какой процент ЛПР делают выбор в пользу данного ЯП, начиная создание нового ПО в 2025 году.
Допустимо ещё нормировать востребованность на кол-во создаваемых вакансий в следствии того или иного выбора, чтобы учесть масштаб проектов.
Из этих определений очевидно, что вопрос на чём крутится "~80% всего интернета" не имеет ни малейшего отношения к теме дискуссии.
Над каким-нибудь yoast трудиться добрая сотня.
Ну, зайдите на Github, посмотрите по факту. Трудится над ним 7 человек, остальные изредка что-то коммитят.
А еще Гутенберг есть.
Да, тут активность даже выше, чем в самом WP. Видно, даже что 2 человека на fulltime заняты. И ещё с десяток достаточно активно участвуют. Ok, вы меня убедили, что есть плагины над которыми идёт активная работа и убедили, что WP относительно неплохо накатывает обновления на существующие инсталляции. Но это всё равно остаётся оффтопиком. Разве что мы переформулируем исходную тему в "востребован ли PHP для создания новых плагинов под WP в 2025?". Тут я соглашусь, что востребован. Вот правда, это очевидная подгонка вопроса под желаемый вами ответ.
Ok. Давайте дадим точные определения.
Я уже дал, не старайтесь
Мы обсуждаем востребованность языка программирования (ЯП). ЯП применяется для создания программного обеспечения (ПО). При создании ПО есть этап первичного проектирования и выбора стека технологий, на котором лицо или группа лиц, принимает решение (ЛПР) о том насколько применение тех или иных технологий обосновано для решения задач, которые планируется решить при помощи ПО.
Востребованностью того или иного ЯП является процент ЛПР, которые сделают выбор в пользу данного ЯП, для решения стоящих перед ними задач. В виду этого, обсуждение востребованности ЯП неразрывно связано со скоупом задач.
Вы редактор Вики?
Вот со скоупом у нас и разночтение.
Не у нас, а у вас
Вы считаете создание сайтов на базе CMS - созданием ПО
Это у вас откуда родилось? Оо
В контексте CMS, я считаю только создание самой CMS (ну и плагинов для неё) созданием ПО.
Перечитываем мой предыдущий комент касательно шабов, плагинов, хуков, комьюнити и пр..
Дальше определимся с тем, что означает "востребованность в 2025 году". Это то, какой процент ЛПР делают выбор в пользу данного ЯП, начиная создание нового ПО в 2025 году.Допустимо ещё нормировать востребованность на кол-во создаваемых вакансий в следствии того или иного выбора, чтобы учесть масштаб проектов.
И как там на Вики, как с востребованностью?
Из этих определений очевидно, что вопрос на чём крутится "~80% всего интернета" не имеет ни малейшего отношения к теме дискуссии.
И на чем же? И кому очевидно?
Ну, зайдите на Github, посмотрите по факту. Трудится над ним 7 человек, остальные изредка что-то коммитят.
Те самые 7 человек из 10?
Да, тут активность даже выше, чем в самом WP. Видно, даже что 2 человека на fulltime заняты. И ещё с десяток достаточно активно участвуют.
Так, интересно, еще 2. Где же пропадает оставшийся один человек... Наверно продлевает домен сайта с постаами 7-летней давности.
Ok, вы меня убедили, что есть плагины над которыми идёт активная работа и убедили, что WP относительно неплохо накатывает обновления на существующие инсталляции. Но это всё равно остаётся оффтопиком. Разве что мы переформулируем исходную тему в "востребован ли PHP для создания новых плагинов под WP в 2025?". Тут я соглашусь, что востребован. Вот правда, это очевидная подгонка вопроса под желаемый вами ответ.
У вас плохо с памятью, но вы сами притянули сюда ВП :D Справедливо, кстати. Что я вам и попытался объяснить.
В кейсе ВП вы дали заднюю, это уже прогресс. Поговорим о Джумле? Битриксе? Мб Шопифай? Может какой-то своей CMS? Ой, простите, программном обеспечении. А может сразу Питон или Яву помянем? Кого будем отпевать то?
Для того, чтобы понять востребованность чего угодно, включая сам php, просто откройте статистику. Вы даже пофантазировать на тему не в состоянии. Уж тем более, что-то доказать.
Если что, я намерено не спрашиваю, что у вас в голове живее всех живых. Можете дать ссылку на свой блог ВП... Ой. Соцсеть. Где вы делитесь мнением.
PHP 6 был изначально обречен. Как только появилась идея разделить строки на "строковые" и "бинарные", стало понятно, что это путь в никуда. Обеспечить обратную совместимость было бы невозможно, совместимость двух этих типов - еще более нереально.
Я считаю, что отказ от PHP 6 и закрепление понятия строки, как "последовательности байт" с передачей ответственности по интерпретации этих строк на конкретные библиотеки - это был шаг, который спас PHP от неминуемого конца.
Так что тут не "не осилили", а наоборот "нашли в себе смелость отказаться от заведомого бреда"
Не осилили было в контексте того, что полноценной поддержки Unicode так и нет до сих пор. Проверьте на примерах из этой статьи
Как только появилась идея разделить строки на "строковые" и "бинарные", стало понятно, что это путь в никуда.
Да, в целом, есть языки в которых есть bitstring и просто string. Если нормально всё реализовать, то это даже удобно)
Не осилили было в контексте того, что полноценной поддержки Unicode так и нет до сих пор. Проверьте на примерах из этой статьи
Её нет (полноценной) ни в одном из существующих ЯП мира, лишь ограниченное подобие, увы и ах.
Отчего же, например, в Elixir эти примеры спокойно работают, причём без воркэраундов, без перевода в массивы и т.п.
iex(1)> String.reverse("noël")
"lëon"
iex(2)> String.slice("noël", 0..2)
"noë"
iex(3)> String.length("noël")
4
iex(4)> String.length("😸😾")
2
iex(5)> String.slice("😸😾", 1..-1//1)
"😾"
iex(6)> String.reverse("😸😾")
"😾😸"
iex(7)> String.upcase("baffle")
"BAFFLE"
iex(8)> String.equivalent?("noël", "noël")
trueКонкретно эти может и работают, однако можно найти запросто другие.
Ну например, в методе "String.slice" что означает второй аргумент? Что будет если это применить к 👩❤️👨? Там будет 👩? Или 👩 + U+200D + 🏻? Или вместе с сердцем? Или вернётся "как есть" 👩❤️👨? А если вернёт одно, то почему не другое, ведь оба поведения являются корректными?
А String.reverse из👩❤️👨42 сделает 24👩❤️👨 или 24 + 👨 + U+200D + ❤️ + U+200D + 👩?
А equivalent вернёт true или false при сравнении Floß, floss, floſs и floſʒ? Или это всего лишь метод сравнения строк с разной нормализацией?
Ну т.е. куча всяких кейсов есть, когда можно придраться к мелочам. При этом reverse работает, судя по всему некорректно, т.к. в моём понимании реверс строки -- это реверс чаров в строке, а в вашем примере это реверс глифов внутри строки (?), реверс графем или реверс чего?
Ну например, в методе "String.slice" что означает второй аргумент?
Диапазон означает. От нуля, если считать с начала строки, либо от -1, если надо с конца строки считать.
А если вернёт одно, то почему не другое, ведь оба поведения являются корректными?
Нет, когда я работаю со строкой, я ожидаю, что те символы, которые видны на экране - это и есть символы строки. Соответсвенно 👩❤️👨 - это один символ (хоть терминологически правильнее его называть графемой, но это уже как раз детали реализации). И, в целом, вы тут подловили в том плане, что составные графемы действительно рассыпаются на составляющие части, однако они всё ещё рассматриваются как единое целое и при выводе для пользователя всё получается правильно:
iex(1)> String.reverse("👩❤️👨42")
"24👩\u200D❤️\u200D👨"
iex(2)> IO.puts("24👩\u200D❤️\u200D👨")
24👩❤️👨
:ok
iex(3)> String.slice("👩❤️👨42", 0..0)
"👩\u200D❤️\u200D👨"
iex(4)> IO.puts("👩\u200D❤️\u200D👨")
👩❤️👨
:okПри этом reverse работает, судя по всему некорректно, т.к. в моём понимании реверс строки -- это реверс чаров в строке
Так это у вас неверное понимание. Если хотите работать не со строкой, а со списком байтов или даже битов, то такая возможность тоже есть. Но это уже совсем другая тема.
А equivalent вернёт true или false при сравнении Floß, floss, floſs и floſʒ?
Может, я не понял вопрос. Но это же очевидно не эквиваленты, они при выводе для пользователя выглядят совершенно по-разному.
Вот со смайликом вашим, там эквиваленты, потому что для пользователя будет одно и то же отображение:
iex> String.equivalent?("👩\u200D❤️\u200D👨", "👩❤️👨")
trueДиапазон означает. От нуля, если считать с начала строки, либо от -1, если надо с конца строки считать.
От нуля чего и до -1 чего? Байт? Графем?
Нет, когда я работаю со строкой, я ожидаю, что те символы, которые видны на экране - это и есть символы строки.
А видимость на экране символов зависит полностью от версии юникода, которая поддерживается устройством вывода. Если устройство не будет поддерживать юникод 6 (если не путаю, то это из этой версии), то будете видеть 3 символа, вместо одного.
Но в целом, думаю, понятно что я имел ввиду. В качестве задачи со звёздочкой могу предложить в строке 👩❤️👨42 реализовать все 3 варианта реверса:
Байтики в обратную сторону .
Глифы в обратную строну (
24👨\u200D❤️\u200D👩).Ну и графемы в обратную сторону (
24👩\u200D❤️\u200D👨) по дефолту и так работает.
От нуля чего и до -1 чего? Байт? Графем?
Символов строки, ну или графем (что имхо одно и тоже, когда мы про Unicode говорим)
В качестве задачи со звёздочкой могу предложить в строке 👩❤️👨42 реализовать все 3 варианта реверса
А где тут звёздочка? Элементарно же всё:
iex> "👩❤️👨42" |> :binary.bin_to_list |> Enum.reverse
[50, 52, 168, 145, 159, 240, 141, 128, 226, 143, 184, 239, 164, 157, 226, 141,
128, 226, 169, 145, 159, 240]
iex> "👩❤️👨42" |> String.codepoints |> Enum.reverse |> to_string
"24👨\u200D️❤\u200D👩"
iex> "👩❤️👨42" |> String.reverse
"24👩\u200D❤️\u200D👨"
Её нет (полноценной) ни в одном из существующих ЯП мира, лишь ограниченное подобие, увы и ах.
Во всех - не во всех не знаю, не проверял, но в большинстве мейнмтримных это факт. И это камень в огород наркоманов из комитета, которые науевертили всякой дичи в казалось бы всего лишь таблицу символов
str_split, но strpos (почему не str_pos?), зато у обеих строка идёт первым аргументом
Потому что это просто прокси для библиотечных функций Си. Так исторически сложилось.
А функции на Си кто писал? Пушкин что-ли)
Если вы имели в виду, что это функции из С-stdlib, то нет. Там только такие: https://ru.wikipedia.org/wiki/String.h
А эти хоть и на Си, но написаны разработчиками PHP.
PHP 6, который собственно и породил разговоры о том, что PHP своё отыграл
Я эти разговоры слышал (и даже немного в них участвовал) ещё на рубеже PHP 4 и PHP 5, и были живы проекты на PHP 3 =)
Дело не в том, является ли PHP хорошим или плохим языком, дело в том, что его применение ограничено. Например, я в основном пишу бэкенд на TS, но TS также можно применить в создании интерфейсов, причем в случае веб-приложения у вас фактически нет альтернатив. Можно также писать бэк на Python. Он медленнее и, на мой взгляд, писать крупные проекты на нем сложнее, но он отлично подходит для скриптов, для машинного обучения и т.д. Можно ещё перейти на какой-нибудь Rust. Да, выше порог входа, но это также и высокопроизводительные вычисления. PHP же особо ничего не даёт, у него банально нет киллер фичи.
на раст и фронтенд пилить можно)
*Через костыли в виде wasm и js обвязки
Пока сложно найти много примеров не-демок. Так уж сложилось, что основной язык там js и html, остальное это дополнение.
Wasm не является костылем, а решением. js обвязка копеешная и временная необходимость.
Нуууу. Приведите хоть один намек от wcc на то, что бы wasm получил полный доступ к DOM без прослойки js.
Wasm весит много, дебажить сложно. Не знаю, кажется что убийцей js он точно в ближайшее время не станет.
Вы васм запакуйте в зип, ровно как он передается по http, тогда получится совсем немного. Он жмется же прекрасно. Убийцей становиться никому не нужно. У вас появляется возможность поиметь реакт со статической типизацией. Для многих, кто не могут переварить js, но хотят веб - это выход. Дебажить.. ну смотря что вы хотите дебажить в нем.
Полный доступ к DOM будет, но это не главное сейчас, поскольку оверхеда практически нет.
Простите, я люблю Rust, но зачем его использовать для интерфейсов? Написать на Typescript будет банально дешевле и проще в поддержке, если не лепить говнокод, конечно.
Не все любят TS. Раст прекрасно ложится на васм.
Пример Yew это реакт на расте. Есть еще https://sycamore.dev/ и другие.
Ладно, биндинги я не прав. 20кб всего.
Но, черт, побери, are you really sure?! 386kB для TODO app
Это явно не универсальное решение, и "не делаем фронтед на расте по новому".
Для многих, кто не могут переварить js, но хотят веб - это выход.
Хотите в веб - учите JS/TS. ;)
Единственное, где я могу придумать оправдание Rust + WASM это сложные SPA, Figma или еще что-то. Собственно, они, кажется так и делают.
вообще 20kb многовато, я думал меньше, но так как пока как концепт окей.
Скачайте васм файл и сожмите в зип. Это его реальный размер. Какой будет?
И не забывайте, что там рантайм минимальный вложен, а не только код на расте. То есть увеличение кодовой базы будет увеличивать этот файл незначительно.
Ну js то сам по себе не про веб, про веб это браузерный апи аля, дом, таймеры, fetch, воркеры...
Если вы пишите на расте уже сейчас можно делать сайты вполне себе технологичные. Говорят все же есть профит от статической типизации раста, а не той, которая у TS. Это такой, свежий воздух в определенной степени, чего так не хватало всегда в TS.
Это все только вливает в веб новых разрабов, вам чего тут плохого) По-моему это вообще бомба))
Мне всегда интересен стадный инстинкт. Почему подавляющее большинство решило именно так? Вот и к PHP у меня интерес появился. Стало интересно - почему его все хейтят, когда на нём львиная доля веб-проектов? Стал его учить. До сих пор не вижу ничего плохого.
Потому что простой вход и как правило вам не везёт работать с хорошим кодом. Популярные на рынке Битрикс и Вордпресс это тихий ужас.
Потому что все простые языки специально хоронят. Пример - Delphi
Ну Delphi реально мёртв, а у PHP ласт апдейт 13 февраля
У Delphi прямо сейчас идет сессия вебинаров, а релизы каждые 3-4 месяца.
Ну и много на сегодняшний день разработчиков на Delphi? Покажите вакансии. Давайте сравним с вакансиями пхпшников
Зачем их сравнивать? У них разные области применения. И количество вакансий никак не связано с актуальностью.
А если подумать? Например, почему инструмент регулярно обновляется и имеет немалый ценник? Или его разрабатывают просто для души? Или, может, он пользуется спросом?
Должен заметить, что легаси проекты не совместимы с новыми версиями.
Про кобол так же говорят :)
Вы вероятно удивитесь, но актуальная версия Delphi 12.2 вышла 3 сентября 2024 и релизят новые версии вполне себе регулярно. Более того, он уже довольно давно нативно компилируется не только под Windows, но и под Android, iOS, macOS и Linux.
ни разу не слышал и не видел ни одного примера делфи в мобилках в бизнесе
Компилироваться под Android и iOS и плюсы могут, дело то не в этом
Ну, если вы не видели, это ж не значит, что этого нет. Компания продолжает работать и продавать свои IDE за приличный ценник, проводит конференции и выпускает регулярные обновления. Значит, кто-то их продукты покупает.
В Леруа Мерлен (ЛеманаПро) в крупных магазинах находятся планшеты с приложением на Делфи для просмотра 3д панорам интерьеров. Софт для рендеринга этих панорам - тоже на делфи.
Приложения на андроид на делфи ты вряд-ли отличишь от других приложений. Т.к. делфи создаёт нативные приложения под мобильные платформы.
Что там нет каких-то подводных камней не убедите, у быстрых компонентных фреймворков всегда где-то есть ограничения. Тот же флаттер бы использовал этот же подход, но они пошли по пути 2D движка
Пхп это тяп ляп и в продакшн.
А когда легаси на пхп попадает на сопровождение то матерных слов не хватает. У меня опыт резко негативный.
от проекта зависит, от компании - если нанимали хороших разработчиков - там и легаси такое, что приятно и разбирать его. А если кроили, да раз в год нанимали фрилансеров "добавить акции и подпилить админку" - ну так чего вы хотите
То же самое можно найти на любых других фреймворках популярных и с низким порогом входа
Язык как язык. Си подобный. ОО модель поприятнее, чем в других скриптовых языках.
в PHP есть понятные стандарты
А какой там стандарт на имена функций? Какой регистр?
После js не хватает Promise асинхронщины в стандартном php, приходится по зоопаркам Swoole, ReactPHP, AMPHP ходить.
JS во многом отличается от других языков, и при переходе на него тоже приходится привыкать. Но если говорить про PHP, то внутри кода асинхронщина скорее навредит, чем поможет.
PHP изначально разрабатывался под модель "запрос-ответ" без состояния, и большая часть экосистемы рассчитана на эту модель. Даже если добавить промисы и асинхронное выполнение, это не изменит того что скрипт должен жить столько сколько длится запрос.
FastCGI это то что действительно должно работать асинхронно в PHP. Вместо того чтобы заставлять PHP становиться "вторым Node.js", эффективнее использовать использовать его для того для чего он предназначен.
В мире, где повсеместно используют SOA и микросервисы, проще и логичнее вынести асинхронную обработку в отдельный сервис на Go, Node.js или другом языке, чем пытаться заставить PHP работать не так, как он был задуман.
Пожалуй, первый комментарий по делу
Я помню, как еще в начале 2000-х мои коллеги уверяли, что PHP не переживет появление новых технологий.
PHP 7 произвел революцию в производительности благодаря работе Дмитрия Стогова из Core team. А PHP 8 с внедрением JIT-компиляции, улучшением синтаксиса и новыми функциями открыл еще больше возможностей.
Язык прошел несколько важнейших этапов. Переход от PHP 4 к PHP 5 принес полноценное ООП, сделав язык удобным для коллективной работы. Версия 5.4 подарила неймспейсы и пакетный менеджер — PHP стал платформой для больших команд. PHP 7 произвел революцию в производительности благодаря работе Дмитрия Стогова из Core team. А PHP 8 с внедрением JIT-компиляции, улучшением синтаксиса и новыми функциями открыл еще больше возможностей.
Без обид но дело вообще не в развитии языка а в том что большинство программистов безумно инертны и воспринимают свой язык программирования скорей как религию а не как инструмент. Умножаем это на огромное количество существующих проектов и людей и получается неубиваемый язык. Это относиться не только к PHP но и к многим другим языкам.
Цель нормального инженера - решить проблему. Инженер подберет для этого существующий, хороший инструмент. PHP в свое время (да и сейчас наверное) хорошо подходил для написания простых сайтов. Это было его коньком и он был разработан именно для таких задач. Если нам нужно что-то посложнее и мы, вместо того чтобы просто взять уже готовый обкатанный рабочий инструмент, начинаем из кожи вон лезть чтобы сделать наш любимый язык похожим на "старших братьев", производим всякие революции в производительности, в переписывании всего и вся, подкладывании костылей тут и там (с целью даже не перегнать а просто хотя бы догнать), то это уже не инженерный подход - это уже религия. Задача ставиться не "решить проблему" а "решить проблему но только на своей любимом инструменте".
И это укор не только в сторону PHP. У меня такие же чувства возникают когда я вижу очередную поделку к примеру на Java в стиле IDE, игры или даже БД, которая кушает не в себя память и процессор. И все потому что разработчики для себя впереди поставили не идею хорошо решить задачу а решить ее исключительно любимым уютным инструментом во что бы то ни стало.
Я думаю что вы это не специально, но у вас получился довольно иезуитский текст. Вы намешали верные посылки с неверными выводами и прямыми передёргиваниями. Делая, в итоге, то же самое, в чем обвиняете разработчиков языка: подгоняя аргументы под вывод.
Про религию и инерцию - всё верно. Но это ещё не вся правда. Помимо "любимого инструмента" есть ещё "любимая кодовая база" и "любимая инфраструктура". И решение сразу перестаёт быть таким простым, как "взять подходящий инструмент".
"PHP подходит для написания простых сайтов" - верно. Однако это совсем не значит, что не подходит для непростых. Даже чисто логически вы не можете сделать такой вывод. А практически - попытки "из кожи вон лезть" на самом деле дали очень неплохой результат. В РНР современная поддержка ООП, наравне с другими языками. Симфони вдохновлялась Спрингом, а Лара - Рельсами. В итоге РНР - это как бы два языка: процедурный "уэйл роу = муэскуэль фетч эррей" по гайдам из ютубочки, и вполне себе энтерпрайз с гексагональной архитектурой, DDD, TDD и чёртом в ступе.
Собственно, как раз в идее "всё переписать" куда больше уж извините, юношеского максимализма, чем практичности. Переписать пхпшный монолит на пхп-микросервисы с диспетчером на го? Отличная идея. "Переписать всё" и клепать круды на расте? А не попахивает ли это вашим же "подгонять инструмент под задачу"? При том что энтерпрайз - это как раз круды, на стероидах. И там важна в первую очередь осмысленная архитектура, а не язык. Тем более что всё равно писать будем на фреймворке, а не на голом языке. А разницу в коде на Симфе на Яве вы не враз заметите. Только по долларам и сможете отличить.
>> А разницу в коде на Симфе на Яве вы не враз заметите
Замечу. Код на Symfony современных версий будет короче и значительно чище.
Собственно, как раз в идее "всё переписать" куда больше уж извините, юношеского максимализма, чем практичности.
Нет ни слово про переписывание чего бы то ни было в моем комментарии.
Я написал про то что странно удивляться тому что PHP не умирает учитывая то что у этой экосистемы большое комьюнити а большинство современных разработчиков будут из кожи вон лезть только бы не покинуть зону комфорта.
Можно сколько угодно обсуждать как PHP развивается и как он здорово догоняет старших братьев. Но в факт в том что ему приходится догонять на фоне того что решения которые он пытается догонять существуют десятки лет. Это я к тому что абстрактный конь-инженер в вакууме выбирая из пула решений где есть существующие отлаженные и догоняющие решения, никогда бы не выбрал решение которое успешно допиливается и успешно догоняет, он бы выбрал решение которое уже есть, которое не нужно допиливать и которому не нужно кого-то догонять. Но мы живем в реальном мире где разработчик будет выбирать по принципам личной любви и личной зоны комфорта а бизнес будет исходить от количество разработчиков на рынке и их стоимости. Это все будет формировать популярность и живучесть технологии а не просто за то что кто то старается и успешно догоняет другого.
решения которые он пытается догонять существуют десятки лет
Давайте вы будете подкреплять свои красивые слова фактами? У вас очень красивая и стройная проповедь, но с примерами в ней туго. При том, что все языки развиваются примерно одинаково, и берут друг у друга лучшее. И написать "догоняющий" можно про вообще любой. Тот же C# появился, чтобы "догнать" РНР на его поле.
Мне кажется, ваша проблема в том, что вы не можете толком сформулировать свою мысль. И в итоге подтягиваете трескучие аргументы даже не под конкретный тезис, а под неясную идею. И в итоге доходите до того, что начинаете ставить языку в вину тот факт, что он развивается и становится лучше.
Мне кажется, ваша проблема в том, что вы не можете толком сформулировать свою мысль. И в итоге подтягиваете трескучие аргументы даже не под конкретный тезис, а под неясную идею. И в итоге доходите до того, что начинаете ставить языку в вину тот факт, что он развивается и становится лучше.
А мне кажеться Вы в принципе не читаете то что я пишу и придумываете свою версию и с ней спорите. Хотя вроде бы пишу на русском.
Для меня язык программирования - это просто инструмент которым я решаю проблемы. Т.е. это просто отвертка или молоток. Когда есть проблема я выбираю нужный инструмент и решаю проблему. Если есть более подходящий и интересный инструмент я выберу его. У нас разные подходы, Вы любите инструмент а я качественное решение. То что я хотел выразить я выразил, дальнейшие переводы с русского на русский не имеют смысла.
Я очень хорошо читаю, что вы пишете. Ваши идеи сводятся к тому, что ПХП - язык для говносайтов, и надо было продолжать писать на нём говосайты, а не развивать язык, добавляя в него новую функциональность, и улучшая производительность. А энтерпрайз писать на других языках. Но религиозные суеверия и косность разработчиков зачем-то сделали из него язык энтерпрайз уровня.
Сам по себе ход вашей мысли понятен. Просто посылки, из которых вы исходите, довольно странные.
Для меня язык программирования - это просто инструмент которым я решаю проблемы.
Беда в том, что нельзя решение от проблемы со временем отличить) Сегодня у тебя такой опыт, ты думаешь, что ты решил проблему)) а завтра ты это хрен выпилишь и а там надо что-то менять))
Для меня язык программирования - это просто инструмент которым я решаю проблемы.
Я заметил, что обычно те, кто так пишут не знают нормально ни одного языка. Допускаю, что к вашему случаю это не относится и вы в равной степени расскажете про интринсики в Zend VM и JVM, а не только про отличия DI контейнера Symfony от Angular. Но просто такая мысленная параллель наметилась, что говоря "это такой же инструмент" - видишь код таких людей и охреневаешь от него.
а большинство современных разработчиков будут из кожи вон лезть только бы не покинуть зону комфорта
Как будто что-то плохое.
В конце концов, инструменты нам нужны, чтобы зарабатывать деньги, на которые мы живем. Если у вас наоборот - ну, хорошо вам! Но я что-то сомневаюсь, простите :)
... обвинять людей, которые "не хотят выходить из зоны комфорта" - ну такое... может быть там у человека ипотека и трое детей, он щас из зоны комфорта выйдет, а вместе с ним и его дети.
клепать круды на расте
А очень красиво получается, особенно если с нуля, со стадией обследования предметной области и акцентом на домен.
Вот типичный интернет магазин: как его проектировать
https://LLMshare.syntxai.net/ea215410-167d-980e-c236a710
Красота!
Популярность падает, уже не первый год. Большая часть нового кода в WordPress пишется на JavaScript. РНР не исчезнет, но станет более нишевым.
Если можно давно уже писать бэкенд на node JS. Спрашивается, для чего нужно учить 2 языка и рассеивать свой фокус?
Для себя я писал на node JS и мне было по кайфу что я работаю по ощущениям в одной среде на фронтенде и на бэкенде.
Когда я что-то делаю "для себя", у меня даже в мыслях нет брать php.
Изначально холиварная тема, потому что PHP язык с большой историей, и было там многое. Через PHP многим пришлось пройти, потому что все недорогие хостинги до-облачного периода были shared и разрешали использовать только PHP. Ничего другого просто нельзя было себе позволить. С другой стороны, положа руку на сердце, ничего другого, кроме Perl, и предложить довольно долго было нельзя (потом уже понемногу в эту нишу вошли Ruby и Python, но, скорее, были в те времена как редкая экзотика).
Сейчас я пытался смотреть на PHP 8, и он, вроде бы, выглядит как нормальный ЯП в котором всё есть. Но старый синтаксис никуда не денешь, поэтому мне он представляется запутаннее, чем нужно, и в целом в сообществе сложилась некоторая костыльность подхода. Те же проблемы, кстати, и у JS, который сейчас уже тоже норм и ок, но отмершие практики продолжают хватать его за рукава.
Простой критерий — легко ли разбирать старый долгий чужой легаси. В PHP его разбирать очень сложно (в JS, зачастую, та же беда). Нет, понятно, конечно, смотря кто писал, как поддерживал, какая команда, и пр. Это банальности) Но я пытался разбирать и PHP-код от хороших команд — сложно, блин, почему так сложно (хотя сам-то язык простой). Поэтому нет, не хочется освежать старые знания. Кому дано вместить, тот пусть и вмещает.
Тут скорее не в истории дело, а в базовой архитектуре. Ruby появился в том же году, но изначально был хорошо спроектирован. А Python и того раньше. Хотя, в нём тоже требуются костыли вроде if name == "main". PHP же был ориентирован для встраивания в HTML. Но теперь, с развитием JS и отделением фронтенда, практически не используется в вёрстке, и все те решения в бэкендовом коде выглядят чужеродно.
Это верно. Но это не единственное достоинство пхп. Внешняя многопоточность делает его гораздо более устойчивым к проблемам с переполнением памяти например. Элементарный деплой, который стал уже притчей во языцех. У меня здесь на Хабре был длинный спор с одним явистом, в результате которого выяснилось, что ему проще поправить хранимую процедуру в БД, чем редактировать запрос в коде и потом это всё деплоить. Мы очень долго не могли друг друга понять, это просто разные миры!
В старом долгом чужом легаси обычно проблема не в языке вообще - ибо говнокод можно написать на любом языке.
И древние страшные технологии тоже есть почти везде. Вот например C# вроде красивый, цельный язык с грамотной архитектурой. А в легаси там могут скрываться совсем страшные монстры вроде WebForms - если вы не в курсе там кодогенерация из C# в HTML и JS по древним стандартам и попытка имитировать состояние приложения средствами все того же древнего HTML - оно хранится внутри огромной формы которой является вся страница, которая отсылается на сервер полностью при любом действии.
Зато разработчик пишет как бы на C# как бы десктопное приложение в котором он рисует в дизайнере форму и обрабатывает например на кнопке событие клика в C# вообще ничего не зная о том как это потом оттраслируется в HTML.
Я не думаю, что разбираться в таком легаси будет легче чем в древнем коде на PHP.
Подозреваю что и на Java найдется что-то подобное (ну не знаю какой нибудь IBM WebSphere), тут исключением разве что будут очень узкоспециализированные языки вроде Ruby on Rails (который по сути уже реально умер) или что-то новое и свежее вроде Go (зато как во всем новом и свежем с постоянно меняющейся экосистемой пакетов)
PHP скоро умрет
PHP умирает после каждого запроса.
Надо же, какие у них интересные лычки. Senior+... Потом senior pro, senior max, senior pro max plus?
Для веба (бэка) он хорош, т.к. был изначально для него сделан и постепенно эволюционировал с потребностями и усложнением задачь.
Хотя даже в 2025 я часто использую его изначальный функционал. Есть задача в вёрстке сайтов: разбить на шаблоны, повторяющиеся блоки и т.д. И вот пхп с его изначальным функционалом сюда просто идеально подходить. Никаких велосипедов для gulp для работы с шаблонами не надо, есть уже готовый простой язык, который прекрасно миксуется с html.
Он мегастабильный в работе на хостинге и прост там в настройке.
Сам хочу на один язык перейти - js, чтобы и бэк и фронт на одном писать. Но пока, с одной стороны, спрос со стороны заказчиков на него большой (продукты на пхп). С другой стороны, очень дешевая поддержка со стороны хостинга. Большинству сайтиков обычный шаред подходит.
не пойму, почему автор дезинформирует нас о причинах почему , PHP дурно пахнет и в сообществе разработчиков его не жалуют. это совсем не "«Он слишком простой», «Подходит только для новичков» и «Нет серьезных проектов»". просто сам язык Г. как по синтаксису, так и по типу исполнения в ос. и самое главное - его макаронный подход испортил мозги многим, отбросив на много лет переход на нормальные паттерны.
это с некоторых пор пхп комьюнити одумалось и успела впрыгнуть в последний вагон поезда. MVC и подобные фреймворки и некоторые моменты системные слизанные под копирку с других языков - единственное что оставило его на плаву.
ну и конечно - это наследие. пых реально стал очень популярным и захватил в свое время почти все серваки. сколько понаделали сайтов и проектов на нем. и CMS и тп. так что имея такой прицеп-тележку разумеется как откажешься и всех переучишь. потому сидят на том что было, обновляются в подходах и возможностях вслед за нормальными языками.
когда новые молодые лиды берут с нуля писать серьёзный и не серьёзный проект на нем - это конечно вызывает вопросы. но тоже вкусовщина. да и это наследие пыха еще остаётся в кадрах. найти пышника пока еще проще.
комьюнити одумалось и успела впрыгнуть в последний вагон поезда. MVC и подобные фреймворки и некоторые моменты системные слизанные под копирку с других языков
За другие фреймворки не скажу, но MVC Codeigniter вышел в 2006 году. Для JS тогда придумали jquery, до ноды и Ангуляра оставалось 4 года, до Реакта - 7.
Поэтому обвинять php в отсутствии современных подходов не совсем правильно.
Вопрос в целесообразности их применения везде и всюду.
В Codeigniter был весьма творческий MVC, совсем не соответствующий одноименному паттерну.
В целом, и фреймворки и менеджер пакетов PHP слизал с Ruby. Впрочем, он тут не одинок. Во второй половине нулевых все backend-языки брали идеи под копирку из Ruby-экосистемы
Мне кажется, тут уже нельзя говорить, что и кто у кого слизал.
Это объективный процесс. Все одновременно поняли, что централизованное хранилище популярных библиотек и стандартизированный доступ к нему - это хорошо.
Ровно как маркеты приложений, стриминги и прочее, работающее через Сеть.
Это просто должно было появиться, хорошо это или плохо
Ну, как бы тебе объяснить. Я сам в начале 2008-го начал переходить с PHP на Ruby, и прям сравнивал состояние экосистем на тот момент. А так же смотрел и ситуацию в C#, Java и Python. У Ruby уже был Rails 2.0 с адекватным MVC и REST, и удобный тулинг в виде rake-задач, и управление гемами (пакетами). У PHP ничего из этого не было. Да и у остальных только начиналась разработка бета-версий. Так что тут действительно объективный факт, что в 2007-2012 годах Ruby был локомотивом веб-разработки, а все остальные пытались его догнать и сделать то же самое на своих языках.
И где сейчас Ruby, и где php?
Напоминает анекдот про евреев и фараонов, евреев и гитлера, евреев и сталина...
Да всё там же. На Ruby пишут сложные бизнес-системы с развесистой бизнес-логикой, а на PHP - простенькие сайтики, форумы и т.д.
По количеству доменов конечно вторая категория в сотни раз больше. Но первая в сотню раз интереснее :-)
Некоторые, конечно, пытаются применить PHP для чего-то не совсем тривиального, но, как правило, жалеют потом о таком выборе. Общался пару лет назад с представителями ВкусВилла, жаловались на свои страдания с PHP. В общем, у каждой технологии своя ниша.
Ну вот зачем так откровенно передёргивать? Особенно когда вас поймают за руку раньше чем вы успеете достать краплёные карты. Весь российский екомм - от Ламоды до Буквоеда - на пыхе. И тех-эд в придачу. И без всяких страданий. Я понимаю, что вы сами верите в свою сказку про большой и могучий Руби и хилого заморыша пхп. Но против фактов со сказками сложно. Только и остаётся что рассказывать, что кто-то когда-то вам что-то сказал, или не сказал, или сказал, но не вам.
Весь российский екомм - от Ламоды до Буквоеда - на пыхе.
Странный у вас еком. Где Ozon, Wildberries, Мегамаркет, Яндекс.Маркет, Яндекс.Еда, Самокат, Купер? Надо ли говорить, что PHP нет ни в одном из них? А Ruby, кстати, есть в 3-х.
Lamoda, по сути, ещё один из примеров тех, кто пожалел о выборе PHP и теперь пытаются переучить программистов, чтобы они писали на Go.
Про Буквоед я даже не слышал, это кто вообще?
А Ruby, кстати, есть в 3-х.
Скажите, вам самому не смешно это писать? :) Вот именно так, не "написаны на Руби", а "Руби там где-то есть"? :-D
Ничего смешного. Один прям преимущественно написан на Ruby, в одном значительная часть продуктов на Ruby, и ещё в одном есть немного сервисов на Ruby. А так, разумеется, в каждой крупной компании есть несколько стеков. Просто в каких-то компаниях понимают плюсы и минусы каждого и строят продуктовый ландшафт, исходя из этого.
А в каких-то, типа Ламоды, не понимают и кидаются из одной крайности в другую, где обе крайности плохи. На мой взгляд, их решение полностью отказаться от PHP в пользу Go, да ещё переписать силами только что переученных программистов, такое же недальновидное, как и первое решение написать всё полностью на PHP.
Ну вот у вас и получается в итоге "один" :)
А на РНР написаны десятки.
Но вообще, мы ушли не туда. Речь не в том, "кто выше". А в том, что ваше утверждение про "простенькие сайтики" не выдерживает проверку фактами. Вы или не владеете информацией, или - что вероятнее - сознательно передёргиваете. Фу таким быть.
А на РНР написаны десятки
Ну вот, уже вы сознательно передёргиваете. В российском ecom суммарно то нет 2 десятков крупных проектов. По сути мы уже всё самое крупное перечислили. Разве что AliExpress Россия, X5 и Магнит забыли, но там PHP тоже нет.
Если только Авито с натяжкой отнести к ecom, там местами есть PHP, в основном legacy. Ну и вот Ламода в процессе отказа от PHP. Delivery Club ещё помню с PHP на Go переписывали.
Кого из крупняка ещё можете назвать? По-моему, только мелочёвка осталась.
Яндекс.Еда, Самокат
Как раз Я.Еда и Самокат вполне себе и на PHP (в первом он не основной, во втором вроде основной стек). Про остальные не знаю, но допускаю что в каком-нибудь Мегамаркете или Купере тоже он может быть, но это не точно.
Так что это, конечно, очень смешно. С такой уверенностью ошибаться в примерах, которые же сами и привели.
P.S.
Разве что AliExpress Россия, X5 и Магнит забыли, но там PHP тоже нет.
В X5 и Магните тоже есть. Познакомить вас с разработчиками оттуда? О, в X5 даже богомерзкий Битрикс в задворках обнаружится, а не только полноценные сервисы.
Это что-ж получается-то такое, а?)
Ох, ну вы меня насмешили, конечно 😂
Я так то руковожу одним из направлений разработки в Ecom.tech, к которому относятся и Самокат, и Мегамаркет, и Купер. Ни в одном из них нет PHP. Так что ошибаетесь тут только вы xD
Если уж вам так интересно про Самокат, то тут на бекенде исключительно Kotlin, Ruby и Elixir.
Насчёт Яндекс.Еды уточнил, действительно есть пока legacy на PHP, от которого они планируют избавиться в этом году. Основная разработка идёт на C++, Go и Python. Есть даже статья на Хабре, описывающая их страдания с этим PHP legacy: https://habr.com/ru/companies/yandex/articles/756498/
Я так то руковожу одним из направлений разработки в Ecom.tech
Что-то сомневаюсь, учитывая то, что это прям в вакансиях указано...
Заголовок спойлера
Свой стек не знаете?)))
Если уж вам так интересно про Самокат, то тут на бекенде исключительно Kotlin, Ruby и Elixir.
На Saint Highload++ 2024 мне клятвенно заверяли на стенде, что есть PHP. Что и подтверждается скрином вакансий выше.
P.S. А вот с самого сайта Самоката. Специально для Вас обвёл, вдруг не увидите.
P.P.S. Как-то странно спойлеры работают... Первый сработал, а второй нет
Что-то сомневаюсь, учитывая то, что это прям в вакансиях указано...
Читайте внимательнее, там в скобочках написано Логистика.
Вот она на PHP, но к Самокату этот проект отношения не имеет, хоть и вошёл в холдинг.
На Saint Highload++ 2024 мне клятвенно заверяли на стенде, что есть PHP.
Ну, вас либо дезинформировали, либо вы неправильно поняли. Что, в целом, не мудрено. После слияния компаний в единый холдинг HR-бренд какое-то время назывался Samokat.tech, хотя по факту включал не только Самокат, но и Мегамаркет и Логистику. Это пофиксили переименованием бренда в Ecom.tech
Скажи ещё что Сталин это Гитлер, фараон и Навуходоносор
Я конечно так себе пример, но вдруг кому-то интересно.
В качестве хобби трогал веб-разработку примерно с самого начала двухтысячных. Естественно, первым бэк-языком был php. Какая-то версия еще до 5, так как помню, что с интересом разглядывал ООП в 5.
Но это было очень поверхностно все. Хобби, немного фриланса. Я спокойно стал юристом и отдал этому 12 лет. Раз в пол года смотрел, че там придумали в вебдеве.
Потом решил таки стать говнокодером и перешел в разработку. Поучился на JS, первая работа, Ангуляр по вене, потом Нода. И эти технологии показались волшебными. Работалось легко и задорно.
А потом жизнь опять столкнула с php. По причине того, что двадцать лет назад трогал, разобраться получилось более-менее сразу. И первым делом я по традиции подумал:
-Божечки, какое древнее и тупое дерьмище, почему тут все так...
А потом сделал парочку мелких проектов на чистом php, поковырял Вордпрес и стал потихонечку влюбляться. Как будто через 20 лет замутил с одноклассницей, которая в школе нравилась.
Для своих задач php клевый и удобный!
А большинство аргументов про медленность и неприспособленность к космическим технологиям разбиваются о чугунную жопу реальности: 90% проектов в жизни не нуждается в том, чтобы выдерживать сто тысяч запросов в наносекунду, тянуть триста сторонних библиотек или переписываться каждый раз, когда минорная версия какой-то зависимости оказывается старше недели с момента выпуска.
Слава php!
Неубиваемый PHP: почему в 2025 году этот язык все еще остается одним из самых востребованных