Комментарии 123
PHP мертв
Ну зачем вы так. О мёртвых либо хорошо, либо ничего.
О мёртвых либо хорошо, либо ничего, КРОМЕ ПРАВДЫ(с) Хилон
Немного статистики с полей.
Это, конечно, не ++, но не надо в гроб живчика класть.
Или я как обычно не понял сарказма?
Да здравствует PHP.
Главный критерий - количество вакансий. А не всё это..
Плевать на количество, главное качество - оклад, решаемые проблемы и требуемый стек. В php с этим всё хорошо. Хотя были волны хайпа с ROR, Nodejs, Go, которые перетягивали на себя некоторое количество проектов и специалистов. Но в итоге технологии начали жить не вместо, а вместе и всем места хватает, дополняя друг друга.
Дружище, главная попоболь программистов - это количество вакансий вот прямо сейчас. Каждые 5 лет всплывает очередной "убийца всех языков", куча придурков кидаются учить его, растет количество вакансий от таких же молодых начальников, которым дали власть, но не вырастили еще мозги. А когда появятся мозги, начнут задумываться о том, что с этим потом делать, когда убегут парочка "локомотивов". Окажется, что пара недооцененных низкооплачиваемых гениев прокачали скилл на проекте и свалили туда, где больше платят. А новоприбывшие не тянут, т.к. профи в новых языках тупо еще не выросли. Нет огромного комьюнити, нет хороших доков. И оказывается, что на данном конкретном модном языке проект очень резко дорожает. Он становится нерентабельным, пытаются частично или полностью перейти на другие языки. Короче говоря, очень многие языки - это вспышка на небе. чтобы потом исчезнуть в недрах маленьких фанатичных комьюнити. И программист качал, качал стэк, а он вдруг стал нафиг никому не нужным. Опять лезем в вакансии. А вот языки, на которых написано много популярного софта - это стабильный заработок на десятки лет. Кроме вордпресса на этом языке было написано много разных форумов и CMS. Один PhpBB чего стоит или ModX - вообще бомба, лучший из всех движков, которые я пробовал.
И тут внезапно вспоминаем про... Битрикс24. Это - целая экосистема, которая поселившись в корпоративной среде просто как CRM, очень быстро заменяет локальные жаббер-сервера, внутреннюю почту, outlook-календари, общие диски, конфлюенс в качестве БЗ, жиру, форум, интранет-портал на богомерзком шарепоинте (СЛАВА БОГУ!!!). И если внимательно присмотреться к статистике, количество продаж растет и растет. Интеграторы уже в Африканские страны и Европу, Южную Америку продают свои установки и доработки на его базе. Ценник часа высокий, все ОК.
А если сделать невозможное и программистам высунуться из своей скорлупки, то окажется, что сейчас на хайпе отрасль ИБ. Всякие SIEM, IDS, IPS и еще десятки ВИДОВ продуктов породили сотни НАИМЕНОВАНИЙ продуктов. Им всем нужны коннекторы к оборудованию, софту. Какие там языки? Python, C#, PHP. Следовательно, любители Ruby, Go и еще всякой ереси сверкнули яркой звездочкой и остались на уровне статистического шума. А эти 3 кита еще будут теснить такую мелочь еще минимум десятилетие.
Всё так, но по наблюдениям, на много дороже именно легаси, так как людей всё меньше (никто не хочет ни копаться в старом мусоре, ни изучать не требующийся уже язык). И да, можно на нём до пенсии потом сидеть на большой зарплате (Cobol тот же примером), но это не делает язык/платформу живой. То, что вы описали выше, суровая реальность айти как такового, независимо от языка. Всё лишь вопрос времени / поколений.
остались на уровне статистического шума.
Go стабильно развивается. Если Kubernetes и проекты из CNCF (Docker, Grafana, Prometheus и т.д.) на уровне статистического шума, то я даже не знаю, что тут можно сказать.
Язык надежно закрепился в сфере инфраструктурного софта и продолжает набирать популярность, всем бы быть такой "мелочью".
Я понимаю, что опенсорс это не вся индустрия, но графики довольно показательны.
Смотря где смотреть. В Tiobe вот Go сейчас ровно на строчку ниже , чем Delphi, который вроде как уже похоронили окончательно.
В проектах по всему миру Go составляет менее 3% от общего числа проектов. И от общего числа приложений. И от общего числа CMS... Продолжать? Бул резкий скачок, потом резкое падение и мееееедленный подъем. Этому языку до 20% ползти не менее 20 лет такими темпами.
Две двери, два стражника. Одна дверь ведёт к свободе, вторая к смерти. Один стражник врёт, второй говорит только правду. Как узнать за какой дверью выход на свободу?
Нужно спросить: "PHP мёртв?".
Фанатик? Какая свобода? Какое рабство? Это - язык программирования. Очень удобный и эффективный. Отказываясь от него ты ничего радикально не приобретаешь и не теряешь, просто сменил стэк. Ты даже обосновать не можешь, за что ты так его ненавидишь. Просто модно его хаять и ты поддался стадному инстинкту.
Why so serious? ©
Это ж классическая задача, к примеру вот про две двери и двух охранников
Ну ладно, видимо шутка недостаточно удачная. В голове у меня она намного смешнее. Потому что на холиварный вопрос "php мёртв?" однозначного ответа не будет )
Это чтобы они подрались?
Я сомневаюсь, что люди, которые пишут на C++ для Microsoft, любители, и я почти уверен, что они знают, что делают
Отнюдь не берусь судить уровень разработчиков винды, но, чтоб вы понимали, из-за монолитности и размера репозитория windows майкрасофт создали отдельный продукт VFS for Git --- виртуальную файловую систему для гит.
Я, конечно, не поддерживаю тезис, что РНР умирает, но опасения в замедлении разработки есть, при чём, они куда более прагматичны. Не так давно РНР лишился, я бы сказал, главного разработчика --- Никиту Попова. Он ушёл из JetBrains 1 декабря, это буквально можно заметить на графике коммитов в php:
а это действительно минус? в последние пару лет, там такой трэш иногда делали, что кажется это к лучшему что язык чуть замедлит развитие. возможно это даст народу обжиться, найти точки для развития, которые действительно важны.
Какой, например, трэш?
Я так понимаю, это партия любителей примитива, манифест которой озвучил мужчина в комментарии ниже, "не надо заморачиваться".
Я некоторое время назад обнаружил, что не все рады вектору развития языка в сторону строгой типизации, которая не позволяет им говнякать по-старинке, как раньше.
шизофреникам всегда что-то кажется и они из этого строят выводы, это я про вас.
Я год пишу исключительно строготипизированный код на пхп, мне норм. Дело в том что когда пишешь такой код и используешь ООП, сразу возникают вопросики к команде разработки php:
Зачем мне в коде вот это сахарное гуано
<?php
class Point {
public function __construct(protected int $x, protected int $y = 0) {
}
}когда мне не хватает НОРМАЛЬНОЙ перезагрузки методов в зависимости от типа аргумента как в java. Я не могу использовать убожество типа __call, его просто невозможно использовать если пишешь строготипизированный ООП код.
Если мне предлагают инструмент строгой типизации, где инструмент что бы писать реально строготипизированный код PHP, почему я должен писать это
/**
* @return Post[]
*/
public function find() : array {
// возвращает ...
}где дженерики или spl классы которые я смогу использовать для решения задач такого типа, почему вместо средств языка я должен писать какой-то мета-код.
Безусловно тернарные операторы, типизация, больше скорости и FFI это хорошо.
https://wiki.php.net/rfc/sealed_classes - это действительно нам нужно? вот прям кровь из носу, контракты будут знать о реализаторах, это что вообще? Я понимаю что это предложение, но какого черта?
Я вижу, с типизацией у вас всё хорошо, а вот с ясностью изложения своих мыслей не очень.
Как выяснилось, свои претензии вы предъявляете не к тому что было добавлено (как вы заявляли ранее), а к тому, что не было добавлено. Давайте это зафиксируем, а то неудобно получается. В конце концов если вы не хотите использовать сахар — вас никто не заставляет. РНР — это опен соурс проект, и любой человек может добавить в него функциональность, если её одобрит большинство других разработчиков. Поэтому пенять на то что добавили лично вам ненужную функциональность несколько нелогично.
Теперь, с чистого листа, можно поговорить о том, чего вам в РНР не хватает.
По поводу перезагрузки методов. Я бы поспорил, что это хорошая практика сама по себе. "Если пишешь строготипизированный ООП код", то такая перезагрузка в принципе не должна реализовываться, с _call() или без. Используйте композицию, передавайте в класс инструмент для работы с нужным типом, и вызывайте уже метод этого инструмента. Это будет и универсально, и строго, и типизовано.
Про дженерики было уже много копий сломано. Если вы считаете, что их так просто реализовать, а Никита был скорее балластом для проекта, то вы можете предложить свою реализацию. Не обязательно детальную, можете просто написать, как обойти все те проблемы и ограничения, о которых он в свое время рассказывал.
Не было никакого трэша, тем более, конкретно этот разработчик --- исключительно светлая часть РНР. И нет, замедление развития ещё никому не помогало.
По мне так вполне нормальный язык, особенно для шаред хостинга где node или еще что не особо установишь.
Вот когда будут на заборе писать "PHP жив" - это будет симптом. Ну, как с Лениным и Цоем.
А если серьёзно - я за то чтобы уметь писать на разных языках. Пишете на PHP? Попробуйте Go или Rust для ускорения узких мест. Попробуйте JS/TS с vue/react/angular на фронте, попробуйте ноду и serverless. Попробуйте Java или Kotlin. Ruby, Python. Даже если будете продолжать писать на PHP - будете писать по-другому с другим кругозором. И будет гораздо более фиолетово что о каком языке говорят, если всегда готовы переключиться.
Кто на Parser писал, тот над PHP не стебется...
могу сказать несколько минусов PHP, которые мне показались важными:
хаотичный набор встроенных функций. это случилось поначалу, так как никто вначале не проектировал этот язык и не группировал функции
сложное развертывание приложений. нужно управление модулями с правами админа сервера. в Entrprise среде установка драйверов Oracle или MS Sql уже становится небольшим приключением. например в Java драйвера добавляются на уровне приложения.
сессионная природа, скажем так, сервера PHP. время жизни приложения - время отработки запроса к серверу. сделать какие-то вещи асинхронно или в фоне нельзя. фоновые задачи приходится запускать из ОС по планировщику.
огромный плюс это, конечно, легкость начать что-то создавать.
Сессионная природа - как-раз одна из "фишек" языка.
PHP создан чтобы умирать.
Ну, справедливости ради, с приходом контейнеризации, сложности с деплойментом остались только у динозавров.
А где набор функций не хаотичный? В JS или питоне? В джаве тоже все не то чтобы просто организованно. В конечном счете удобство - это синдром утенка, типа в JS это сделано не удобно и у меня слезы из глаз вместо написания кода, но в конце все работает (это я про себя если что).
Я бы не сказал что развертывание джава приложений легче- если есть нормальный докер контейнер то оно везде легко, если нет - везде попаболь.
вот именно если кто-то сделал docker-образ который вам подходит. а если нет, то делать его трудоемко, вообщем шаг влево-вправо боль. а ведь потом его и апгредить нужно, тоже боль.
в Java все решается, например, Alpine linux контейнером, в который кладется единственная зависимость Java-приложения - JVM. все другие зависимости на уровне приложения - пакетами/библиотеками.
не только PHP страдает сложным развертыванием, та же песня с Python/Django, Ruby/Rails.
"Единственная зависимость приложения"
Ну как бы нет, во первых некоторые джава пакеты хотят конкретных бинарь в системе, конечно не все, но мы же про общий случай, да? (тот же PHP практически не имеет бинарных модулей, не знаю хорошо ли это но это так)
Потом JVM - который будем ставить? Oracle у которого не всё гладко с лицензиями, или OpenJDK который не всеми поддерживается?
Дальше будет веселье с "вы не правильно выбрали параметры GC" и ещё хрен знает какие переменные среды. А ещё у любого уважающего себя Java приложения внутри миллион Enterprise фреймворков из за чего оно имеет кучу не документированных опций конфигурации которые не всегда такие какие надо (привет log4j).
Тот же PHP требует пары пакетов после чего php-fpm работает и его особо трогать не надо.
Для меня проблемы непосредственно установки это не проблемы вообще, а конфигурации приложений уже зависят от приложения и там сумасшедшие вещи могут быть в любом языке.
Не ради холивара, а чтобы расставить точки над i:
– В 99% случаев для запуска java используют openjdk / liberica;
– В 99% случаев нет необходимости задавать параметры jvm: дефолтный G1 GC более чем достаточен; heap подстраивается по память контейнера, но если надо, то можно и задать явно – это один параметр;
– Куча Enterprise фреймворков в последние 10 лет выродились до экосистемы Spring/SpringBoot, если конечно у вас не замшелое легаси;
– Нашумевший log4j используется разве что в том замшелом легаси, т.к. в экосистеме Spring по умолчанию slf4j+logback;
По ветке обсуждения: скорее всего автор выше имел ввиду, что если вам захочется собрать свой образ для Java с нуля, то вам достаточно взять образ ОС и добавить только openjdk. В случае же php, кроме php-fpm придется заранее решить - какие модули будут использованы в моем приложении, т.к. каждый модуль добавляется по отдельности, ну или добавить сразу все, с запасом на будущее.
Если способны поставить на голую машину своё барахло, то и упаковать его в контейнер - не rocket science. Там всё проще, чем кажется.
сложное развертывание приложений.
Неактуально для контейнеризованных приложений.
сделать какие-то вещи асинхронно или в фоне нельзя. фоновые задачи приходится запускать из ОС по планировщику.
Можно через очереди и воркеры.
Работаю в 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
сделать какие-то вещи асинхронно или в фоне нельзя
если у вашей системы есть консольный интерфейс, то можно
exec('nohup path/to/cli command &');
Если в вашей системе есть bash. И не забудьте подпереть какой то синхронизацией, а то если первая команда ещё работает, а вы уже запустили вторую, результат может не понравиться.
Всё не о том, надо ответить на вопрос какие преимущества у php? Ниша скриптовых языков не такая большая чтобы уместить всех, питон растёт, остальные стагнируют или падают.
PHP быстрее питона, течет меньше (и дохнет чаще) и в нем удобный чудо вектор/хеш/хрен-пойми-что но удобное.
Ниш у скриптовых языков много, ту же математику на PHP писать не буду, а вот сайтик как то сподручнее на нем. Питон на коне пока не появился другой мейнстримовый язык в который C/C++ легко встраивать, та же Julia если поправит время первичного запуска может из под питона табуретку вынуть.
Про течку не слышал, а производительность в этой нише не главное.
Сайты у меня маленькие, поэтому снижение нагрузки никак не сказалось на моих расходах, всё в пределах тарифа было изначально (но видимый невооружённым глазом прирост производительности порадовал). А вот если сайт очень популярен, то это позволило бы заметно экономить деньги.
Судя по тестам, PHP 7 гораздо быстрее Python 3. При этом, сложность разработки на Python и PHP примерно одинаковая, то есть не получится сказать, что разработка «более быстрого» сайта на PHP будет дороже, что нивелировало бы экономию на серверах.
Да, но в этой нише это не киллер-фича, когда сайт уже на пхп бесплатный прирост это круто, но для новых проектов критерии другие судя по графикам популярности.
Плюс появился Node.JS (который тоже быстрый), много кому удобнее на одном языке писать как frontend, так и backend. Python во многом набрал популярности за счёт новых областей типа Data Science, где для этого первее всего появились удобные библиотечки. Ну и одобрение Google наверное сказалось. Первые лет 15 Python ведь не особо пользовался спросом (Python старше PHP), а потом вдруг пошёл вверх.
для меня основное преимущество пхп в том что он не догматизирован разработчиками, как питон или джава. пхп позволяет мне, например, экспериментировать с ООП, заниматься исследованием ООП, в весьма обширных рамках. джава уже окуклился со своими фреймворками и паттернами. это не плохо, но это ограничивает простор для экспериментов. питон в вебе представлен в основном джанго, что тоже создает ситуацию как с джавой. короче джава и питон задали у себя промышленный стандарты, и попытка писать лучше чем они требуют или исследовать возможности писать по другому, называют обычно - ересью(говной).
Питон мультипарадигменный, в чём он догматизирован?
и джава, и питон мультипарадигменные я не спорю. Догматизация именно в использовании инструментария для решения конкретного рода задач. То есть по сути что в питоне/джаве фреймворки являются чуть ли не еще одним языком для решение конкретных отраслевых задач. При этом решение этих задач другими инструментами, будет воспринято негативно или не найдет понимание, так как нарушен отраслевой стандарт, то есть - догма. Отраслевой стандарт хорошо для поддержки продуктов, но именно для исследований и экспериментов плохо. Когда в пхп какой-то из фреймворков станет отраслевым стандартом, то тогда я смогу точно сказать, что он стал таким же как и джава, и питон. Сейчас в пхп лидирует ларавел, но все отнесутся с пониманием, если будет использован симфони или ламинас, на худой конец юии. В питоне, как я понимаю если ты не выбрал джангу для веба, то к тебя автоматом появляются вопросики.
Я не спорю, что и на питоне, и на джава можно заниматься тем же, что и в пхп занимаюсь я, но это будет крайне не эффективно так как на реальных проектах это невозможно будет попробовать, в силу описанных выше причин.
Python движется к микросервисам и асинхронности, а Django это не про асинхронные микросервисы; для синхронных МС и небольших монолитов есть Flask, для асинхронных МС есть FastAPI или Aiohttp. Django возможно стандарт для крупных монолитов, но не стандарт для веб-приложений вообще.
В опросе SO за 2021 год есть три фреймфорка на Python.
Ниша скриптовых языков не такая большая чтобы уместить всех, питон растёт, остальные стагнируют или падают.Вряд ли Python сможет заменить JavaScript, который уже много лет держит первое место по популярности. Всё же веб слишком важен, и JavaScript (в паре с TypeScript) достаточно хорош, чтобы не было необходимости в браузеры добавлять поддержку других скриптовых языков.
Вот мне сейчас пыхари минусов-то накидают..
PHP сейчас жив примерно так-же как и Cobol (ну, ладно, немного утрирую). Его держит на плаву огромный пласт созданного в прошлом ПО, которое проще поддерживать чем переписать заново. Думаю в таком состоянии он еще долго будет жить.
даже в хеловорде налажали facepalm
отус такой отус...
Я за последние 20 лет так и не понял, php быстрее умрет, или у доллара крах настанет.
Я писал на многих языках, начинал с 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 есть минусы, но плюсов гораздо больше и писать на нем на порядок комфортнее, чем на любом из тех языков, которые я знаю.
Сложил 2 числа - получилось обычное сложение. Попался текст - автоматом конкатенация.
Девочка_и_javascript.jpg ;) В php тоже так? Строку на int умножать можно? А наоборот?
В РНР нельзя писать <? echo $name; ?>. Но можно (и нужно) писать <?= $name ?>.
Ну и в профессиональной разработке практически всегда пишется {{ name }}
Юноша, читайте официальные доки, там много мудрости: 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-го года. А автор в школу уже ходил в этом году? Или еще в садик?
Спасибо, поржал :) "Да я в 1918 году дивизией командовал!", и при этом никогда не видел нотации {{ name }} — это говорит о многом. Меньше, чем предыдущий манифест про "плюну в морду", но тоже доставляет. Как говорится, аффтар, пешы ещо.
Вы с какой целью интересуетесь?
Чтобы узнать, можно посмотреть https://twig.symfony.com/ и https://laravel.com/docs/9.x/blade
Рекомендую глянуть https://mustache.github.io
Очень лёгкий и универсальный шаблонизатор. Есть реализации для огромной кучи языков, в том числе php и js.
Спасибо, поржал :)
Я раньше слышал это слово, но не приглядывался. А сейчас решил посмотреть, и страшно удивился. "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}} — цикл или условный переход.
В итоге логика в шаблоне есть, но мы это упорно отрицаем. И получаем нечитабельную, нелогичную галиматью. Никогда не следует приносить логику в угоду идеологии.
Над предыдущим комментатором тут все угорают, не стоит принимать его всерьёз :)
Ну и я больше к тому что РНР тоже не стоит на месте, и "вместо <?php echo $name; ?> можно писать просто {{name}}" — это квазиквотер, сделанный отдельной библиотекой.
{{name}}" — это квазиквотер, сделанный отдельной библиотекой
Не совсем понятно, это уже встроенный в язык функционал, или что-то побочное? Ибо лыжи как-то совсем не едут: Teh Playground!
{{ name }} обрабатывается фреймворками?
Нельзя потому что стандарт запрещает использовать короткие теги (из-за их неуниверсальности).
{{ name }} обрабатывается шаблонными движками, которые используются составе фреймворков, но вполне могут применяться и самостоятельно.
> Страшно представить, какой стиль у кода в итоге.
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 такого нет. Я пишу код с таким оформлением, как удобно мне или тимлиду, а не парсеру в дурацких языках.
Я живу в хорошем доме, езжу на отличной машине, потому что потратил 20 лет на то, чтобы стать по настоящему успешным в этом деле.
А заметил, здесь никто на эту ерунду не ведётся, как это было бы на дзене.
Кстати, поскольку я не могу написать лишний комменарий.
Огромным удовольствием для меня было узнать, что php скрипт можно запустить в bash. Написал бэкапер в связке с sh скриптом. Правда, здесь нет таких светоакустических эффектов, как в веб...
Опять какая то левая статья. Зачем вообще публиковать очередной PHP is die? Чисто набить себе очков на хабре?
Пока жив веб, будет жить PHP: Personal Home Page. На данный момент это самый лучший скриптовый язык для веб сайтов. И не важно, пишите как ФП или ООП. Laravel или Symfony. В итоге веб сайт.
Конечно, сейчас существуют такие сайты как Front-end (React, Vue, Angular, ...) и Back-end (Go, Python, Ruby, C#). Но в основной массе - это PHP.
В каком то смысле PHP - мертв. Он, как и любой скриптовый язык, умирает каждый раз, когда скрипт завершает свою работу. Скрипт завершил работу, умер, завершил, умер, и т.д.
Но как ЯП его не похоронить. Как и Python и Ruby.
Фронт на Vue/React etc и бэк на PHP прекрасно сосуществуют. Писать API на PHP - сплошное удовольствие. И отлаживать.
У PHP есть крупный минус - отсутствие многопоточности. Для нее нужно использовать другие языки. Но он и не для нее создавался.
На Хабре были бенчмарки по производительности - Java, Node.js, PHP и что-то еще - все примерно одинаково на удивление. Не "в несколько раз", по крайней мере. Имеются в виду именно вычисления или работа с БД
Ну и напрягает неупорядоченность в определениях функций. Типа, когда у property_exists() и key_exists() аргументы идут в разном порядке
В остальном PHP - прекрасный инструмент в руках программиста
У PHP есть крупный минус - отсутствие многопоточности.
А это что?
У 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 (т.е. там, где реальные затыки).
Ну кстати и без ффи, вот один дядька вчера на реддит написал что сделал корутины как в го, на файберах. https://old.reddit.com/r/PHP/comments/u80gyg/true_coroutines_like_go/
Если не врёт, то будет доступно всем. Неблокирующие файловые операции, вот это вот всё.
Я, правда, сам не асинхронный человек, и как-то оценить эту либу не могу.
Не, ну так файберы и есть чистые грин треды. Там даже полноценный стек есть. Про них я как бы и говорил. Рекомендую всё же потыкать в них. Я в восхищении. Все эти Promise и Future после их появления маршем идут в утиль и кажутся неюзабельными костылями.
Но вопрос же был изначально не про грин треды, а про, цитата, "многопоточность". Отсюда и подобный комментарий, мол, если нету, то никто не мешает их написать (пусть и через SDL обёртку, как это сделал я).
А с SIGSEGV ошибками аффтор этих тредов пусть сам развлекается, если уж решил использовать ;)
Я уж не говорю про то, что надо ещё будет придумать как использовать CMPXCHG операции для синхронизации данных в многопоточной среде (хотя ходят слухи, что ext-sysvsem расширение доступно из коробки под линусками: https://www.php.net/manual/ru/book.sem.php, так что тут всё готовенькое уже).
Потому что бюджет на продвижение в отусе.
Народная примета — если на Хабр потянулись левые переводы левых статей по пхпе — значит в отусе скоро очередной курс.
В общем, надо дождаться, когда наберут уже достаточно оболтусов, чтобы учить их писать вот этот вот адов говнокод от ведущих экспертов, и эта активность прекратится. До следующего набора.
.
Оспади. Да как это мертв? Кто это говорит? Люди не понимают шутки: php умирает в момент завершения исполнения скрипта.
В нише простых и средних по нагрузке, контенту и посещаемости сайтов и API у PHP действительно нет конкурентов. К тому же перейти с него на другой язык, типо java гораздо легче, чем, например с питона.
Если вы выбираете "с какого языка начать изучать програмирование", то вопрос поставлен не корректно. В первую очередь нужно выбирать сферу, простоту изучения, количество вакансий, обширность документации, количество примеров и гайдов.
Обычно на бэке +- 3 варианта: Питон, Java и PHP.
Питон, например, имеет смысл выбрать, если вы потом хотите уйти в датасаенс. Java, если хотите в интерпрайз или в целом не уверены, что хотите. PHP, если нравится писать API и хотите как можно быстрее устроиться.
В целом, если честно, разница минимальна, но так выбирать легче, когда нет опыта. Через года 3 по зп и задачам можно выйти на одинаковый уровень, что бы вы не выбрали.
Если решать в категориях "нравится синтаксис" или "модно", то можно никогда не определиться.
Если я не ошибаюсь, то в Slack и Facebook используют HHVM и, как следствие, Hack
Хороший некролог
Да успокойтесь уже, никто его не хоронит. Хватит писать статьи про то, что пхп не мертв и какой он крутой. Одно и тоже стабильно раз в 2 недели.
Это не так. PHP не умер. Он жив, и до “конца жизни” ему еще очень далеко. На этом все.
Начну с того, что нужно верно понимать данное высказывание и сменить акцент с языка PHP, на авторов подобных высказываний, так как многие столкнулись с несколькими концептуальными проблемами языка, то они ищут замену языку и рапортуют о своей смене диспозиции, что говорит о профессиональном росте специалиста и его развитии.
Говоря о развитии специалиста это всегда воспринимают в штыки и воспринимают, что PHP какой-то отсталый язык не заслуживающий внимания и это еще одна ошибка, так как на ранней стадии развития компании использование подобных экономический выгодных инструментов является решающим фактором.
Что касаемо самого языка, то его можно отнести к ряду си-подобных синтаксисов и имеет вполне неплохую сегодня производительность и реализацию, так что вполне применим на раннем этапе становления бизнеса.
С ростом амбиций у компаний возникает потребность в добавлении активных соединений, множественной обработки и порой доходит до работы в реальном времени и тут уже плохо подходят скриптовые языки в целом и не только PHP, но и другие и на первый план выходят языки или хорошо масштабируемые (для масштабирования в ширину) или если ставка сделана на производительность оборудования, то языки с высокой эффективностью (компилируемые в машинные коды).
Это не значит, что PHP не способен решать эти задачи, а скорее менее эффективен, но и то в последние годы ядро языка сильно развивают и оптимизируют и тут следует обратить внимание на Benchmark-и показывающие реальное положение дел.
Хорошо масштабируемые языки обычно имеют возможность распределенного выполнения и копируемую природу данных вроде Elexir или ферймворков вроде Pulsar2.
Делающие ставку на железо это следующая языки имеющие бинарную трансляцию C#, Java, JavaScript или нативную трансляцию кода Golang, C/C++/Rust. Опять же эти языки требуют особго внимания и квалификации программиста и нужны делеко не каждой компании.
Я считаю, что в целом данный миф о мертвости языка PHP связан в первую очередь с ростом квалификации у программистов и соответсвенно с переходом коммерческих команий на качественно новый уровень.
Новый уровень — это какой? Можно пример? Я имею в виду конкретный. Скажем, пример интернет-магазина, который переписали с РНР на C/C++/Rust. Или даже целиком на Golang — целиком, а не воткнув его в паре узких мест.
Новый уровень — это какой? Можно пример?
Конечно. Преобразование компании в группу компаний или создание дочерних предприятий или из-за возросшей нагрузки или увеличения штата разработчиков на другом стеке. Это все в первую очередь продиктовано обстоятельствами в которых оказалась компания.
Скажем, пример интернет-магазина, который переписали с РНР на C/C++/Rust. Или даже целиком на Golang
Гибридные решения тоже имеют право на существование, так сказать переходная (миграционная) стадия развития. Сейчас достаточно популярная - микросервисная архитектура, но и тут есть свои ограничения, но и для каких-то случаев она может оказаться оптимальной. Все зависит от целесообразности в каждом конкретном случае.
Изначально вопрос перехода ради перехода на Golang, Rust, C/C++ может оказаться очень дорогим удовольствием и пустой затеей, а может и экономический целесообразным решением. Скажем для обычного небольшого интеренет магазина собственных товаров с фиксированным потоком локальных клиентов (локальная доставка скоропортящихся товаров) с фиксированными расходами на поддержку магазина может быть не нужным развлечением, а для корпорации с автоматизацией процессов вроде Amazon и смешанными контрактами PHP потребует дополнительных усилий для поддержки.
Решение требующее реакции в реальном времени на скриптовых языка (в том числе и на PHP) и вовсе невозможно и становиться вопрос о нецелесообразности при масштабировании этого решения. Rust в таком случае будет решением, но это уже не совсем работа сайта, а скорее какая-то системная разработка каких-то внутренних инструментов - возможно даже с Web интерефейсом.
Многое тут можно определить только уже на работающем бизнесе в частности при уже существующих отделах технической поддержки, контроля качества и конечно развитом управлении в компании. Если отдел качества рапортует от 20% отказов при совершении покупок проносящих 80% прибыли из-за 500 ошибок на сайте, то начинаем считать целесообразнось "лечения" проблемы и это может быть как масштабирование, так и микросервисная архитектура так и полное переписывание на Golang.
Что касаемо конкретных примеров и планов миграции, то поищите на Habr были какие-то статьи по переходу инструментов и сайтов с PHP (Ruby) на Golang. Я смог найти с ходу несколько историй перехода, но не думаю, что в этом есть какой-то смысл чаще всего это будет происходит на уровне эволюции самой компании и незаметно появятся вокруг решения на PHP строительные леса с другими технологиями.
Я, в общем-то, и был уверен что примера у вас нет :)
Я в общем-то понимал, что изначально вы своим вопросом решаете совершенно другую задачу мало связанную с публикацией и любые попытки разумного объяснений это пустая трата моего времени.
Вы даже на уровне псевдонима сообщаете, что представляете лагерь фанатиков, которых сейчас в каждой технологии очень много, так что будет это Golang или PHP обсуждение с вами перейдет в холивар.
В 99% случаях смена языка — это:
1) Ну вот вышел новый язык GO#, RustScript или Java++ давайте вынесем Х в отдельный кусок, заодно похайпимся.
2) Нас (компанию т.е.) купил условный Яндекс, а как известно, в условном Яндексе вообще не умеют писать на PHP, да и экспертизы нет, а значит переписываем условный Кинопоиск на условный Питон. Потому что погромистов на оном больше. Ну и что, что медленней будет… И стоить саппорт дороже… И код хуже качеством… Зато ресурсы на саппорт есть.
3) Мы писали этот код в аврале, с дедлайнами и переработками. Поддерживать его больше нереально. Сейчас выделили бюджет, так что давайте попробуем условный Elixir (на котором пишет полтора землекопа), зато хайпанём!
*п.3 хоть и похож на п.2, однако обычно это кончается ничем (закрытием проекта).
А случаев когда из-за нагрузки надо всё переписать на ассемблер и это ну прям оправдано… Ну такое просто невозможно в принципе, т.к. и на пыхе можно ассемблерные вставки вставлять. Боюсь что даже всякие HHVM/KPHP появлялись как больше инженерные проекты фор-фан (потому что можем), а не оправданное решение.
Выбор технологии может действительно определять инновационность (бравость участников), экспертиза команды (квалификация), борьба с техническим долгом (покрытие кода).
А случаев когда из-за нагрузки надо всё переписать на ассемблер и это ну прям оправдано. Ну такое просто невозможно в принципе, т.к. и на пыхе можно ассемблерные вставки вставлять
Возможно в классе работ по созданию сайтов действительно нет необходимости использовать производительный код - ничего ведь страшного, что пользователь подождет на пару миллисекунд больше, а памяти/процессора/диска нужно будет купить в разы больше.
В классе задач по работе с данными (статистика, отображения, агрегации, тиражирование, сжатие, распаковка) вопрос стоит остро (будет ли результат получен за 0.176 сек. или запрос упадет по памяти), а так же в задачах обмена информации в реальном времени (опять же при классическом применении в сервере приложений PHP-FPM) обработка различного рода сводок на биржах, текстовые сообщения, видео, аудио и т.д.
Относительно HHVM/KPHP это попытка сделать реализацию языка эффективной по определению, т.е. попытка фанатиков технологии расширить класс применимости языка. Плохо помню за счет чего ребята хотели это достигнуть, но предполагаю, что там всего два варианта движения или трансляция в машинный код или в промежуточное представление. В любом случае думаю, что тут нужно в первую очередь было работать с разработчиком оригинального PHP и инвестировать в основную ветку разработки.
Хватит говорить, что PHP мертв