Это не так. PHP не умер. Он жив, и до “конца жизни” ему еще очень далеко. На этом все. Как бы некоторые ни хотели, чтобы он исчез, этого не произойдет. По крайней мере, в обозримом будущем уж точно.
Эта статья пролежала в моей папке для неопубликованных достаточно долго. Время от времени я вносил правки то тут, то там, но все никак не мог определиться со временем публикации. Но вот релиз PHP 8 наконец показался мне подходящим моментом.
Каждый месяц мне попадаются статьи, комментарии, или твиты, в которых говорится, что PHP умирает, и нам пора прекращать его использовать. Если кто-то задает вопрос на каком-либо форуме или на Stack Overflow касательно изучения PHP, с вероятностью почти в 100%, кто-то ответит что-то вроде: “Зачем вам изучать PHP? Потратьте время на что-нибудь стоящее, например <здесь-должен-быть-ваш-замечательный-язык-который-не-php>”.
На протяжении последних 20 лет, помимо других языков, я писал код на PHP (на самом деле, может быть и дольше. Я точно не помню, когда я начал это делать), и большую часть времени я просто игнорировал эти высказывания. И все эти годы PHP “умирал”, и я должен был бросить его использовать уже очень давно. Я отнюдь не претендую на звание эксперта ни в одном языке, которые я использую, и в PHP есть еще много вещей, в которых мне не мешало бы разобраться, но снова и снова я возвращаюсь к нему.
Я потратил много часов на изучение других языков, на что меня подтолкнули случайные, убедительно написанные статьи критикующие PHP. И я признаю, что эти приключения естественно были в высшей степени полезны для меня как для разработчика. Хотя я, вероятно, никогда не буду использовать многие из этих языков профессионально, я чувствую, что расту как программист, изучая другой язык.
Главная мысль, которую я хотел бы донести в этой статье: “выучить другой язык” — идея очень хорошая, но не потому, что “php умирает” — это просто неправда. Вы должны учить другие языки, потому что они будут полезны для вас как для программиста. Если бы PHP действительно умирал, то, конечно, у вас была бы еще одна (достаточно веская) причина двигаться дальше, но прямо сейчас, в данный момент, он не умирает.
Один из первых аргументов многих PHP-программистов, которым они будут парировать, отстаивая свой выбор, — это статистика, демонстрирующая, насколько PHP популярен в сети. Хотя эти цифры очень интересны, я склонен полагать, что они немного вводят в заблуждение. Было бы неправильно игнорировать тот факт, что львиной доле этой популярности PHP обязан WordPress. Любить его или ненавидеть, решать вам, но WordPress — причина, по которой мы все здесь. Но WordPress… такой… WordPress. У него много (действительно много) недостатков, но я знаю (и дружу с) множеством людей, которые создают много удивительных вещей — и зарабатывают большие деньги — с помощью WordPress.
PHP — это не WordPress. И, хотя WordPress увековечен в истории PHP, PHP лучше, чем WordPress — НАМНОГО лучше. В WordPress много чего не так, как и в PHP, но это не значит, что он не подходит для всех проектов. Я, вероятно, не стал бы писать свои веб-приложения на C++ (или, по крайней мере, он не стал бы ПЕРВЫМ среди языков, рассматриваемых для работы над этими проектами), но это не делает C++ плохим языком. Он просто не подходит для этой работы, точно так же, как я бы не стал использовать PHP для написания аппаратных драйверов или чего-то еще, связанного с ИИ. И дело просто в том, что это выходит далеко за пределы его специализации.
Выбор языка также во многом зависит от того, в чем вы разбираетесь. Как гласит старинная пословица: время — деньги, и в большинстве случаев использование нового языка для проекта — это серьезная затея, которое еще больше урезает временные рамки, которые обычно и без того очень сжаты. Я достаточно хорошо знаю PHP, поэтому в основном использую именно его. Я немного знаю Python, но лучше разбираюсь в PHP. Я, вероятно, мог бы сделать то же самое на Python, но это займет у меня вдвое больше времени (по крайней мере, в начале). Это не означает, что я вообще не буду использовать Python или что я имею что-то против Python, это просто означает, что PHP — это то, в чем я лучше.
Изучение языка на самом деле не так сложно, и опытный программист может понять суть языка, посвятив ему всего одни выходные. Но это не значит, что этого достаточно, чтобы в полной мере знать язык. Знание языка программирования — это не только знание того, какая встроенная функция что делает, но и наличие достаточного опыта, чтобы знать, КОГДА и какие фичи использовать или как экосистема сочетается друг с другом.
Я знаю PHP, и также знаю, как настроить Nginx на сервере и как конфигурировать FPM или opcache; У меня достаточно знаний, чтобы сделать разумный выбор в отношении зависимостей; Я знаю, как безопасно развертывать PHP-приложения в рабочей среде, и мне известно о проблемах безопасности, которые могут возникнуть, если я не буду внимательно следить за тем, как я использую определенные языковые фичи. Это больше, чем просто “знание” языка. Как программисты, мы тратим много времени на изучение подобных вещей, которые часто даже не связаны с языками, которые мы выбирали.
Вот почему меня очень разочаровывает, когда другой программист говорит мне, что мой выбор языка — “отстой”. Я потратил 20 с лишним лет, совершенствуя свои навыки, но теперь какой-то человек заявляет, что мой выбор был неправильным?
Что ж, они ошибаются. С помощью PHP я сделал свою карьеру, которой я очень доволен. Я живу в хорошем доме, езжу на отличной машине, потому что потратил 20 лет на то, чтобы стать по настоящему успешным в этом деле.
Но я немного отвлекся. Эта статья должна была быть о том, что PHP не отстой.
Многие из кружка “мы ненавидим PHP и думаем, что он скоро умрет” говорят о ряде вещей, которые, по их мнению, делают PHP плохим выбором во всех отношениях. Некоторые из них мы слышим годами и они имеют отношение к старым версиям PHP (я не понимаю, почему все до сих пор так зациклены на PHP 4, я серьезно). Остальные претензии просто безосновательны и не соответствуют действительности. Это не разглагольствования на тему “мой язык лучше твоего”, и я искренне верю, что у каждого языка программирования есть определенная цель. Люди, которые приносят эти инструменты в мир (которые намного умнее меня), обычно делают это не без оснований. Языки программирования обычно не появляются случайно.
Итак, почему PHP?
Ответ очень прост: потому что тогда он был доступен. Я самоучка, и как-то обошел стороной формальное образование. За исключением, может быть, случайных онлайн-курсов, которые я проходил, у меня нет листка бумаги со штампом престижного университета, на котором написано, что я могу говорить компьютерам, что делать.
Я пришел в PHP из дизайна, и несмотря на то, что я возился с компьютерами и кодом лет с семи, я не последовал за этим увлечением и не поступил в университет на программиста. Я точно не смогу вам ответить, почему. Мне нравились компьютеры, и мне нравился интернет, но вместо этого я выбрал графический дизайн. Я не собираюсь особо углубляться в это, потому что моя ученая степень особо не играет большой роли в том, чем я занимаюсь сегодня.
Я пришел к PHP тем же путем, что и большинство PHP-программистов. Потому что мы хотели, чтобы сайт мог делать больше, чем просто отображать изображение и абзац текста. Я был невероятно взволнован, когда понял, как получить информацию из базы данных и отобразить ее на веб-странице. Это было потрясающе! Это было именно то, что мне было нужно, и я сразу нырнул в PHP с головой.
Затем я узнал о WordPress. И, как и для любого другого человека, сидящего перед экраном компьютера с некоторыми базовыми знаниями PHP, WordPress перевернул мой мир. Это было круто, правда?
WordPress обязан своим успехом таким людям, как мы - подросткам, которые хотели свой блог, но у них не было достаточно знаний для того, чтобы создать его самостоятельно.
Вы установили WordPress... Затем добавили плагин и изменили тему... Потом внесли небольшое изменение в тему, чтобы она работала по-другому или выглядела немного иначе. Затем вы модифицировали плагин. Затем вы создали свою собственную тему. После чего вы задумались... А что еще я могу сделать?
Так я познакомился с PHP. Я не выбирал PHP, он выбрал меня. 20 прошло, а я все еще пишу на PHP. Конечно, больше не через WordPress, и мне нравится то, что я уже достаточно вырос как PHP-программист, чтобы со знанием дела написать эту статью.
“PHP слишком прост. Лучше выучи что-то посложнее”.
Одна из основных причин, по которой PHP так популярен, заключается в его повсеместном использовании. Его можно найти почти везде. Да даже самый обычный MacBook поставляется с предустановленным PHP (хотя похоже, что это изменится в будущей версии MacOS).
Писать на PHP с нуля не сложно. Обычно ничего особенного делать не нужно. Создайте index.php, поместите в него одну строку PHP-кода и загрузите практически на любую учетную запись общего хостинга:
<?php
echo 'Hello, World!';Начало положено. Начать работу с PHP очень просто, потому что вам не нужно думать о том, как заставить PHP работать. Это почти всегда уже сделано за вас.
Однако, представьте себе, что именно эта “простота использования” на самом деле является одной из претензий к PHP. Теория гласит, что если PHP настолько прост, то на PHP очень легко написать действительно небезопасный код.
Меня всегда это немного настораживало. Значит ли это, что языки, которые труднее использовать, с меньшей вероятностью будут использоваться для написания плохого кода? Я где-то читал, что около 70% патчей, которые Microsoft выпускает для Windows, предназначены для решения проблем с памятью, возникших из-за C++ (но не цитируйте меня, это не официальное заявление). Я сомневаюсь, что люди, которые пишут на C++ для Microsoft, любители, и я почти уверен, что они знают, что делают. Да, Windows намного сложнее, чем ваш типовой сайт с корзины покупок, но я думаю, что аргумент остается в силе. Я не согласен с тем, что простота использования PHP делает его потенциально опасным. Python хорошо известен за то, как он удобен для начинающих, но не имеет такой “потенциально опасной” репутации. Легко написать небезопасный код на ЛЮБОМ языке. Не язык делает код небезопасным, а недостаток знаний.
“Простота” — это не причина отговаривать новичков от изучения PHP, а, скорее, причина дать этим новичкам лучшие инструменты для принятия более взвешенных решений относительно кода, который они пишут. Это повод помочь им найти нужные ресурсы для изучения PHP. Мне очень повезло; и хотя я написал свою долю “небезопасного” кода, в моей жизни были люди (не всегда PHP-программисты), которые помогли мне понять, что можно улучшить.
PHP медленный
Что ж, это неправда. PHP работает настолько быстро или медленно, насколько написан ваш код. PHP — это скриптовый язык, поэтому сравнивать его с компилируемыми языками бессмысленно, но почему-то я даже видел, как люди сравнивают PHP с Rust или Go. Но это просто бессмысленно. Сравнение PHP с Python или Ruby, вероятно, понятнее, но “скорость” языка зависит от ряда различных факторов. Сам язык, да, но также его среда, какой код он выполняет, как настроен интерпретатор и т. д. Говорить, что PHP медленный без контекста, неправильно.
PHP определенно медленный в отношении определенных типов задач. Например, PHP, вероятно, не станет вашим первым выбором, если речь идет о машинном обучении (хотя есть несколько очень интересных проектов, которые имеют вполне реальные перспективы).
Можно встретить бенчмарки двух разных языков, выполняющих одно и то же, например, перебирающие миллион записей и выполняющие простые вычисления. Результаты часто отличаются миллисекундами. Иногда это используется, чтобы показать, что PHP работает медленно (или, в некоторых случаях, быстро). Если вы пишете программное обеспечение, в котором лишние несколько миллисекунд при циклическом просмотре миллиона записей были бы катастрофическими, то, возможно, вы задаете неправильные вопросы.
WordPress плох
Да, я согласен. Я не самый большой поклонник WordPress, особенно в наши дни, но я также готов признать, что без WordPress у нас, вероятно, не было бы того PHP-сообщества, которое существует сегодня.
Однако судить о языке по одному программному обеспечению - это неправильно. Это все равно, что сказать, что C++ — плохой язык, потому что вам не нравится Microsoft Windows.
PHP — это не узкоспециальный язык, а WordPress — это только часть истории PHP. Существует множество фреймворков и пакетов на любой выбор, если уж на то пошло. Laravel пророчат “снова сделать PHP крутым”, и я должен признать, что этот фреймворк, безусловно, один из моих любимых и он удобен для большинства проектов.
Хулить PHP, презирая WordPress, действительно несправедливо. Можно утверждать, что WordPress был отражением ограничений PHP, но это было давно, и с тех пор язык сильно вырос.
PHP не дотягивает до корпоративного уровня
Почему? Я действительно не понимаю, откуда это пошло. Но это серьезное заявление. Что делает язык “корпоративным” (enterprise ready)? Как определить, что один язык более корпоративный, чем другой? Java, вероятно, является одним из самых популярных языков в корпоративной среде, но это не потому, что Java сам по себе корпоративный. Причина в существовании платформы Java EE. Я не Java-разработчик, поэтому поправьте меня, если я неправ, но, насколько я понимаю, Java EE — это платформа, на которой создаются корпоративные приложения. Звучит как фреймворк, верно? Так что, возможно, вопрос должен звучать так: “Дотягивает ли <мой-любимый-php-фреймворк> до корпоративного уровня?”.
Для ответа на этот вопрос нужна целая отдельная статья. Я пытаюсь подчеркнуть, что PHP как язык настолько же “корпоративный”, как и любой другой язык. Это целиком и полностью зависит от того, как вы его используете.
Примечание: некоторое время назад я был частью небольшой команды, которая создала и развернула платформу управления событиями во внутренней сети одного из ведущих финансовых учреждений Южной Африки (я мог бы написать кое-что об опыте). Приложение было полностью написано на PHP и JavaScript. И в разгар пандемии Covid-19 система находилась под огромной нагрузкой, но справилась почти со всем. У нас было несколько заминок, но ничего такого, что нельзя было бы решить быстро.
PHP не масштабируется
Это единственная претензия, в которой есть доля правды, но и тут все немного сложнее, чем вы думаете. По правде говоря, PHP прекрасно масштабируется, если вы пишете нормальный код. Когда люди говорят, что PHP не масштабируется, они обычно имеют в виду, что приложения, написанные на PHP, могут быть не в состоянии обрабатывать очень большое количество запросов (например, миллионы). Дело в том, что это все не так просто, и я думаю, что многие заблуждения уходят корнями в WordPress, который до недавнего времени был хорошо известен своими проблемами с масштабируемостью.
В качестве доказательства: Slack, платформа обмена сообщениями, которая нацелена заменить электронную почту, с миллионами пользователей, каждый из которых подключается каждый день к системе, имеет бэкенд написанный на PHP. Если это не пример того, как PHP может масштабироваться, то я не знаю, что вообще вас может переубедить. Многие люди приводят Facebook в качестве примера, и хотя я считаю, что Facebook, вероятно, все еще использует PHP в той или иной форме, я думаю, что они, скорее всего, перенесли большую часть своих приложений с PHP. Но, честно говоря, Facebook — это особый случай.
Нельзя говорить о масштабируемости, не говоря об инфраструктуре. Если вы размещаете блог WordPress на простом виртуальном хостинге и внезапно переживаете десятки тысяч посещений… ну, это может быть проблемой, и ваш хостинг отправит вам неприятное электронное письмо или, по крайней мере, выставит вам больший счет, чем вы ожидали.
Масштабирование приложения включает в себя гораздо больше, чем просто выбор языка. В этом деле очень много деталей, и меня расстраивает то, что все шишки достаются PHP. Более новые версии PHP, в правильной среде и правильно настроенные, более чем способны обрабатывать большое количество запросов. Laravel Vapor, первая бессерверная платформа для приложений Laravel, работающих на AWS, показывает действительно впечатляющие цифры.
Иногда я думаю, что вопрос масштабируемости также несколько преувеличен. За 20 лет написания вещей на PHP я никогда не сталкивался с “миллионами запросов” в секунду. Даже близко. Большинство из нас не будут создавать новый Facebook, как бы мы не мечтали. На самом деле мы создаем гораздо более узкоспециализированные приложения. Мы работаем с конкретными отраслями, часто в определенных странах, и нам не приходится беспокоиться об обработке более нескольких сотен запросов в секунду. Для многих проектов, в которых мы участвуем, это большие цифры. Это не значит, что то, что мы делаем, не важно, это просто означает, что нам не нужно беспокоиться о таком масштабе. Масштабирование приложений для обработки миллионов запросов просто не является частью нашей рутины.
PHP уродлив
Вы, должно быть, шутите. Самую бесячую претензию я оставил напоследок. Если вы выбираете свой стек технологий, основываясь на том, как красиво что-либо выглядит, то вы серьезно заблуждаетесь, и вам нужно серьезно задуматься над своим выбором.
Но даже несмотря на это, я не думаю, что это правда. Вероятно, это происходит из-за давней практики использования PHP непосредственно в HTML (где он действительно выглядел не очень). Но дело в том, что мы больше этого не делаем, так как это не приветствуется.
Я не говорю, что так называемые “красивые языки” — неправильный выбор, но это определенно не должно быть определяющим фактором. Java совершенно некрасив, но при этом является одним из самых популярных языков в мире. Просто глупо возражать против использования PHP из-за того, что он некрасив.
PHP, вероятно, не самый красивый язык, но я нахожу его вполне читабельным, когда он хорошо написан. И в PHP 8 есть несколько действительно замечательных инструментов, которые помогут сделать ваш код еще более “красивым”.
Я люблю PHP
Я действительно его люблю. Я люблю язык и экосистему. Мне нравится, какие улучшения произошли в нем за последние несколько лет. PHP 8 — это не просто еще одна версия того же языка. С каждым крупным релизом мы получаем более качественные и полезные инструменты.
Мне нравится, что с PHP легко начать работу, как и то, что он сложен и на самом деле нужно так много знать, чтобы считаться профессиональным PHP-программистом. Я люблю Symfony и Laravel и думаю, что люди, стоящие за ними, также ответственны за продвижение языка, как и основная команда PHP.
Но больше всего мне нравится быть программистом. Не только на PHP, но я люблю создавать вещи на любом языке, который мне приходится использовать. Мне нравится тот факт, что я могу указывать компьютерам, что делать, и что я сам этому научился. Я обязан этим PHP. Без PHP я не знаю, что бы я сейчас делал. Может быть, я был бы каким-то посредственным дизайнером, ненавидящим свою работу и свою жизнь (не в обиду дизайнерам, читающим это. У меня есть действительно талантливые друзья-дизайнеры, которым тоже нравится то, что они делают). Но вместо этого я делаю то, что люблю, используя язык, который мне нравится.
Перевод материал подготовлен в преддверии старта специализации "PHP Developer".
Комментарии (109)
usego
19.04.2022 19:03+10Главный критерий - количество вакансий. А не всё это..
AmdY
19.04.2022 21:20+2Плевать на количество, главное качество - оклад, решаемые проблемы и требуемый стек. В php с этим всё хорошо. Хотя были волны хайпа с ROR, Nodejs, Go, которые перетягивали на себя некоторое количество проектов и специалистов. Но в итоге технологии начали жить не вместо, а вместе и всем места хватает, дополняя друг друга.
usego
19.04.2022 21:56+7С таким критерием и Cobol живёт и здраствует.
AmdY
20.04.2022 12:52Не по всем критериям, стек всё же устаревший. Но и он как бы жив, особенно после пандемии ;). У меня знакомый на таком же древнем языке RPG пишет для японского автопрома за 200 тыс $ в год за минусом налогов и имеет пачку других предложений о работе без срока давности.
sergey_privacy
19.04.2022 23:09+15Дружище, главная попоболь программистов - это количество вакансий вот прямо сейчас. Каждые 5 лет всплывает очередной "убийца всех языков", куча придурков кидаются учить его, растет количество вакансий от таких же молодых начальников, которым дали власть, но не вырастили еще мозги. А когда появятся мозги, начнут задумываться о том, что с этим потом делать, когда убегут парочка "локомотивов". Окажется, что пара недооцененных низкооплачиваемых гениев прокачали скилл на проекте и свалили туда, где больше платят. А новоприбывшие не тянут, т.к. профи в новых языках тупо еще не выросли. Нет огромного комьюнити, нет хороших доков. И оказывается, что на данном конкретном модном языке проект очень резко дорожает. Он становится нерентабельным, пытаются частично или полностью перейти на другие языки. Короче говоря, очень многие языки - это вспышка на небе. чтобы потом исчезнуть в недрах маленьких фанатичных комьюнити. И программист качал, качал стэк, а он вдруг стал нафиг никому не нужным. Опять лезем в вакансии. А вот языки, на которых написано много популярного софта - это стабильный заработок на десятки лет. Кроме вордпресса на этом языке было написано много разных форумов и CMS. Один PhpBB чего стоит или ModX - вообще бомба, лучший из всех движков, которые я пробовал.
И тут внезапно вспоминаем про... Битрикс24. Это - целая экосистема, которая поселившись в корпоративной среде просто как CRM, очень быстро заменяет локальные жаббер-сервера, внутреннюю почту, outlook-календари, общие диски, конфлюенс в качестве БЗ, жиру, форум, интранет-портал на богомерзком шарепоинте (СЛАВА БОГУ!!!). И если внимательно присмотреться к статистике, количество продаж растет и растет. Интеграторы уже в Африканские страны и Европу, Южную Америку продают свои установки и доработки на его базе. Ценник часа высокий, все ОК.
А если сделать невозможное и программистам высунуться из своей скорлупки, то окажется, что сейчас на хайпе отрасль ИБ. Всякие SIEM, IDS, IPS и еще десятки ВИДОВ продуктов породили сотни НАИМЕНОВАНИЙ продуктов. Им всем нужны коннекторы к оборудованию, софту. Какие там языки? Python, C#, PHP. Следовательно, любители Ruby, Go и еще всякой ереси сверкнули яркой звездочкой и остались на уровне статистического шума. А эти 3 кита еще будут теснить такую мелочь еще минимум десятилетие.
usego
20.04.2022 08:29+1Всё так, но по наблюдениям, на много дороже именно легаси, так как людей всё меньше (никто не хочет ни копаться в старом мусоре, ни изучать не требующийся уже язык). И да, можно на нём до пенсии потом сидеть на большой зарплате (Cobol тот же примером), но это не делает язык/платформу живой. То, что вы описали выше, суровая реальность айти как такового, независимо от языка. Всё лишь вопрос времени / поколений.
cy-ernado
20.04.2022 15:55+1остались на уровне статистического шума.
Go стабильно развивается. Если Kubernetes и проекты из CNCF (Docker, Grafana, Prometheus и т.д.) на уровне статистического шума, то я даже не знаю, что тут можно сказать.
Язык надежно закрепился в сфере инфраструктурного софта и продолжает набирать популярность, всем бы быть такой "мелочью".
Демонстрация статистического шума Я понимаю, что опенсорс это не вся индустрия, но графики довольно показательны.
nmrulin
20.04.2022 16:30Смотря где смотреть. В Tiobe вот Go сейчас ровно на строчку ниже , чем Delphi, который вроде как уже похоронили окончательно.
sergey_privacy
20.04.2022 23:24+1В проектах по всему миру Go составляет менее 3% от общего числа проектов. И от общего числа приложений. И от общего числа CMS... Продолжать? Бул резкий скачок, потом резкое падение и мееееедленный подъем. Этому языку до 20% ползти не менее 20 лет такими темпами.
janson
19.04.2022 19:12+9Две двери, два стражника. Одна дверь ведёт к свободе, вторая к смерти. Один стражник врёт, второй говорит только правду. Как узнать за какой дверью выход на свободу?
Нужно спросить: "PHP мёртв?".
sergey_privacy
19.04.2022 23:14+4Фанатик? Какая свобода? Какое рабство? Это - язык программирования. Очень удобный и эффективный. Отказываясь от него ты ничего радикально не приобретаешь и не теряешь, просто сменил стэк. Ты даже обосновать не можешь, за что ты так его ненавидишь. Просто модно его хаять и ты поддался стадному инстинкту.
janson
20.04.2022 00:29+1Why so serious? ©
Это ж классическая задача, к примеру вот про две двери и двух охранников
Ну ладно, видимо шутка недостаточно удачная. В голове у меня она намного смешнее. Потому что на холиварный вопрос "php мёртв?" однозначного ответа не будет )
trokhymchuk
19.04.2022 19:36+2Я сомневаюсь, что люди, которые пишут на C++ для Microsoft, любители, и я почти уверен, что они знают, что делают
Отнюдь не берусь судить уровень разработчиков винды, но, чтоб вы понимали, из-за монолитности и размера репозитория windows майкрасофт создали отдельный продукт VFS for Git --- виртуальную файловую систему для гит.
Я, конечно, не поддерживаю тезис, что РНР умирает, но опасения в замедлении разработки есть, при чём, они куда более прагматичны. Не так давно РНР лишился, я бы сказал, главного разработчика --- Никиту Попова. Он ушёл из JetBrains 1 декабря, это буквально можно заметить на графике коммитов в php:
cheevauva
19.04.2022 22:06-1а это действительно минус? в последние пару лет, там такой трэш иногда делали, что кажется это к лучшему что язык чуть замедлит развитие. возможно это даст народу обжиться, найти точки для развития, которые действительно важны.
alexey-m-ukolov
20.04.2022 06:13+6Какой, например, трэш?
FanatPHP
20.04.2022 11:17+4Я так понимаю, это партия любителей примитива, манифест которой озвучил мужчина в комментарии ниже, "не надо заморачиваться".
Я некоторое время назад обнаружил, что не все рады вектору развития языка в сторону строгой типизации, которая не позволяет им говнякать по-старинке, как раньше.
trokhymchuk
20.04.2022 11:01+6Не было никакого трэша, тем более, конкретно этот разработчик --- исключительно светлая часть РНР. И нет, замедление развития ещё никому не помогало.
ligor
19.04.2022 19:46+3По мне так вполне нормальный язык, особенно для шаред хостинга где node или еще что не особо установишь.
urvalla
19.04.2022 19:59+12Вот когда будут на заборе писать "PHP жив" - это будет симптом. Ну, как с Лениным и Цоем.
А если серьёзно - я за то чтобы уметь писать на разных языках. Пишете на PHP? Попробуйте Go или Rust для ускорения узких мест. Попробуйте JS/TS с vue/react/angular на фронте, попробуйте ноду и serverless. Попробуйте Java или Kotlin. Ruby, Python. Даже если будете продолжать писать на PHP - будете писать по-другому с другим кругозором. И будет гораздо более фиолетово что о каком языке говорят, если всегда готовы переключиться.
bozman
19.04.2022 20:37+6Кто на Parser писал, тот над PHP не стебется...
dizatorr
20.04.2022 12:40+1Было дело, повёлся на Лебедева. И правда, не смеюсь. Хотя сейчас ушёл из фулстека в администрирование, тулзы для себя бывает пишу на РНР, хотя в принципе и другие языки знаю. На нём получается проще и быстрее.
zesetup
19.04.2022 20:38+8могу сказать несколько минусов PHP, которые мне показались важными:
хаотичный набор встроенных функций. это случилось поначалу, так как никто вначале не проектировал этот язык и не группировал функции
сложное развертывание приложений. нужно управление модулями с правами админа сервера. в Entrprise среде установка драйверов Oracle или MS Sql уже становится небольшим приключением. например в Java драйвера добавляются на уровне приложения.
-
сессионная природа, скажем так, сервера PHP. время жизни приложения - время отработки запроса к серверу. сделать какие-то вещи асинхронно или в фоне нельзя. фоновые задачи приходится запускать из ОС по планировщику.
огромный плюс это, конечно, легкость начать что-то создавать.
DeadMaster
19.04.2022 21:41+13Сессионная природа - как-раз одна из "фишек" языка.
PHP создан чтобы умирать.
randomsimplenumber
19.04.2022 22:13+5PHP создан чтобы умирать
Ничто не мешает написать на php вечно живого демона с worker'ами.
usego
19.04.2022 22:02+6Ну, справедливости ради, с приходом контейнеризации, сложности с деплойментом остались только у динозавров.
tzlom
19.04.2022 22:12+5А где набор функций не хаотичный? В JS или питоне? В джаве тоже все не то чтобы просто организованно. В конечном счете удобство - это синдром утенка, типа в JS это сделано не удобно и у меня слезы из глаз вместо написания кода, но в конце все работает (это я про себя если что).
Я бы не сказал что развертывание джава приложений легче- если есть нормальный докер контейнер то оно везде легко, если нет - везде попаболь.
zesetup
19.04.2022 22:30-1вот именно если кто-то сделал docker-образ который вам подходит. а если нет, то делать его трудоемко, вообщем шаг влево-вправо боль. а ведь потом его и апгредить нужно, тоже боль.
в Java все решается, например, Alpine linux контейнером, в который кладется единственная зависимость Java-приложения - JVM. все другие зависимости на уровне приложения - пакетами/библиотеками.
не только PHP страдает сложным развертыванием, та же песня с Python/Django, Ruby/Rails.
tzlom
19.04.2022 22:43+5"Единственная зависимость приложения"
Ну как бы нет, во первых некоторые джава пакеты хотят конкретных бинарь в системе, конечно не все, но мы же про общий случай, да? (тот же PHP практически не имеет бинарных модулей, не знаю хорошо ли это но это так)
Потом JVM - который будем ставить? Oracle у которого не всё гладко с лицензиями, или OpenJDK который не всеми поддерживается?
Дальше будет веселье с "вы не правильно выбрали параметры GC" и ещё хрен знает какие переменные среды. А ещё у любого уважающего себя Java приложения внутри миллион Enterprise фреймворков из за чего оно имеет кучу не документированных опций конфигурации которые не всегда такие какие надо (привет log4j).
Тот же PHP требует пары пакетов после чего php-fpm работает и его особо трогать не надо.
Для меня проблемы непосредственно установки это не проблемы вообще, а конфигурации приложений уже зависят от приложения и там сумасшедшие вещи могут быть в любом языке.
usego
20.04.2022 08:35+2Если способны поставить на голую машину своё барахло, то и упаковать его в контейнер - не rocket science. Там всё проще, чем кажется.
Bonio
20.04.2022 10:04сложное развертывание приложений.
Неактуально для контейнеризованных приложений.
сделать какие-то вещи асинхронно или в фоне нельзя. фоновые задачи приходится запускать из ОС по планировщику.
Можно через очереди и воркеры.
avengerweb
21.04.2022 01:49+2Работаю в enterprise среде, потратили пару месяцев чтобы уйти с win и iis в Linux и докер и это все на 20 летней legacy code base. Зажили как люди. Благо ребята всегда поддерживали LTS php, так что 20 летняя кодовая база работает сейчас на 7.4, готовим 8.1.
Фоновые задачи тоже тема, мы например в legacy code base завернули laravel, он пока не ведёт полный цикл запроса (к сожалению) но теперь из любой точки в легаси можно закинуть долгую задачу в job queue (laravel), сессии их тоже легли на легаси не плохо (в редисе), в итоге 20 летнее легаси теперь горизонтально маштабируется, я такого от php не ожидал. Я пишу на java/js/go/python и ни один язык я не готов назвать убийцей php
65536
21.04.2022 11:39сделать какие-то вещи асинхронно или в фоне нельзя
если у вашей системы есть консольный интерфейс, то можно
exec('nohup path/to/cli command &');randomsimplenumber
21.04.2022 11:47Если в вашей системе есть bash. И не забудьте подпереть какой то синхронизацией, а то если первая команда ещё работает, а вы уже запустили вторую, результат может не понравиться.
65536
21.04.2022 12:32Я самый примитивный случай описал, в ответ на слово "нельзя". Из коробки может и нельзя, а вообще можно.
А в каком линуксе баша нет, или в чем проблема его поставить. Или что такого может произойти, что проект должен будет переехать на винду?
randomsimplenumber
21.04.2022 14:09Или что такого может произойти, что проект должен будет переехать на винду?
Проект уже живёт под windows, например ;)
65536
22.04.2022 14:37Прискорбно. Отсутствие баша это не единственное страдание там. Но думаю и под виндой не "нельзя".
worldmind
19.04.2022 21:28+2Всё не о том, надо ответить на вопрос какие преимущества у php? Ниша скриптовых языков не такая большая чтобы уместить всех, питон растёт, остальные стагнируют или падают.
tzlom
19.04.2022 22:17+6PHP быстрее питона, течет меньше (и дохнет чаще) и в нем удобный чудо вектор/хеш/хрен-пойми-что но удобное.
Ниш у скриптовых языков много, ту же математику на PHP писать не буду, а вот сайтик как то сподручнее на нем. Питон на коне пока не появился другой мейнстримовый язык в который C/C++ легко встраивать, та же Julia если поправит время первичного запуска может из под питона табуретку вынуть.
worldmind
19.04.2022 22:28+2Про течку не слышал, а производительность в этой нише не главное.
VEG
19.04.2022 22:33+2Производительность тоже важна. Я как-то свои сайты перевёл с PHP 5.4 на PHP 7.4, где как раз заметно подняли производительность. Результат был заметен как на глаз (страницы изначально загружались с небольшой задержкой, а стали загружаться мгновенно), так и по нагрузке на сервер.
Сайты у меня маленькие, поэтому снижение нагрузки никак не сказалось на моих расходах, всё в пределах тарифа было изначально (но видимый невооружённым глазом прирост производительности порадовал). А вот если сайт очень популярен, то это позволило бы заметно экономить деньги.
Судя по тестам, PHP 7 гораздо быстрее Python 3. При этом, сложность разработки на Python и PHP примерно одинаковая, то есть не получится сказать, что разработка «более быстрого» сайта на PHP будет дороже, что нивелировало бы экономию на серверах.worldmind
19.04.2022 23:03+2Да, но в этой нише это не киллер-фича, когда сайт уже на пхп бесплатный прирост это круто, но для новых проектов критерии другие судя по графикам популярности.
VEG
19.04.2022 23:13+3Ну PHP стал слишком немодным. Наверное, из-за того, что слишком много людей «входило в IT» именно через этот язык, и они писали не самый лучший код. Появилась даже соответствующая стигма, мол PHP-шник — это уже приговор. Сейчас, кстати, я заметил, что изначально очень далёкие от IT люди пытаются попасть в IT уже через Python. До стигмы осталось 3, 2…
Плюс появился Node.JS (который тоже быстрый), много кому удобнее на одном языке писать как frontend, так и backend. Python во многом набрал популярности за счёт новых областей типа Data Science, где для этого первее всего появились удобные библиотечки. Ну и одобрение Google наверное сказалось. Первые лет 15 Python ведь не особо пользовался спросом (Python старше PHP), а потом вдруг пошёл вверх.
cheevauva
19.04.2022 22:23+2для меня основное преимущество пхп в том что он не догматизирован разработчиками, как питон или джава. пхп позволяет мне, например, экспериментировать с ООП, заниматься исследованием ООП, в весьма обширных рамках. джава уже окуклился со своими фреймворками и паттернами. это не плохо, но это ограничивает простор для экспериментов. питон в вебе представлен в основном джанго, что тоже создает ситуацию как с джавой. короче джава и питон задали у себя промышленный стандарты, и попытка писать лучше чем они требуют или исследовать возможности писать по другому, называют обычно - ересью(говной).
worldmind
19.04.2022 22:29+2Питон мультипарадигменный, в чём он догматизирован?
cheevauva
20.04.2022 00:53+2и джава, и питон мультипарадигменные я не спорю. Догматизация именно в использовании инструментария для решения конкретного рода задач. То есть по сути что в питоне/джаве фреймворки являются чуть ли не еще одним языком для решение конкретных отраслевых задач. При этом решение этих задач другими инструментами, будет воспринято негативно или не найдет понимание, так как нарушен отраслевой стандарт, то есть - догма. Отраслевой стандарт хорошо для поддержки продуктов, но именно для исследований и экспериментов плохо. Когда в пхп какой-то из фреймворков станет отраслевым стандартом, то тогда я смогу точно сказать, что он стал таким же как и джава, и питон. Сейчас в пхп лидирует ларавел, но все отнесутся с пониманием, если будет использован симфони или ламинас, на худой конец юии. В питоне, как я понимаю если ты не выбрал джангу для веба, то к тебя автоматом появляются вопросики.
Я не спорю, что и на питоне, и на джава можно заниматься тем же, что и в пхп занимаюсь я, но это будет крайне не эффективно так как на реальных проектах это невозможно будет попробовать, в силу описанных выше причин.
dimastbk
20.04.2022 09:28+2Python движется к микросервисам и асинхронности, а Django это не про асинхронные микросервисы; для синхронных МС и небольших монолитов есть Flask, для асинхронных МС есть FastAPI или Aiohttp. Django возможно стандарт для крупных монолитов, но не стандарт для веб-приложений вообще.
В опросе SO за 2021 год есть три фреймфорка на Python.
VEG
19.04.2022 22:38Ниша скриптовых языков не такая большая чтобы уместить всех, питон растёт, остальные стагнируют или падают.
Вряд ли Python сможет заменить JavaScript, который уже много лет держит первое место по популярности. Всё же веб слишком важен, и JavaScript (в паре с TypeScript) достаточно хорош, чтобы не было необходимости в браузеры добавлять поддержку других скриптовых языков.
vvbob
19.04.2022 22:03+3Вот мне сейчас пыхари минусов-то накидают..
PHP сейчас жив примерно так-же как и Cobol (ну, ладно, немного утрирую). Его держит на плаву огромный пласт созданного в прошлом ПО, которое проще поддерживать чем переписать заново. Думаю в таком состоянии он еще долго будет жить.
cheevauva
20.04.2022 01:04+4пхп пережил 3 оттока разработчиков, первая волна - питон(джанго), вторая волна - нода, третья - го. И ничего жив и здоров. Переживет ли нода или го такие же волны оттока разработчиков как пхп - большой вопрос.
Exclipt
19.04.2022 23:54+9Я за последние 20 лет так и не понял, php быстрее умрет, или у доллара крах настанет.
sergey_privacy
20.04.2022 00:07-4Я писал на многих языках, начинал с basic, pascal, asm86-486, потом turbovision, c, c++, c#, богомерзкие js и java, perl, delphi, python, еще куча макро- и batch-языков типа mawk, whs, bash и т.д. Остановился на PHP.
Любому, кто назовет его некрасивым или неудобным я просто плюну в морду. Почему? Объясню:
Во многих дурацких языках программирования обычно обязательно надо указывать их тип. И не дай бог смешать в одной операции разные типы переменных
float pi=3,14; string zzz="zzz"; double xxx=28; aaa=pi+zzz+xxx; или просто aaa=pi+xxx; вызовут ошибку в неудобных языках. А что будет в PHP? aaa=pi+zzz+xxx; aaa=3,14zzz28 или aaa=pi+zzz+xxx; aaa=31,14;Это чертовски удобно и эффективно. Мне не надо заморачиваться с какими то объявлениями переменных, не надо тратить время на ловлю ошибок, если вдруг смешались в кучу целые, символы, числа с запятой, текст. Сложил 2 числа - получилось обычное сложение. Попался текст - автоматом конкатенация.
Чтобы сгенерировать html-страницу на каком то дурацком языке программирования, мне нужно ее сначала сверстать, а потом в начале каждой строки добавлять команду print, echo или printf чтобы получить вывод типа
print("<html>"); print("<body>"); print("<p>Приветутствую тебя ", $name, " на нашем сайте"); print("</body>"); print("</html>"); А что будет в PHP? <html> <body> <h1>Приветствую тебя <? echo $name; ?> на нашем сайте <p>blablabla <div>blablabla</div> <p> Всего посетителей страницы: <? echo $counter; ?> </body> </html>Я код вставляю в любое место страницы. Моему PHP приходится обрабатывать только 2 команды, остальное пропускает парсер. А практически любому другому языку приходится обрабатывать МИНИМУМ столько команд, сколько строк текста на странице.
А еще меня бесят языки со строгими правилами размещения кода. Лишний пробел или не хватило пробела - программа валится. Я пишу на языке код! Зарабатывание денег упирается в скорость релиза. Скорость релиза зависит от скорости и эффективности разработки. А я вместо отлова ошибок самого кода должен еще тратить время на ошибку из-за пробела? Пробел - это не значащий символ кода и в PHP я волен писать код так, как мне удобно и надо.
PHP очень сильно облегчает разработку программ, уменьшая непродуктивные накладные расходы процентов на 10 минимум.
Если кто то начинает заикаться про сравнение скорости скриптовых языков и отсутствие масштабируемости, я плюну ему в лицо второй раз. Вы пробовали php в режиме php-fpm? Он очень быстрый! А еще он может работать как через сокеты, так и через сетевые порты. Что это значит? А это значит, что у тебя есть пул хостов с php, на который прилетают запросы от web-сервера на апаче и или nginx-е через пул балансировщиков нагрузки. Consul-ом отслеживаем живые инстансы и не шлем на те, которые улеглись. Масштабируй хоть до миллиона инстансов. У php есть минусы, но плюсов гораздо больше и писать на нем на порядок комфортнее, чем на любом из тех языков, которые я знаю.
randomsimplenumber
20.04.2022 06:27+2Сложил 2 числа - получилось обычное сложение. Попался текст - автоматом конкатенация.
Девочка_и_javascript.jpg ;) В php тоже так? Строку на int умножать можно? А наоборот?
0xd34df00d
20.04.2022 20:25+1Во многих дурацких языках программирования обычно обязательно надо указывать их тип.
Да, тоже не люблю такое. Предпочитаю языки, где нужно указывать только топ-левел-типы (например, хаскель, очень близок по концепции типов к php).
Чтобы сгенерировать html-страницу на каком то дурацком языке программирования, мне нужно ее сначала сверстать, а потом в начале каждой строки добавлять команду print, echo или printf чтобы получить вывод типа
Можно взять, например, снова такой пхп-подобный язык, как хаскель. Тогда html генерируется либо квазиквотерами:
[html| <html> <body> <h1>Приветствую тебя #{name} на нашем сайте <p>blablabla <div>blablabla</div> <p> Всего посетителей страницы: #{counter} </body> </html> |](смотрите, вместо
<? echo $name; ?>можно писать просто#{name}!)
либо монадическими комбинаторами.При этом квазиквотеры и комбинаторы — это не что-то, встроенное в сам язык. Они сделаны отдельными библиотеками, и никто не мешает сделать вам свою, максимально удобную для вас лично, под отдельный проект (и таскать её потом в другие проекты).
Скорость релиза зависит от скорости и эффективности разработки. А я вместо отлова ошибок самого кода должен еще тратить время на ошибку из-за пробела? Пробел — это не значащий символ кода и в PHP я волен писать код так, как мне удобно и надо.
Страшно представить, какой стиль у кода в итоге.
FanatPHP
20.04.2022 20:35+1В РНР нельзя писать
<? echo $name; ?>. Но можно (и нужно) писать<?= $name ?>.Ну и в профессиональной разработке практически всегда пишется
{{ name }}sergey_privacy
20.04.2022 23:11-5Юноша, читайте официальные доки, там много мудрости: https://www.php.net/manual/en/language.basic-syntax.phptags.php
Цитирую:Example #1 PHP Opening and Closing Tags
1. <?php echo 'if you want to serve PHP code in XHTML or XML documents,
use these tags'; ?>
2. You can use the short echo tag to <?= 'print this string' ?>.
It's equivalent to <?php echo 'print this string' ?>.3. <? echo 'this code is within short tags, but will only work '. 'if short_open_tag is enabled'; ?>Прежде чем писать всякую фигню, актуализируйте ваши знания. Никто не запрещает использовать любой из 3-х тегов.
> Ну и в профессиональной разработке практически всегда пишется
{{ name }}
Юноша, читайте официальные доки, там много мудрости: https://www.php.net/manual/ru/language.variables.basics.phpЦитирую:
Переменные в PHP представлены знаком доллара с последующим именем переменной. Имя переменной чувствительно к регистру.---- поскипано ---
<?php
$var = 'Боб';
$Var = 'Джо';
echo "$var, $Var"; // выведет "Боб, Джо"
?>Я на PHP пишу с 2000-го года. А автор в школу уже ходил в этом году? Или еще в садик?
FanatPHP
20.04.2022 23:34+1Спасибо, поржал :) "Да я в 1918 году дивизией командовал!", и при этом никогда не видел нотации
{{ name }}— это говорит о многом. Меньше, чем предыдущий манифест про "плюну в морду", но тоже доставляет. Как говорится, аффтар, пешы ещо.
mafia8
21.04.2022 10:47Где это есть в справке PHP?
FanatPHP
21.04.2022 10:50Вы с какой целью интересуетесь?
mafia8
21.04.2022 11:08Чтобы узнать. А то не знал. До сих пор.
FanatPHP
21.04.2022 11:14Чтобы узнать, можно посмотреть https://twig.symfony.com/ и https://laravel.com/docs/9.x/blade
xmcuz
21.04.2022 21:24Рекомендую глянуть https://mustache.github.io
Очень лёгкий и универсальный шаблонизатор. Есть реализации для огромной кучи языков, в том числе php и js.
FanatPHP
22.04.2022 08:35+2Спасибо, поржал :)
Я раньше слышал это слово, но не приглядывался. А сейчас решил посмотреть, и страшно удивился. "logic-less" шаблонизаторы были бешено популярны где-то в середине нулевых, но затем быстро сошли на нет — и совершенно закономерно. Потому что когда ты начинаешь отрицать логику в угоду идеологии — в результате получается ад.
Эмпирическое правило: как только видишь шаблонизатор, который его авторы называют logic-less, это означает, что у авторов очень плохо с
головойлогикой.Потому что шаблонов без логики не бывает. Логика отображения — это совершенно законная часть приложения. Сделать шаблон без логики невозможно. Если у тебя в коде есть цикл или условный переход — то это уже логика. И отрицать это глупо. Нелогично.
И дальше у тебя есть только два пути: либо признать очевидное, и сделать нормальный шаблон с логикой — как Twig, например — либо продолжать биться головой об стену, называть чёрное белым и рожать дикие извращения.
Например разделять шаблон на два: собственно шаблон "без логики" и отдельный контроллер этого шаблона, который всю эту логику и реализует. В итоге вместо удобства и "отсутствия логики" мы получили гораздо более замороченный код, который неудобно писать и неудобно поддерживать, бегая между двумя файлами. В одном из которых "нет логики", но мы сами должны держать её в уме, потому что должны помнить, что вот этот блок — это цикл, а вот этот — условный переход. А во втором — отдельном пхп файле, который мы пишем исключительно ради поддержки нашего шаблона, эта логика куда более замороченная, чем если бы была в "шаблоне с логикой". Вам уже не смешно?
В итоге, намучившись с такой беготнёй, мы начинаем-таки добавлять логику в шаблон. Но поскольку идеология не позволяет нам назвать кошку кошкой, мы пускаемся во всякие извращения.
Как организовать условный цикл в Твиге?
{% if users|length %} <ul> {% for user in users %} <li>{{ user }}</li> {% endfor %} </ul> {% endif %}и здесь у нас всё наглядно — что за операторы мы используем, что выводим.
Как организовать условный цикл в Усах?
{{#users.length}} <ul> {{#users}} <li>{{.}}</li> {{/users}} </ul> {{/users.length}}Эээ… извините, а чем оператор цикла отличается от оператора условного перехода? А ничем! Вот как хочешь — так и понимай. Поведение блока кода зависит от типа переменной. И читая шаблон, ты никак не узнаешь, что означает блок
{{#users}}— цикл или условный переход.В итоге логика в шаблоне есть, но мы это упорно отрицаем. И получаем нечитабельную, нелогичную галиматью. Никогда не следует приносить логику в угоду идеологии.
0xd34df00d
21.04.2022 04:03Спасибо, я-то просто у исходного комментатора скопировал. Если вдруг придётся писать код на php, воспользуюсь (но это вряд ли).
FanatPHP
21.04.2022 07:28Над предыдущим комментатором тут все угорают, не стоит принимать его всерьёз :)
Ну и я больше к тому что РНР тоже не стоит на месте, и "вместо<?php echo $name; ?>можно писать просто{{name}}" — это квазиквотер, сделанный отдельной библиотекой.
sergey_privacy
20.04.2022 23:18> Страшно представить, какой стиль у кода в итоге.
function emailClients($clients) { $activeClients = activeClients($clients); array_walk($activeClients, 'email'); } ИЛИ ТАК: class MenuConfig { public $title; public $body; public $buttonText; public $cancelLabel = false; } $config = new MenuConfig(); $config->title = 'Foo'; $config->body = 'Bar'; $config->buttonText = 'Baz'; $config->cancelLabel = true; ИЛИ ТАК: function createMenu(MenuConfig $config) { // ... }Я могу писать так, как мне удобно, а не парсеру. В этом вся суть. Где то я вынес фигурную скобку на 2 пробела/таб - уже краш. Перенес фигурную скобку на другую строку - краш. В PHP такого нет. Я пишу код с таким оформлением, как удобно мне или тимлиду, а не парсеру в дурацких языках.
randomsimplenumber
21.04.2022 08:47как удобно мне или тимлиду
Так удобно вам, тимлиду или всей команде? Или всё это один человек?
Exclipt
21.04.2022 21:45Если вы за 22 года опыта продолжаете какие-то языки называть "дурацкими", то у меня для вас плохие новости... (пишу на php с 1998го)
NTDLL
20.04.2022 00:46+4Я живу в хорошем доме, езжу на отличной машине, потому что потратил 20 лет на то, чтобы стать по настоящему успешным в этом деле.
А заметил, здесь никто на эту ерунду не ведётся, как это было бы на дзене.
Кстати, поскольку я не могу написать лишний комменарий.
Огромным удовольствием для меня было узнать, что php скрипт можно запустить в bash. Написал бэкапер в связке с sh скриптом. Правда, здесь нет таких светоакустических эффектов, как в веб...
gmtd
20.04.2022 07:06+2Вот, кстати, да. PHP - отличное дополнение для скриптов шелла на сервере. На нем намного проще и понятней писать утилиты для запуске в Cron, например, или автоматизации каких-то процессов.
asvechkar
20.04.2022 02:29+3Опять какая то левая статья. Зачем вообще публиковать очередной PHP is die? Чисто набить себе очков на хабре?
Пока жив веб, будет жить PHP: Personal Home Page. На данный момент это самый лучший скриптовый язык для веб сайтов. И не важно, пишите как ФП или ООП. Laravel или Symfony. В итоге веб сайт.
Конечно, сейчас существуют такие сайты как Front-end (React, Vue, Angular, ...) и Back-end (Go, Python, Ruby, C#). Но в основной массе - это PHP.
В каком то смысле PHP - мертв. Он, как и любой скриптовый язык, умирает каждый раз, когда скрипт завершает свою работу. Скрипт завершил работу, умер, завершил, умер, и т.д.
Но как ЯП его не похоронить. Как и Python и Ruby.
gmtd
20.04.2022 07:00+1Фронт на Vue/React etc и бэк на PHP прекрасно сосуществуют. Писать API на PHP - сплошное удовольствие. И отлаживать.
У PHP есть крупный минус - отсутствие многопоточности. Для нее нужно использовать другие языки. Но он и не для нее создавался.
На Хабре были бенчмарки по производительности - Java, Node.js, PHP и что-то еще - все примерно одинаково на удивление. Не "в несколько раз", по крайней мере. Имеются в виду именно вычисления или работа с БД
Ну и напрягает неупорядоченность в определениях функций. Типа, когда у property_exists() и key_exists() аргументы идут в разном порядке
В остальном PHP - прекрасный инструмент в руках программиста
randomsimplenumber
20.04.2022 07:15-2У PHP есть крупный минус - отсутствие многопоточности.
А это что?
gmtd
20.04.2022 07:29+1Он использует модуль pthreads, который "This extension is considered unmaintained and dead"
Это не часть языка
SerafimArts
22.04.2022 14:04У PHP есть крупный минус — отсутствие многопоточности. Для нее нужно использовать другие языки. Но он и не для нее создавался.
Ну как сказать… Просто умение с ней работать доступно не только лишь всем)
Заголовок спойлера<?php $sdl2 = FFI::cdef(<<<'C' typedef struct SDL_Thread SDL_Thread; typedef int (*SDL_ThreadFunction)(void *data); extern SDL_Thread *SDL_CreateThread( SDL_ThreadFunction fn, const char *name, void *data, void* pfnBeginThread, void* pfnEndThread ); extern void SDL_WaitThread(SDL_Thread *thread, int *status); C, 'libSDL2-2.0.so.0'); $before = \microtime(true); $thread1 = $sdl2->SDL_CreateThread(function () { sleep(1); return 42; }, 'Thread #1', null, null, null); $thread2 = $sdl2->SDL_CreateThread(function () { sleep(1); return 23; }, 'Thread #2', null, null, null); $sdl2->SDL_WaitThread($thread1, FFI::addr( $status1 = $sdl2->new('int') )); $sdl2->SDL_WaitThread($thread2, FFI::addr( $status2 = $sdl2->new('int') )); echo number_format(microtime(true) - $before, 2) . "s\n" . 'Thread #1: ' . $status1->cdata . "\n" . 'Thread #2: ' . $status2->cdata . "\n" ; // 1.00s Thread #1: 42 Thread #2: 23Если что, то FFI — часть php-common, так что любым apt install php оно ставится и включается так же, как и json.
С другой стороны — зачем она? В пыхе, в стдлиб есть гринтреды, и их хватает, по-моему, выше крыши для распараллеливания работы с IO (т.е. там, где реальные затыки).
FanatPHP
22.04.2022 14:46+1Ну кстати и без ффи, вот один дядька вчера на реддит написал что сделал корутины как в го, на файберах. https://old.reddit.com/r/PHP/comments/u80gyg/true_coroutines_like_go/
Если не врёт, то будет доступно всем. Неблокирующие файловые операции, вот это вот всё.
Я, правда, сам не асинхронный человек, и как-то оценить эту либу не могу.SerafimArts
22.04.2022 15:48Не, ну так файберы и есть чистые грин треды. Там даже полноценный стек есть. Про них я как бы и говорил. Рекомендую всё же потыкать в них. Я в восхищении. Все эти Promise и Future после их появления маршем идут в утиль и кажутся неюзабельными костылями.
Но вопрос же был изначально не про грин треды, а про, цитата, "многопоточность". Отсюда и подобный комментарий, мол, если нету, то никто не мешает их написать (пусть и через SDL обёртку, как это сделал я).
Заголовок спойлераА с SIGSEGV ошибками аффтор этих тредов пусть сам развлекается, если уж решил использовать ;)
Я уж не говорю про то, что надо ещё будет придумать как использовать CMPXCHG операции для синхронизации данных в многопоточной среде (хотя ходят слухи, что ext-sysvsem расширение доступно из коробки под линусками: https://www.php.net/manual/ru/book.sem.php, так что тут всё готовенькое уже).
FanatPHP
20.04.2022 11:13+1Потому что бюджет на продвижение в отусе.
Народная примета — если на Хабр потянулись левые переводы левых статей по пхпе — значит в отусе скоро очередной курс.
В общем, надо дождаться, когда наберут уже достаточно оболтусов, чтобы учить их писать вот этот вот адов говнокод от ведущих экспертов, и эта активность прекратится. До следующего набора.
wolfandman
20.04.2022 08:51+1Оспади. Да как это мертв? Кто это говорит? Люди не понимают шутки: php умирает в момент завершения исполнения скрипта.
ISharovarov
20.04.2022 09:46+1В нише простых и средних по нагрузке, контенту и посещаемости сайтов и API у PHP действительно нет конкурентов. К тому же перейти с него на другой язык, типо java гораздо легче, чем, например с питона.
Если вы выбираете "с какого языка начать изучать програмирование", то вопрос поставлен не корректно. В первую очередь нужно выбирать сферу, простоту изучения, количество вакансий, обширность документации, количество примеров и гайдов.
Обычно на бэке +- 3 варианта: Питон, Java и PHP.
Питон, например, имеет смысл выбрать, если вы потом хотите уйти в датасаенс. Java, если хотите в интерпрайз или в целом не уверены, что хотите. PHP, если нравится писать API и хотите как можно быстрее устроиться.
В целом, если честно, разница минимальна, но так выбирать легче, когда нет опыта. Через года 3 по зп и задачам можно выйти на одинаковый уровень, что бы вы не выбрали.
Если решать в категориях "нравится синтаксис" или "модно", то можно никогда не определиться.
Mihail_Tropin
20.04.2022 09:49+2Если я не ошибаюсь, то в Slack и Facebook используют HHVM и, как следствие, Hack
Hett
20.04.2022 23:15Да успокойтесь уже, никто его не хоронит. Хватит писать статьи про то, что пхп не мертв и какой он крутой. Одно и тоже стабильно раз в 2 недели.
FanatPHP
20.04.2022 23:38+2Это разумный комментарий, но, увы, бесполезный. Контент-менеджеры не читают Хабр, они на него пишут. И понятия не имеют о том, про что здесь статьи были, а про что не было. У них план — каждый день по статье. Придется терпеть, пока полный курс не соберут.
SkillZQ
PHP мертв
slonopotamus
Ну зачем вы так. О мёртвых либо хорошо, либо ничего.
UnknownQq
Немного статистики с полей.
Это, конечно, не ++, но не надо в гроб живчика класть.
Или я как обычно не понял сарказма?
Harley347
Да здравствует PHP.
FanatPHP
Ну кстати, кроме шуток, все так и есть. Старый говнокодеоский пых действительно умер, и пользуются им одни вурдалаки, типа экзальтированного мужчины ниже. А новый удобный быстрый современный язык занял его место.