Недавно я решил зайти на сайт cybersport.ru (проект VK GROUP), где хотел посмотреть результаты матчей наших мальчиков по Dote. Мой взгляд упал на статью "Когда будет новый сайт". Там помимо общей информации было пару фраз про PHP и Symfony, которые меня расстроили.
Что же меня меня расстроило
Хотя мотивации писать новую версию проекта все на том же PHP вполне понятна, адекватна и разумна, общий тон ответа содержит извинения за то, что проект пишется на PHP. Словно, вот где-то есть настоящие проекты, на настоящих языках программирования, которые пишут настоящие программисты, а тут пишется поделка на PHP, ибо ничего лучше команда не умеет и не может. Словно люди должны стыдиться, что они пишут на PHP, поэтому вот как-то все обходится фразами "все довольно неплохо". Об этом хочется и поговорить.
Почему PHP стал "плохим" и "постыдным"
В силу того, что в свое время у PHP был достаточно низкий порог входа, и работа по натягиванию шаблонов на различные CMS системы не требовала каких-то глубоких знаний в Computer Science, в PHP пришло много людей, которые не знали, как писать хороший код.
Качество кода таких ребят бросило тень на сам PHP, поэтому в IT-сообществе появились байки, что все PHP-программисты - плохие программисты, а PHP - плохой язык программирования. Вот точно такие же байки, как у всех Subaru проблема с 4 цилиндром, а весь Дальний Восток ездит на Toyota Mark II. Ничего общего с реальностью, но забавно.
На самом деле на PHP создавалось много успешных хайлоад-проектов, где работали талантливые программисты с высоким уровнем профессионализма.
Давление рекламы и лидеров мнений
Помимо того, что PHP имел не самое положительное мнение в IT-сообществе о себе, в инфо-пространство ворвались онлайн-школы, которые по какой-то рандомной причине выбрали python "тем самым языком, на котором с тобой говорит интернет". Это привело к заказам рекламы своих курсов у множества лидеров мнений. Многие из лидеров мнений, чтобы подчеркнуть превосходство курсов по Python, стали топить PHP - его главного конкурента.
Как итог у людей, которые имели мало опыта в программировании, стало формироваться мнение, что PHP - это плохо, не модно, не клево. Да и вообще "Насмехайтесь над ним, гоните его".
К сожалению, статья от редакции cybersport.ru говорит о том, что уже сами команды, которые работают на PHP, стали поддаваться пропаганде, и стали считать PHP плохим языком программирования и оправдываться за это. Это все печально.
Хватит стыдиться PHP
В своих статьях "Стоит ли учить PHP в 2022 году" и "Потрясающее будущее PHP-стека для карьеры" я привел аргументы, почему PHP является клевым, перспективным и эффективным языком программирования, который имеет современную экосистему и готов для решения большого круга, как текущих, так и перспективных задач, стоящих перед современными командами.
Более того, именно PHP дает наилучшие шансы начать карьеру в IT, участвовать в интересных проектах и расти до существенных зарплат, общаюсь с опытными коллегами и перенимать их ценнейший опыт.
PHP - отличный инструмент, поэтому нужно иметь профессиональную гордость, что вы смогли его освоить, и нашли применение своим знаниям на реальных проектах. Я не понимаю, причем тут стыд!
Вернемся к cybersport.ru
Окай, у нас есть контентный проект, где планируется некоторая интерактивность. Для чего ребята вполне разумно выбрали PHP (Symfony) и некоторые event-сервисы, которые (я полагаю) будут написаны либо на node.js, либо на go. Можно ли было выбрать более подходящий стек?
Весь бек на node.js/go/rust - очевидно, что писать бизнес логику на этих языках с админкой, ролями, паблишером, выводом контента и прочими штуками - не самый лучший выбор. Будет долго и неудобно.
Java/C# - удачи найти адекватных ребят в команду, когда за ними уже стоит очередь из финтеха, операторов связи, крупного ритейла, российского FAANG'а, галер и крипто-стартапов. Явно контентный проект не сможет на равных конкурировать за ребят на этом стеке.
Ruby (ROR) - в российских реалиях это новый Perl. Новых проектов пишется не так много, поддержка старых продолжается, интерес молодых ребят минимальный. Как итог, старички на поддержку выбивают очень хорошие условия. Переманивать их сложно и дорого.
Python (Django) - на самом деле хороший вариант, который достаточно неплохо подходит для контентных проектов. Проблемой можно лишь назвать сложность найма адекватных ребят в команду, ибо на рынке много джунов без боевого опыта (ибо проектов на Django не так много на самом деле в РФ (статья на эту тему), а опытные разработчики уже работают в российском FAANG. Ну и самое главное - есть ли какое-то объективное преимущество Python (Django) над PHP (Symfony) - нет!
Поэтому я до конца не понимаю, почему ребята из Cybersport.ru оправдывались в выборе PHP (Symfony), когда они сделали максимально правильное и грамотное решение.
Комментарии (96)
Keks650
20.02.2022 13:06+22Согласен с Автором, современный подход к разработке на PHP сейчас не имеет ничего общего с тем, что было 10 лет назад. И многие колкости в адрес PHP разработчиков это просто тренд (только ленивый не пнёт PHP в попытке утвердиться, что он выбрал более подходящую платформу для разработки).
Периодически встречаю людей которые удивляются, что PHP может делать то, что как им казалось фишка только их языка.
Частично дурную славу языку сделали "кодеры" которые пренебрегали какими-то было паттернами разработки и минимальным тестированием проекта. В годах 2005 ... 2010 на каждом втором сайте были sql инъекции из-за необдуманной подстановки параметров запроса в sql. В этом была н вина PHP а именно тех кто так делал.
А написать плохо - можно на любом языке.
Virviil
20.02.2022 19:47+5Не холивара ради, а только в качестве интереса: не могли бы вы привести несколько примеров таких «фишек», которые есть в PHP а не только в языке X, и заодно сам язык X
Keks650
20.02.2022 21:02+7Если про синтаксис, к примеру лямбды, замыкания, строгая типизация, JIT всё это завезли в PHP.Инфраструктурно - огромное количество пакетов на все случаи жизни, от подключения какого-нибудь менеджера очередей до нейросетей, адаптеры для Oracle и вообще к чему угодно.
csl
20.02.2022 21:21+5заодно сам язык X
А язык с лямбдами, замыканиями, строгой типизацией - например, Haskell.
w96k
21.02.2022 12:51+5PHP не так плох с точки зрения того, что в языке возможно сделать используя его конструкции. У меня лично претензии скорее к историческим аспектам. Очевидный шаблонизатор, который практически заставляет настраивать редактор на автоматическую вставку <?php или пользоваться генераторами как в symfony cli, даже если тебе не нужно генерировать html. Стандартная библиотека со странным неймингом и отсутствием модульности, сам язык зовётся препроцессором, а концепция препроцессинга это прям очень сильный даунгрейд во времена C (с его include), язык модула-2 появился на 6 лет позже чем C, но намного раньше чем PHP в 1978м году (из него модульность стащил Python). В PHP нет модулей в стандартной библиотеке, если запустить php -a, то автодополнение будет работать на ~4.8к функций. Ну и слабая типизация не делает чести языку.
Из «фишек», которые есть в PHP, но нет в других языках (скриптовых) - поддержка LSP (не сервера). "Уникальный" тип данных массивохеш (в документации ещё практикуется подмена понятий из других языков) и проверка типов в рантайме без обязательного указания типа или auto. В целом PHP ощущается как C++ от мира веб-разработки, где в язык тащат вообще всё что можно, есть даже goto. Ну и из очевидных вещей не надо всякие wsgi настраивать. Ещё достаточно удобная вещь есть для дебага без дебаггера var_dump и die, в других языках есть аналоги для интроспекции, но в php вывод var_dump сделан хорошо, а die достаточно короток и понятен.
https://www.php.net/manual/ru/language.oop5.basic.php#language.oop.lsp
https://www.php.net/manual/en/control-structures.goto.php
https://www.php.net/manual/en/language.types.array.php
Лично мне очень не хватает объектной стандартной библиотеке с хорошим именованием. Если без объектном библиотеки, то хотя бы оператора pipe |> не хватает, чтобы собирать в цепочку вызовы функций. Ещё очень не хватает хорошего shell'а на манер python, ruby.
gen
22.02.2022 00:48+3"Уникальный" тип данных массивохеш
Он не уникальный, в Lua есть тип table.
Лично мне очень не хватает объектной стандартной библиотеке с хорошим именованием.
Если уж сильно не хватает, можно воспользоваться каким-нибудь пакетом, например https://github.com/azjezz/psl.
Если без объектном библиотеки, то хотя бы оператора pipe |> не хватает, чтобы собирать в цепочку вызовы функций.
Совсем недавно была отклонена вторая попытка добавить этот оператор: https://wiki.php.net/rfc/pipe-operator-v2. Обсуждение и причины можно почитать по ссылкам:
* https://externals.io/message/109734
* https://externals.io/message/114770
* https://externals.io/message/115333Ещё очень не хватает хорошего shell'а на манер python, ruby.
https://psysh.org/ пробовали?
w96k
22.02.2022 12:33Он не уникальный, в Lua есть тип table.
Не знал про аналог в Lua, но согласитесь такой тип данных не очень популярен в языках программирования.
Если уж сильно не хватает, можно воспользоваться каким-нибудь пакетом, например https://github.com/azjezz/psl.
За рекомендацию библиотеки большое спасибо, скорее всего в ближайшее время начну использовать.
https://psysh.org/ пробовали?
Пробовал, отличный инструмент, хотелось бы видеть его в поставке самого php вместо php -a, писать var_dump'ы и echo в шелле очень неприятно.
gen
22.02.2022 14:23+1Не знал про аналог в Lua, но согласитесь такой тип данных не очень популярен в языках программирования.
Lua был лишь примером, на самом деле много других языков, которые поддерживают разные типы ключей в ассоциативном массиве, вот пример на Go: https://go.dev/play/p/Eb1MhUTaxr1. Кстати, PHP разработчики проделали огромную работу по оптимизации этого типа, в 7-ке появилась концепция "packed array", в 8.1 packed array оптимизировали, убрав ключи во внутреннем представлении структуры. То есть под капотом разделение на map/array уже реализованно в виде
ZEND_HASH_PACKED_*/ZEND_HASH_MAP_*(совсем недавно был толькоZEND_HASH_*). Но я согласен, более специализированные структуры данных не помешают, а пока можно воспользоваться DS :)
Shonina
20.02.2022 13:25+2Как раз недавно встречала мнения, что если топят за какой-то конкретный язык программирования, а другие принижают, то вот "удивительно" этот человек на нем и работает, чаще использует именно его.
А по итогу сейчас (давно) стало просто много распространённых и попросту модных языков (которые таковыми стали в том числе благодаря онлайн школам программирования), но все забывают истину, что язык не главное, это просто инструмент, с помощью которого реализуется проект.
Так что не переживайте, не слушайте никого, занимайтесь тем, что нравится, удобно, всем не угодишь и не докажешь. А так, конечно обидно бывает=))
pae174
20.02.2022 13:53Поэтому я до конца не понимаю, почему ребята из Cybersport.ru оправдывались в выборе PHP (Symfony), когда они сделали максимально правильное и грамотное решение.
Потому что у успешного независимого человека должен быть какой-нибудь якобы недостаток, за который ему якобы неудобно перед соседями, друзьями, клиентами или родственниками - просто что бы им всем не было слишком завидно и что бы они не лезли конопатить мозги.
DeadMaster
20.02.2022 14:35+60Да ладно с имиджем php ещё не всё так плохо, гораздо хуже если вы 1С-ник )))
Akuma
20.02.2022 14:45+5Есть только два языка: те, которые все гнобят и те, про которые никто не слышал.
mitya_k
20.02.2022 15:39+5Странно ставить в один ряд NodeJS c Rust/Golang. Последние низкоуровневые и предназначены быть в своем роде заменой для C++ в определенных нишах.
А на Node JS уже есть навороченные фреймворки: NestJS (похож на Spring) или Adonis JS (похож на Laravel) и т.д.Да, и в эпоху микросервисов и облачных провайдеров не имеет смысла чтобы фреймворк вообще реализовывал все подряд. Зачастую авторизацией и ролями управлять будет отдельный сервис (или облачная служба), а файлы хранить и обеспечивать к ним доступ будет облачный провайдер, а вы будете пользоваться лишь SDK. И так далее.
intelligentpotato
20.02.2022 16:24+13Пишу небольшие микросервисные API на ванильном PHP. Вся логика - запросы к базе, немного арифметики и условий и циклы по массивам. Иногда по очень большим и глубоким массивам. Недавно поймал себя на мысли, что в случае с массивами производительность PHP превосходит мои ожидания. Получается быстрее выдернуть сырые данные из БД и обработать у себя, нежели использовать функции СУБД. К примеру, array_merge() отрабатывает существенно быстрее, чем JSON_AGG() в Postgres. Вкупе с простотой синтаксиса и обширной документацией PHP просто прекрасен. Но не надо писать на нём демоны.
Bonio
20.02.2022 19:35+1Но не надо писать на нём демоны.
Почему нет? На современном php прекрасно пишутся демоны.
TonyKentnarEarth
21.02.2022 02:55+3согласен, на php демоны прекрасно пишутся и успешно живут
и даже более того - есть roadrunner как пример того, что все приложение может работать в режиме демона
iyzoer
20.02.2022 19:40+1Чем плохи демоны на PHP?
naff
20.02.2022 20:28+1Утечками, полагаю.
init0
20.02.2022 23:08+1Расскажите, по вашему опыту PHP априори "течет" или может "дело было не в бобине"?
Mozhaiskiy
21.02.2022 01:42+1Всякие swoole вполне неплохи. Ради гомогенности проекта иногда проще всё делать на PHP, не размазывая систему по разным языкам.
rrrad
21.02.2022 00:56+1Может быть потому что если речь о производительности, то вместо функций json_xxx следует использовать jsonb_xxx? Тип json в PostgreSQL - это просто строка с навешенными ограничениями на содержимое.
SerJook
20.02.2022 16:43Обычно php это что-то не очень серьезное/второстепенное/сделанное побыстрее на коленке.
Я писал на PHP долгое время и перешел на Java, это был как глоток свежего воздуха.
naff
20.02.2022 17:20+6Очень смелое заявление. А как же Авито, Delivery club, Badoo, facebook в конце концов?
Breathe_the_pressure
20.02.2022 17:58+20У них глоток свежего воздуха ещё впереди! :)
naff
20.02.2022 18:24+1Ну авито не сильно страдал, насколько я видел. Сейчас все конечно на микросервисах и go. Второстепенное на php
anaken
20.02.2022 20:07+6Я тоже раньше писал на PHP (около 10 лет), после чего перешел на Java, в основном из-за того что в среднем по больнице оплата джавистов выше, да и не скрою, всегда чувствовалось некое снисхождение от разработчиков на других языках. Хотелось на себе прочувствовать как оно на другой стороне барикады, а вдруг я и вправду "программист второго сорта". Перешел на Java в 2017 году, и вот я senior java developer в очень уважаемой компании. Никакого глотка свежего воздуха в помине не почувствовал, сферы у языков немножко разные, а строгую типизацию можно и в PHP использовать в полный рост, а плохих разработчиков на java пишущих говнокод тоже хватает. Язык безусловно может способствовать выработке правильных методик, но в большей степени этому способствует личное стремление и чтение правильных книг.
rrrad
21.02.2022 01:06Похоже что ваш переход в Java произошел слишком поздно. Есть мнение, что один из мейнстримовых PHP-фреймворков создавался под влиянием опыта использования Spring'а, когда в PHP-мир пришли бывшие java-разработчики.
wolfandman
23.02.2022 00:01+2Я наоборот свежий воздух почувствовал от php после java. На java все пишется дооолго, когда торопиться некуда.
Hett
20.02.2022 16:54-2Ну про дженерики в PHP это громко сказано. Можно сколько угодно хвалить инструмент кроме которого не удалось попробовать что-то еще, только этот инструмент лучше не станет от этого, а лишь появится ложное чувство. Не знаю еще ни одного человека кто с котлина на пхп перешел например, зато наоборот - много случаев. Пока в пхп не появятся нормальные дженерики - не появятся нормальные коллекции и другие структуры данных. Как настрадаетесь с пхпдоком - посмотрите все же по сторонам.
BeMySlaveDarlin
20.02.2022 23:23+3Но... Кроме дженериков все остальное уже есть :(
У вас точно инфа не с нулевых?
Hett
21.02.2022 09:01Нет, не с нулевых. Последний проект был недавно на PHP 8 + Symfony 5.
Не подумайте, я не хейчу PHP, просто не понимаю тенденцию с его нахваливанием: раз в пару недель стабильно статья на хабре какой же PHP недооцененный.
Кроме дженериков все остальное уже есть :(
А что "всё"? Да, добавили тайпхинты и анотации (атрибуты), это был прорыв, можно сказать. Но...
Так как нет дженериков, как уже и говорил, - нет и нормальных коллекций, и это многого стоит.
Расширения пишутся на потустороннем языке, из-за чего они плохо развиваются, так как "обычный" PHP-шник туда не может контрибьютить.
Нет многопоточности (всё, что есть, это костыли)
Нет возможности использовать функциональный подход хотя бы частично там, где это оправдано. Могу привести в пример Java Streams API, хотя бы. А если сравнивать с Kotlin, то совсем грустно.
Даже если в будущем это всё добавят - PHP всё равно отстал навсегда от таких языков как Java, C#, Kotlin. К сожалению. Я для себя не вижу смысла ждать с десяток лет когда это все появится в PHP. Уже сейчас можно взять язык в котором это всё уже есть и даже больше.
Да, стоит заметить, что под каждую задачу нужно выбирать инструмент индивидуально, где-то PHP не плох, возможно. Но зацикливаться на нем не стоит.
FanatPHP
21.02.2022 10:46+2Это просто контр-тенденция. Никто пых особенно не нахваливает, но учитывая количество неграмотного хейта, просто надо ему что-то противопоставить.
BeMySlaveDarlin
21.02.2022 12:23Это не совсем нахваливание. Больше похоже на попытку реабилитировать инструмент.
Все же, несмотря на массу недостатков (помимо перечисленных вами), в своей нише он занимает лидирующую позицию.
Применять Java для клепания публичных презентационных приложений (где не требуется ни алгоритмов, ни структур данных, ни производительности высокой) не совсем экономически обоснованно.
А альтернативы в виде питона, котлина и тд ещё слишком молодые и тоже не имеют той кодовой базы, чтобы с аналогичной скоростью и эффективностью деплоить и поддерживать при схожих затратах.
funca
21.02.2022 19:09-1Применять Java для клепания публичных презентационных приложений (где не требуется ни алгоритмов, ни структур данных, ни производительности высокой) не совсем экономически обоснованно.
Для этого достаточно JavaScript и serverless типа Firebase на бекенде (можно даже с алгоритмами).
BeMySlaveDarlin
21.02.2022 19:20В теории это возможно, но для десятков тысяч РогаИКопыта экономически не выгодно. Так или иначе запилить за пару часов на каком-нибудь вп или джумле х*як-х*як и в прод на порядок дешевле.
Но, как говорится, на чем разраб умеет, то и использует.
Вы пишите на js, ноде и питоне. Они достаточно популярны и в своей нише удобны.
Я пилю на пыхе, го и изредка шарпе, жаве. Причем первое для быстрых апи, второе для поставляемых коробочных клиентов. Они тоже в своей нише популярны и удобны.
w96k
21.02.2022 12:58-1Согласен с приведёнными недостатками. Интересно вводу дженериков не мешает то, что основная структура данных для коллекций это массивохеш.
zandelok
20.02.2022 17:57+2Не вижу ничего плохого в разработке на PHP. Сам-то я RoR, но старший брат всегда писал на php и как-то все норм. А насчёт малого количества проектов на руби и небольшого интереса молодых спецов: не думал, что такая колоссальная разница будет между Беларусью и Россией (я из Беларуси). У нас очень много проектов как продуктовых, так и на аутсорс, а спецов молодых на RoR очень много (чисто в нашей компании курсы по нему постоянно укомплектованны)
Tatikoma
20.02.2022 20:24+3Про то что PHP не подойдёт для websocket и других realtime задач - утверждение как минимум сомнительное. amphp, reactphp, swoole - совершенно замечательно решают этот класс задач. В 8.1 приехали fibers, в связи с чем удобство работы с этими инструментами станет ещё выше. Для особых любителей есть parallel, который позволяет делать realtime-сервисы без асинхронного ввода/вывода (но менее эффективно).
У меня в production stateful сервис асинхронно обрабатывающий realtime трафик, выдаёт по 1000+ RPS на одно ядро (что не много, но вполне прилично и горизонтально шардируется). Никаких проблем с тем что он написан на PHP - нет, у меня в этом сервисе узким местом является не PHP, а rabbitmq, который упирается в 15k RPS в рамках одной очереди (несколько очередей работают корректно, шардируем очереди).
Если есть проблема с realtime-сервисами на PHP, то она у программиста и на других языках будет. Подходы к реализации таких сервисов не отличаются на разных языках, разница присутствует в инструментарии и удобстве работы с ним.
Simipa
20.02.2022 20:42-2Подходы к реализации таких сервисов не отличаются на разных языках
Вот это как раз и не так. На том же Erlang / Elixir накосячить в real-time приложении невозможно by design, просто потому что язык, а точнее виртуальная машина была как раз для этого и создана. Поэтому меня всегда удивляли всякие попытки написания real-time на всяких скриптовых языках. Да, оно работает, да, оно может вывозить тысячи соединений, но Erlang может вывозить миллионы на том же железе. И резкий скачок нагрузки ведь всегда не вовремя, и приходится потом в впопыхах переписывать все хотя бы на Go.
Tatikoma
21.02.2022 00:30+8Когда мне говорят Erlang - я предлагаю посмотреть на RabbitMQ. Чего он такой прожорливый, если должен на том же железе вывозить миллионы ?
alekciy
22.02.2022 22:16+3А много ли удалось написать продуктовых приложений на Erlang за карьеру что получилось составить такое мнение?
P.S. Если что я не против Erlang, что бы это понять достаточно заглянуть в мой профиль. Просто интересно, на чем базируется утверждение про by design.
funca
20.02.2022 22:47-1Про то что PHP не подойдёт для websocket и других realtime задач - утверждение как минимум сомнительное. amphp, reactphp, swoole - совершенно замечательно решают этот класс задач. В 8.1 приехали fibers, в связи с чем удобство работы с этими инструментами станет ещё выше. Для особых любителей есть parallel, который позволяет делать realtime-сервисы без асинхронного ввода/вывода (но менее эффективно).
Сейчас рассуждают как-то так. Нам нужен сервис, обрабатывающий 1000 запросов с ядра. Что будем использовать? Azure и .Net! AWS и Java!! Google Cloud и Go Lang!!!... PHP (вылетает в окно).
funca
20.02.2022 22:05-7PHP был разработан как движок, сильно упрощающий разработку сайтов (по сравнению с "write-only" Perl, который был в этой нише мейнстримом). Как сайд-эффет это означало крайне низкий порог входа для новых специалистов. Оказавшись в нужном месте в нужное время (эпоху доткомов) он быстро стал очень популярным.
Проблема современного повзрослевшего PHP, вобравшего в себя разные навороты из других языков и платформ, в том, что теперь его преимущество не очевидно. Крутые фишки требуют крутых знаний. От былой простоты мало что осталось: в чем-то хуже, в чем-то лучше - он стал как все.
Есть несколько ниш, где PHP может быть ещё долго востребован, чисто по инерции. Это e-commerce (типа 1C Bitrix, Magento), WordPress, несколько CMS ну и разное корпоративное легаси с корнями и традициями разработки из нулевых, которое нужно поддерживать. Но повторить былой глобальный успех ему уже ни когда не удасться.
Чтобы сейчас начинать карьеру в области PHP разработки надо понимать, что в среднесрочной перспективе это путь уникальных специалистов (как COBOL, Perl, Delphi и т.п). Там вероятно можно уже найти неплохие деньги, ввиду специфичности скиллов. Но это рынок работодателя, где увольнение может быть крайне болезненным.
Mellorn
20.02.2022 22:41+5Да ладно.
Вакансий по php море и ещё немного.
И я сейчас говорю о нормальной разработке, а не клепать лентосы на Вордпрессе.
Так что нет, увольнение вот совсем не страшит.
funca
20.02.2022 22:53+1Что вы называете нормальной разработкой, можно пару примеров таких вакансий?
vsh797
21.02.2022 08:47+1На php куча админок, систем управления делается. В т.ч. и с нуля. Как-то в разработке онлайн банка участвовал. На почту постоянно идет поток предложений рассмотреть ту или иную вакансию. Так что с редкостью COBOL вы уж совсем мимо.
И сам php как язык, отягощенный обратной совместимостью с не самыми лучшими решениями, по сравнению с новыми ЯП может и не очень. Хотя и он неплохо развивается. Но вот удобных фреймворков и библиотек на нем написана масса. Так что в целом разрабатывать легко и приятно.
funca
21.02.2022 18:39Наследие эпохи PHP ещё долго будут разгребать и какие-то улучшения там происходить ещё точно будут. Но это не драйв, а движение по инерции. Как я уже говорил, в среднесрочной перспективе вся эта история будет идти только спад: основная масса разработчиков уже развернулась в сторону других языков. https://www.stackscale.com/blog/popular-programming-languages-2021/ Нужны какие-то очень весткие мотивы, чтобы заманить их обратно. Какие?
vsh797
21.02.2022 19:32+2Даже по вашей ссылке php занимает вполне хорошее место. А с учетом того, что он, в отличие от прочих ЯП, представлен только в одной области, так вообще отличное.
Наследие эпохи PHP ещё долго будут разгребать и какие-то улучшения там происходить ещё точно будут.
Новые проекты на нем все так же пишутся. В своей области он вполне популярен.
Нужны какие-то очень весткие мотивы, чтобы заманить их обратно.
Я считаю, что у php довольно пологая кривая обучения, плюс Очень хорошая инфраструктура в своей области. Часто слышу, что php разрабов проще найти / они меньше стоят, что немаловажно для компаний.
Так что доля php может глобально и снижается, особенно за счет узости его применения. Но жизнь на нем вполне есть. И профессионал, и новичок в ближайшие 10 лет без работы не останутся.funca
21.02.2022 21:00Даже по вашей ссылке php занимает вполне хорошее место. А с учетом того, что он, в отличие от прочих ЯП, представлен только в одной области, так вообще отличное.
Он представлен только на первом графике - использования языка. Этот график отражает ситуацию в настоящем как результат каких-то прошлых событийный.
На графике предпочтений разработчиков PHP теперь на 11 месте (если смотреть не в посте, где показано только первых 10, а оригинал survey на StackOveflow). До этого пару лет держался на 8-м. В процентном соотношении так же виден обратный рост. Думаю на счет 10 лет вы правы.
K36
20.02.2022 23:05+3что в среднесрочной перспективе это путь уникальных специалистов (как COBOL, Perl, Delphi и т.п)
PHP is used by 78.0% of all the websites whose server-side programming language we know.
funca
21.02.2022 08:39+1На клиенте там такие же циферки у jQuery, а underscore рвет всех в этом сезоне. Интересного вам кодинга и побольше таких вакансий!)
K36
21.02.2022 10:34+1Интересного вам кодинга и побольше таких вакансий!)
"Нет, сынок, я работаю на интересном стеке в дружной команде" (с)
А вообще я это привел к тому, что PHP живее всех живых и помирать явно не собирается, как тут многие пророчат.
Medeyko
20.02.2022 23:11-10Когда я услышал, что с восьмой версией PHP стал полноценным современным языком, на котором программировать не стыдно, я решил глянуть, действительно ли всё снисходительное отношение к этому языку должно остаться в прошлом, и теперь всё изменилось?
Увы, у меня сложилось ощущение, что нет. У меня от языка как и раньше остался привкус бессистемной поделки. А нововведения мне показались не вполне успешными потугами сделать "как у взрослых". Хотя, конечно, я допускаю, что могло сказаться моё предубеждение.
Но вот, например, оператор match. Даже стрелочки "=>" как "у взрослых". Однако одно из основных его свойств "у взрослых" - это то, что он исчерпывающий (exhaustive). Это, в частности, позволяет избегать достаточно существенного класса ошибок. В PHP 8 же он ничтоже сумняшеся сделан не исчерпывающим - ну а чё, для "хомяков" норм! Я уж не говорю о таких мелочах, как мощь сопоставления с шаблонами (pattern matching) и ограничений ("if" guards), которая отличает match "у взрослых" от старого доброго сишного switch'а. А у PHP не отличает, да, и он остался по сути тем же самым switch'ем, только чуть более эргономичным.
С другой стороны, почему бы и не гордиться тем, что пишешь на PHP? Сейчас эра бодипозитива и всего такого прочего!
init0
20.02.2022 23:26+9Ну вот собственно еще один типичный "специалист" описанный в статье. Сразу видно, что даже в мануал не глядел:
A
matchexpression must be exhaustive. If the subject expression is not handled by any match arm an UnhandledMatchError is thrown.Medeyko
21.02.2022 00:09-2Нет, я читал не мануал, а новости о нововведениях в PHP 8 (PHP - не мой язык, я на нём только чужой код чуть подправлял более десяти лет назад). И я точно помню, там про это не писалось. И я решил, что раз об этом весьма важном моменте не написано, значит, этого там и нет.
Что ж, спасибо, значит, был поверхностен. До более тщательного изучения текущей ситуации с этим языком буду избегать суждений о нём.
Medeyko
21.02.2022 09:53Я подумал, и понял, что ещё ввело меня в заблуждение, кроме отсутствия упоминания об исчерпывающем характере match'а в тех анонсах, которые я читал. А именно, это примеры приводимого в качестве корректного кода конструкции вида:
<?php $expressionResult = match ($number) { 1, 2 => foo(), 3, 4 => bar(), }; ?>То есть я слишком привык немного к другому проявлению исчерпывающего характера match - что такой код, без default, просто некорректен в принципе, а не что это может определяться в процессе исполнения путём обнаружения фактически не обработанного значения, и не смог вовремя от этого абстрагироваться. Хотя выброса исключения вполне логично ожидать для интерпретируемого в своей основе языка.
init0
22.02.2022 02:20А откуда вы взяли этот пример корректного кода?
Medeyko
22.02.2022 06:36-1Пример был синтетический. Но и правда, лучше обратиться к мануалу, ссылку на который Вы дали.
Там в самом начале приведён Example #2 Basic
matchusage, который имеет именно указанную проблемную структуру - match делается по строке, от которой обрабатываются только три варианта.(На самом деле я вспомнил, я таки смотрел в мануал, и увидев пример с откровенно не exhaustive match, не стал читать дальше.)
qw1
21.02.2022 10:03+3Исчерпывающий match записывается явно, в коде должно быть прописано поведение на все ветки. Для ошибок меньше возможностей. А кидать exception это какая-то полумера. Может вылезти в runtime через какое-то время.
init0
22.02.2022 02:16Все верно, вы должны записать его явно. А кидать exception это как раз таки правильное поведение - забыли указать, отловить в try catch и тем более покрыть тестами - останов, а не как раньше со switch - непонятно что пошло "гулять" дальше по рантайму. Компилятор/интерпретатор не должен за вас решать такие задачи. Не силен в других языках но судя по этому поведение там подобное.
Medeyko
22.02.2022 07:09+1Нет, как раз это дело компилятора и даже интерпретатора. В Скале, Расте и Джаве код не скомпилируется, если компилятор не смог удостовериться, что рассмотрены все варианты. И это очень важно, потому что позволяет избегать большого класса ошибок, в том числе - приводящих к уязвимостям.
Приведённые по вашей ссылке примеры относятся к enum'ам, перебираются все их варианты, и поэтому default не нужен. В Расте можно не ставить рукав "_" например в случае, если match идёт по u8 (байт), и рассмотрены все его 256 вариантов.
Но в конструкциях, аналогичных примеру Example #2 Basic
matchusage из мануала по PHP, указанные мной языки потребуют рукава, срабатывающего по умолчанию ("_", "default").PHP - язык в своей основе интерпретируемый. Но это не значит, что ничего нельзя сделать. Например, можно сделать рукав defaul синтаксически обязательным и выдавать ошибку сразу при попадании на match без default (как, например, сейчас в PHP выдаётся синтаксически ошибка при попадании на match с двумя рукавами default). На худой конец, даже если по какой-то причине с языком ничего не сделать, на крайнюю желательность наличия рукава default нужно было бы сделать акцент в документации с самого начала.
В отличие от указанных мной языков, подход PHP с выбрасыванием исключения при выявлении фактического экземпляра непокрытого значения в runtime приводит к тому, что ошибка выявляется не сразу на этапе создания программы, а уже в продакшене, когда пользователь ввёл нетипичные данные, например. То есть этот подход провоцирует на написание не очень хорошего кода. Но безусловно, это несколько лучше молчаливого старого switch.
caballero
21.02.2022 02:49+17Как по мне стыдится нужно нынешнего яваскриптового безумия.
И кстати большинство быдлокодеров сейчас идет именно на фронтэнд.
aceofspades88
21.02.2022 10:24ну так к фронту сбоку ноду с монгой за 10 мин и вот уже все кликается сохраняется, манагер счастлив можно клиенту сдаваться)
caballero
21.02.2022 14:13не выйдет потому что большинство фронтэдщиков понятия не имеет что делает бекенд и заче он вообще кроме загрузить яваскрипты а работа с сервером БД для них это как квантовая теория поля
Valser
21.02.2022 03:15Python не конкурент PHP, они просто созданы были для разных целей, а в процессе эволюции, Python обрастал новыми возможностями для улучшения системы, на которой он изначально запускался (Linux), а эволюция РНР шла другим путем и в какой-то момент затормозилась на много лет и это дало бурный рост фрейворкам РНР, так как рынку нужны были новые функции, а РНР их им не давал, по разным причинам. И теперь это совершенно разные игроки на рынке и между ними конкуренция если и возникает то это во время вопроса "А на чём сверстать лингпединг?". Для остальных выбор очевиден иногда он за Python, а иногда это РНР начиная этак с версии 7, хотя конечно лучше 8.х...
zynaps76
21.02.2022 04:49+4PHP - язык, как язык. Да, он как и питон - некомпилируемый, и куча шибок вылазит при исполнении, а не компиляции. Да, по-моему, там все еще все плохо с многопоточностью и черт его знает, как писать демонов, которым надо все и сразу, а не линейно. Да, всякие приколы по типу массивов, которые и не массивы вовсе, а типа хешмапы с ключом произвольного типа. Да, по сравнению с гошкой или скалой/джавой - тормоз он тот еще, если надо чиселки подробить. Я где-то могу ошибиться, так как давно уже ничего не писал на нем... сорян, если что.
Но с другой стороны - PHP на синтетике до 10 раз быстрее модного питона (тут у питонистов обычно челюсть отваливается). Библиотек / фреймворков на все случаи жизни - навалом. Любая проблема - все уже разобрали на всяких stackoverflow и не надо голову ломать. Всяких модных штук в язык тоже завезли порядком.
У него действительно только одна "проблема". Из-за низкого порога входа туда пришло очень много людей с низкой квалификацией творить дичь. :) Как сейчас - не знаю.
imho.
Tatikoma
22.02.2022 18:59-1У PHP тонна проблем, например отсутствие доступа к SO_ORIGINAL_DST, который в linux активно используется для написания прозрачных прокси.
Yusuper4ik
21.02.2022 05:51Наоборот говорю всем и каждому, что прогаю на пхп. Если сам не стыдишься, то и люди начинаю по другому воспринимать это, и даже нет попыток посмеяться надо мной или языком
pprometey
21.02.2022 05:54Ну вот ты сам автор, признал то, чему якобы в своей статье пытаешься противостоять
Java/C# - удачи найти адекватных ребят в команду, когда за ними уже стоит очередь из финтеха, операторов связи, крупного ритейла, российского FAANG'а, галер и крипто-стартапов. Явно контентный проект не сможет на равных конкурировать за ребят на этом стеке.
Получается раз Java/С# востребованы, то зачем этот PHP? Ну переучись ты на другой стек, это не так уж сложно, если голова работает правильно... И будут за тобой стоять очереди эйчаров.
И есть вполне объективные причины, почему эти два языка более востребованы чем PHP.
И сравнивать PHP и Python - не совсем корректно. Phyton - это еще и про bigdata, чего PHP практически не умеет. Не его стезя, в отличии от Python и написанном для него кучи библиотек.
Вот как правильно заметил, остается маленькая узкая ниша, и то, лишь только потому что "мы умеем в это". А других аргументов то и нет.
PHP я думаю это тупиковая ветвь. Рано или поздно вымрет после очередного перехода к какому-нибудь web 4.0.И правильно. Я бы тоже на месте ребят из симфонии стыдился, именно как ИТ-специалист. Современное ИТ развивается так стремительно, что работа в ИТ это как бег за поездом, который отъезжает с большей скоростью чем ты его догоняешь. И вопрос тут только в том, насколько далеко этот поезд уедет. И очень важно догонять тот поезд, который не упрется в тупик. В случае PHP - у меня лично нет сомнений, что все закончиться тупиком.
vsh797
21.02.2022 09:07+3На рынке кроме фактора спроса на язык есть еще и предложение спецов, умеющих в него. И на php, imho, проще начинать. В т.ч. из-за кучи фриланса и простых инструментов на нем.
переучись ты на другой стек, это не так уж сложно, если голова работает правильно…
А чем backend на java принципиально лучше, чем на php?
У меня в команде работал чел, перешедший с C# на php. Говорил, что Doctrine получше чем EF. Да и работу новичку проще найти.И будут за тобой стоять очереди эйчаров.
За толковыми php-шниками тоже очередь. Видимо, везде сейчас так.
zynaps76
21.02.2022 11:35+2Получается раз Java/С# востребованы, то зачем этот PHP?
зачем, зачем. затем... hh.ru, moscow: C# от 205.000 руб.: 359; PHP от 265.000 руб.: 254.
aelaa
21.02.2022 08:47-1Я правильно понял, в призывах перестать критиковать PHP автор раскритиковал (тут было более грубое слово) все остальные технологии?
THQSql
21.02.2022 08:55-7Проблема PHP в том, что написанные костыли в до 7-е версии времена, сейчас исправляются новыми костылями.
PHP сам по себе хороший инструмент, но только для тех задач, для которых он изначально был придуман. Для панелек, админок и сайтов лучше ничего нет.
Мелочь всякую можно закрыть, чтоб не изучать новый стек, но писать что-то масштабное исключительно на не предназначенном для этого PHP не стоит. Хлебнёте проблем.
У меня был такой опыт. Правда есть один существенный плюс - опыта хапанёте вагон и маленькую тележку)
nsrwork
21.02.2022 12:57+2Вы сейчас находитесь на сайте, который написан на php. По вашему это мелочь?
Bagir123
21.02.2022 16:43-2Я переходил с php и vb.net на c#. Что касается php, то меня наоборот не устраивает неявная типизация и как следствие проблемная отладка. Ещё меня не устраивает открытый код, поскольку это лишает заработка от поддержки проекта и авторских прав, создавая ситуацию частого рефакторинга кода.
i9i6
23.02.2022 00:10-1Как по мне: автор не прав в исторической справке. Язык стал считаться позорным до распространения cms, еще когда только появился все к нему относились как к недоязыку - вроде "подумаешь скриптики для хомяков, он ведь даже не компилируется". А потом только список претензий менялся.
sedyh
А вот мне это не очевидно, почему node.js и go поставлены в один список с rust?
Murtagy
А мне не очевидно почему в один список их ставить нельзя?
Ведь рассматривается конкретный контекст веб-серверов, где на раст тоже есть популярные решения
asd111
Код на расте не уступает в сложности с++, он безопасный но такой же сложный. В отличие от go,nodejs.