После года разработки опубликован релиз языка программирования PHP 8.5. Новая ветка включает серию новых возможностей, а также несколько изменений, нарушающих совместимость...Подробнее: https://www.opennet.me/opennews/art.shtml?num=64290
> Добавлен оператор "|>" (pipe)Синтаксический сахарозаменитель какой-то
А по мне так недурно выглядит.
Наверное у них просто нет методов-расширений (которые прекрасны, но требуют определённого кода как в том же дотнете и усложняют жизнь системам автоподстановки) и они выкрутились таким способом.
в том же дотнете тоже не у всех есть методы-расширения, зато у некоторых есть пайп оператор с рождения
Как инородное говно он выглядит, особенно с замыканиями. Какой-то недоумок сделал чтобы закрыть единственный кейс. А если надо сделать деструктивное присваивание того, что вернулось с функции и передать дальше?
банальный оператор композиции, непонятно зачем это называют "трубой".
минусатор видать с логикой не дружит, у него труба и конвейер это одно и тоже.
Нет, просто ты путаешься в терминах. Если не профессионал - не пиши, совет такой.
> Нет, просто ты путаешься в терминахf(g(x)) = g * f --> это называется композиция функций, * - собственно оператор композиции. И это никак не "труба", а конвейер.
Покупая в макдаке банку колу, вы через трубочку виски пьете? А мука попавшая на кондитерский конвейер не выпечкой в итоге получается? Мука равна выпечке? Кола равна виски?
> Если не профессионал - не пиши, совет такой.
Вам бы сначала толковый словарь изучить, потом советы давать
Кексперту//en.wikipedia.org/wiki/Pipeline_(software)
"""
Connecting elements into a pipeline is analogous to function composition.
"""Но слово "pipeline" тут не в значении трубопровода, а конвейера, потому-что по "трубе" может течь однородная масса, что никак не укладывается в логику передачи результата от оной функции к другой, что на самом деле называют композицией - конвейером!
//en.wikipedia.org/wiki/Pipeline_(computing)
Термин "трубопровод" некорректен для композиций функций.
нынче на википедию бы ссылаться
ещё и англоязычную
> нынче на википедию бы ссылатьсявы бы предложение свое дописали бы или нынче с логикой дружить не в тренде?
Pipeline - это когда результат a передается аргументом b, и так далее.
Функциональная композиция, естественная для стековых языков - ровно то же самое.Да, pipeline обычно используется в контексте I/O, а композиция - когда речь идёт о чистых функциях. Но раз уж мы говорим о скриптовом языке, в котором нет никакой разницы между этими понятиями, то можно считать синонимами.
> Pipeline - это когда результат a передается аргументом b, и так далее.Что такое Pipeline? Трубопровод ведь, не так? Ну вот вам вопрос, у вас по трубопроводу с одного конца если подают воду, с другого конца, что вытечет на выходе?
А вот функция f(x) = y (возвращает y), а функция g(f(x)) - получает на вход тот самый "y", а не изначальный "x". Отсюда, при y =/= x это вовсе не "трубопровод", а конвейер. А этот конвейер это банальная композиция функций, там ниже я дал ссылки, что есть композиция функций.
При f(x) = x и g(f(x)) = x еще можно с натяжкой назвать "трубой", а функции - "фитинги". А это все не имеет смысла если сразу можно записать как g(x).
> Функциональная композиция, естественная для стековых языков - ровно то же самое.
Термин pipeline как "труба" некорректен с точки зрения оператора композиция.
> Да, pipeline обычно используется в контексте I/O
Это как бы шина передающая одни данные на разные устройства, но не как конвейер, где результат с одного конвейера передается на следующий.
> а композиция - когда речь идёт о чистых функциях
Композиция это конвейер, неважно чистые или не чистые функции.
> Но раз уж мы говорим о скриптовом языке, в котором нет никакой разницы между этими понятиями, то можно считать синонимами.
Ну раз мы говорим о php, тогда мне не надо удивляться минусаторам, они с логикой не дружат, куда там с языком родным.
> Ну вот вам вопрос, у вас по трубопроводу с одного конца если подают воду, с другого конца, что вытечет на выходе?
> Добавлен оператор "|>" (pipe)С одного конца оператора передали строку 'Hello', с другого конца оператора вытекла она же. В чём проблема?
> С одного конца оператора передали строку 'Hello', с другого конца оператора вытекла
> она же. В чём проблема?Я же описал этот случай
"""
При f(x) = x и g(f(x)) = x еще можно с натяжкой назвать "трубой", а функции - "фитинги". А это все не имеет смысла если сразу можно записать как g(x).
"""Оперируя вашей логикой, можно сказать, что на вход всех функций подается двоичная строка и на выходе всех функций в итоге двоичная строка и поэтому любая композиция функций это есть труба (а в реальности ничего кроме двоичных строк в вычислениях и нет). Но подождите, возвращаюсь к значению слова "трубопровод", если с одного конца трубы подавать воду, то с другого конца трубы разве сладкая вода вытекает? Нет, потому-что, по трубе может течь однородная масса (f(x) = x), ее ничто не прерывает, и никто ее не изменяет по пути (g(f(x)) = x ~ g(x)). Если у вас на выходе трубы все же получилась сладкая вода, то я вас поздравляю, это конвейер по производству пепси-колы, а не водопроводная труба.
Ясно теперь почему термин трубопровод некорректный?
При чём тут функции, при чём тут двоичные строки? Речь про конкретный оператор: "|>".Он из одной ф-ии берёт конкретные данные (строка "Hello"), и передаёт в следующую ф-ю ровно то же самое - строку "Hello". Ничего туда не примешивает, не подслащивает, не убирает и не изменяет. Это просто труба, pipe.
"Да что ты, чёрт возьми, такое несёшь?" ©
> При чём тут функции, при чём тут двоичные строки?у вас любые данные представленные в виде двоичных строк, ку-ку.
> Речь про конкретный оператор: "|>".
Этот оператор уже называется - композицией.
> Он из одной ф-ии берёт конкретные данные (строка "Hello"), и передаёт в
> следующую ф-ю ровно то же самое - строку "Hello".давайте, передачу аргументов в функцию, называть "трубой", дожили. Вы понимаете, что запись вида f(x) или fx говорит о том, что примени функцию f к аргументу x. Так таковой "передачи" нет!!!
x |> f(x) = y |> g(y) = z |> h(z) = v
если вы называете это |> "трубой", тогда f(x) это "фитинги" - соединители труб, так, что у нас на входе? на входе - x, а на выходе - v. Это что за трубопровод? Это конвейер пепси-колы. Даже если рассмотреть в минимальном случае:
x |> f(x) = y
Это что труба? На входе х, а на выходе y. У вас из водопроводной трубы пепси-кола на выходе?
Между двумя компонентами конвейера трубная передача возможно, так же как и любая иная передача, то есть вашу "трубу" я могу назвать "проводок", "звонок", "волокно", "веревочка", "посылка", "письмо" и т.д. любой термин в понятии передачи.
Отсюда, термин "труба" - не корректный, ибо по трубам течет однородная масса. Только в этом случае
x |> f(x) = x
можно |> назвать "трубой". Даже в юниксвей оператор | (pipe) имелся ввиду конвейера, а не просто "трубы".
Значит, если два завода соединили трубой, то это уже не труба, а композиция... Всё с тобой ясно, давай досвиданья.
> Значит, если два завода соединили трубой, то это уже не труба, а
> композиция...А кто это отрицал? Но ведь труба не есть трубопровод, подключи еще один завод в итоге что? И вопрос в том, что почему выбрали термин "труба", а не конвейер.
> Всё с тобой ясно, давай досвиданья.Удачи.
//wiki.php.net/rfc/pipe-operator-v3
"""
Composition generally takes two forms: Immediate and delayed. The immediate execution of chained functions is typically implemented with a “pipe” operator. Delayed execution is typically implemented with a composition operator, which takes two functions and produces a new function that will call each one in turn.
"""//wiki.php.net/rfc/function-composition
Аргумент пхпешников - что их "труба" - это Immediate композиция, а в математическом смысле это яко бы delayed. Но даже в математике композиция это функция обертка которая не определяется, а исполняется. И делить тут композицию на Immediate and delayed - бред!
//en.wikipedia.org/wiki/Function_composition
In mathematics, the composition operator ∘ takes two functions, f and g, and returns a new function h(x) := (g ∘ f)(x) = g(f(x)). Thus, the function g is applied after applying f to x. (g ∘ f) is pronounced "the composition of g and f".
h(x) при вызове вернет результат g(f(x)), а не функцию как результат, которую потом надо еще вызывать, это уже вызов через оберточную функцию, и в пхп это было бы
$output = h($input); А это разве не Immediate исполнение?
Альтернативно одаренным оставлю ссылки://en.wikipedia.org/wiki/Function_composition
//en.wikipedia.org/wiki/Function_composition_(computer_science)
взято из руби и эликсира
может из джулии... Откуда вы знаете...
Из OСaml и F#.
Скорее из F#. Они там (https://thephp.foundation/blog/2025/07/11/php-85-adds-pipe-o.../) упоминают эликсир, но:> The |> operator appears in many languages, mostly in the functional world. F# has essentially the exact same operator, as does OCaml. Elixir has a slightly fancier version (which we considered but ultimately decided against for now).
Если бы просто "сахар"... Это засилие разнойпунктуации в языке превращает его в brainfuck !!!!!! Это просто пи...ец какой-то !ГОРШОЧЕК НЕ ВАРИ !!!
Лучшейший язык пи аш пи(пи эйч пи) стал еще лучше. Странно что до сих пор нету альтернативного рантайма, как node для javascript только наоборот.
Википедия говорит что есть и много. Сходу вспоминаю, что лицокнига и вконтакт рожали себе по рантайму.
ВТентакле породил ужаснейшнего монстра - KPHP, который транспилирует код в C++ для его дальнейшей компиляции.
Представили себе цену поддержки этого чудовища?
Один человек на энтузиазме. А в конторе где можно форсить какие фичи и синтаксические конструкции можно и нельзя использовать - вообще полчеловека.
Лучше бы сразу страницы на С++ писали.
> как node для javascript только наоборот.т.е. javascript для node?
> Лучшейший язык пи аш пи(пи эйч пи) стал еще лучше.Таки пи эйч пи и только пи эйч пи. Латинизмы вроде пи аш пи и русизмы вроде пэ ха пэ - это зло.
Пых он и в Африке пых.
На французском он пе аш пе, откуда вы тут вдохновение черпаете не знаю, румынский?
> На французском он пе аш пе, откуда вы тут вдохновение черпаете не
> знаю, румынский?Причём тут французский? В оригинале PHP - это Personal Home Page, то есть английский.
>phpФП же, нет?
А русская латынь, ну есть такое, что отрицать что есть, она родом из немецкой латыни которая в свою очередь из французской латыни, а вот с прочими латынями типа итальянской или английской (хотя последняя тоже из старофранцузской, но уже с разночтениями), смеха ради в итальянской таки есть "че" и это там не обсуждается, мало того что мы заимствовали "с" перед "i/e", так смешное даже не в итальянском или "нашем" подходе, а то что там везде в латыни был "к" при любой записи через "с"...
Русская латынь - это всего лишь глупая и давно устаревшая конвенция из советской средней школы и советских шахмат, корнями уходящая в дореволюционные гимназии. До сих пор в школах привыкаете к иксам и игрекам, а затем начинаете корёжить профессиональные термины, которые не имеют никакого отношение ни к латыни, ни к дореволюционным гимназиям.
PHP - это непрофессиональный термин
Разрешение На Работу вполне официальный документ. Почему он непрофессиональный?
>А русская латынь, ну есть такое, что отрицать что есть, она родом из немецкой латыниТак умник, стоп. Нет такого языка, как "немецкая латыни". Есть немецкий язык имеющий письменность основанный на латинском алфавите. В России Химия, Биология, Медицина, Математика - это латынь и греческий. Программирование - это английский. Уяснил?! Всё свободен!
Латынь классическая как язык одна, но в школах и гимназиях разных стран были разные традиции её чтения. В Германии, Франции, Англии по-своему читали. Сейчас вот есть ещё восстановленное классическое чтение - реконструкция лингвистами чтения классических времён. В восстановленном классическом чтении Caesar - как раз Кайсар, а не Цезарь.
>В Германии, Франции, Англии по-своему читали.В России всё намного хуже! Не было своей традиции чтения. В разные времена латинские слова заимствовали из того языка, который в то конкретное время казался модным. При Москвинских царях заимствовали из польского. При Питаре Первом - из голланского, при Екатерине Великой - из французкаго.
У Русской православной церкви была своя отдельная, скрепная метOда чтения латинских слов.
Так вот "цикл" никогда не был "чикл", а всегда был "кикл"))
cyclus - сайклус
Слово cycle (сайкл) однокоренное с bicycle (байсикл) и восходит к латинскому circulos (циркулос, круг). Ну третий класс же, ну, позорище.
Или вы циркуль тоже называется чиркуль или киркуль?!
Киклоп (с) Виктор Олегович
Во-первых circulus, не circulos. Во-вторых, да, в классической латыни это киркулус.
circulus - не "циркулус", а "сюркилус"
Вообще то это жаргоизмы. Хотя я уже привык что "шпициализды с опена" раньше опу с пальцем сравнивали, а теперь вообще не отличают.
> а теперь вообще не отличают.Так, маразм - он такой. Подкрадывается незаметно.
> Вообще то это жаргоизмы.Невежество это, а не жаргонизм.
ПХП: Хыпертеxт Препроцессор.
ПХП: Хыпертеxт Препроцессор.
swoole ?
опять сломали все плагины?
и совместимость тоже...Ну вот как работать, только разберешься, и на тебе, бац и уже работает не так!
Вот как раз повод поработать, а не ваньку валять.
Выглядит сложнее джавы и Си++ вместе взятых.
Ну насчёт плюсов ты загнул, а вот джаву я считаю пых уже почти догнал. И в чем прикол этого языка теперь непонятно.
Индусы. Индусы любят яву. Любят яву настолько, что изговняли весь дотнет, дабы по образу и подобию. Ведь чем больше строк напишешь, тем больше заплатят.
Молодежь нынче полностью не знает php все только питонисты. Сложнее сказать в чат джипити напиши мне привет мир они не могут.
php не особо нужен в 2025 году для новых проектов, он годится только для легаси, более того, для нормального бэкенда он и не использовался никогда. php - нескучный шаблонизатор и не более.
Да, смена поколений. PHP умрёт примерно так же и по тем же причинам, что и Perl.
Скорее всего у него будет не судьба BCPL (совершенно мёртвый язык), а какого-нибудь Кобола.
Только вот у Perl и до веба, и после было применение как языка. Применять где-то кроме веба PHP не имеет смысла.
А теперь уже и в вебе не имеет смысла.
Простите, а что нынче актуально в бэкэнде вэба, желательно в процентном соотношении?
Это мало что меняет, разве что PHP умрёт быстрее. Но то, что это смена поколений разработчиков - несомненно. Зумеры точно не будут кодить на этих языках. Альфы скорее всего похоронят ООП.
А зачем он молодёжи? Время LAMP уже давно прошло. Вагон фреймворков на любом ЯП - и почти всё не такое вырвиглазное, как PHP.
> Время LAMP уже давно прошло.А мужики-то не знают. Кстати этот сайт даже не на ПХП написан, а внезапно на... perl.
Этот сайт написан в далёком ламповом 1996 году сисадмином, которому сейчас примерно полтинник. Зачем ему осваивать что-то более молодёжное?
Изменений не так много за целый год. Надо смотреть бенчмарки. Пайп оператор выглядит не очень нужным, писать на нём точно не будут т.к. он практически ничего не даёт, за то сломает обратную совместимость кода с прошлыми версиями. Тут вокруг 9.0 ходят серьёзные разговоры про дженерики и поговаривают про реализацию Pthread (пока не ясно на корутинах или нет) нативно в базовой либе. Вот таких изменений подождём однозначно.
пипец, а ведь можно было использовать "..." и там, где несколько аргументов, чтоб без замыканий:$output = $input
|> trim(...)
|> str_replace(' ', '-', ...)
|> str_replace(['.', '/', '…'], '', ...)
|> strtolower(...);дизайнеры языка не могут в консистентность. Хотя, требовать от пыха консистентности глупо, весь язык адская мешанина стилей явы, си и перла (гуглить "фрактал плохого дизайна").
Нормальный дизайн к которому невозможно придраться только у lua. Все остальное треш в большей или меньшей степени.
>>фрактал плохого дизайна
>>Кстати: я обожаю Python. И с удовольствием прожужжу тебе уши, ноя о нём, если ты на самом деле этого хочешь. Я не утверждаю, что он идеален; я просто взвесил его преимущества и его проблемы и сделал вывод, что он лучше всего подходит для того, что я делаю.Ну т.е. питонист (лол) придолбался к штуке, которая изначально просто препроцессор страниц, эдакий веб-баш, постепенно обрастающий функциональностью. Это как явист, катящий бочку на 1С; вроде как и выглядит логично, но аргументы уровня «танк Т-90 хуже тойоты камри, ведь в танке нет Car Play и бесключевого доступа, а управление передачами вообще ужас» обычно вызывают сомнения в рассудке говорящего.
Безотносительно питониста. PHP, постепенно прирастающий функциональностью, при этом ломающий совместимость со старыми версиями, но оставляющий мусор в именовании функций и мусор в синтаксисе.
В PHP до сих пор нет AST, им сложно что-то этакое воротить местами. Думаю, здесь либо приколы с парсером, либо "как в F#", там тоже только с лямбдами.
https://wiki.php.net/rfc/abstract_syntax_tree
Status: Implemented (in PHP 7)
Кстати а что там по оптимизациям? В прошлых релизах все ускоряли и ускоряли, в этом релизе ни слова
в этом релизе ломали совместимость
Вас в гугле забанили что ли?https://tideways.com/profiler/blog/php-benchmarks-8-5-vs-8-4...
Ну язычок он то не особо в 2025, ни в каких нормальных компаниях он не идёт как основной, это так себе язычок на сегодня, хотя совсем копеечных вакансий полно для него. Увы, пых упустил возможности быть серьёзным язычком.
но легаси помирать будет еще долго
Для легаси много программистов не надо, а так пых на слуху только благодаря вордпресу, ну и всякий колхоз использует пых для простеньких сайтиков, это не считается. Увы, пых ждёт судьба перла.
В целом для пыха много программистов не надо. А людей которые готовы заплатить за быстрый результат всегда много.
Ой, уже, наверное, лет 10 php-все, а сайты все производят и производят, wp, bitrix, laravel... вот это вот все, и на этом вот всем работает почти весь инет по сей день, а сколько еще это будут поддерживать, обновлять, дополнять да и зачем отказываться от его использования, в угоду чего, python? Как-то особых преимуществ вроди и нет перед php.
пых - безтиповый язычок, тяп ляп и готово. typescript + go хоть проверяют типы данных на стадии компиляции, а пых такого не может, там любая лапша сойдёт. А питон не особо лучше пыха, не понимаю хайпа вокруг него.
Мож завезут строгую типизацию, а?
Это похапистам придётся переписывать тот шлак, что они писали десятилетиями, это будет не пых а новый язычок уже.
Будет чем заняться, хорошо же ;) А то чат жопетэ чат жопетэ...
>пых - безтиповый язычок, тяп ляп и готовоС подключением. В пыхе уже есть типы, хотя, как и пологается языку не из ML семейства(Haskell, Ocaml, Rust) не в полной мере. В общем как в ts можно написать ерунду, так и на пыхе.
>typescript + go хоть проверяют типы данных на стадии компиляцииПых не требует компиляции. Вместо этого проверка осуществляется во время исполнения. Если хотите, можете взять psalm, phpstan, phan и так далее. При этом скорость запуска пыха - мгновенная. Так что тут пых однозначно TS превосходит
>А питон не особо лучше пыха, не понимаю хайпа вокруг него.Питон хуже, там аннотации типов вообще никак интерпретатором не учитываются.
Из коробки в пыхе нет никаких типов, а всякие сторонние приблуды - это васянство.
есть, давно уже, ваши данные из 2005 - устарели
вы имели в виду под васянством когда сам жёстко типизируешь, чтобы потом не приходилось временные переменные лишними строчками писать, чтобы работало?
> пых - безтиповый язычок, тяп ляп и готово. typescript + go хоть
> проверяют типы данных на стадии компиляции, а пых такого не может,
> там любая лапша сойдёт. А питон не особо лучше пыха, не
> понимаю хайпа вокруг него.TS это ужасная duck типизация, JS на стероидах, я вот все примерялся и прихожу к выводу, что лучше без типизации, зная, что ее нет, чем с такой горбатой
современный ECMAScript сильно лучше того, чтобы было ранее, хоть по сути тоже говно, если сравнивать с Java, с C# или даже C++ ))))
> там любая лапша сойдётага, сойдёт, только потом перед каким-нибудь действием будешь лишнюю строчку добавлять
все кому надо пишут правильно, и вам никто не мешает. да и компиляции в пыхе нет, там интерпретация, если что
JavaScript. Непонятно почему яваскриптёры считают свой ЯваСценарий лучше а себя элитнее.
Наверное, потому что зарплата повыше чем в пыхе, да и типизация с асинхронщиной в ts есть. Вот и гордятся...
Наверно поэтому джаваскрипт и хуже, что программисты дороже.
JavaScript не хуже пыха уж точно, а вот хуже чем го или си шарп в бэкенде, но это совсем другая история.
Ну, что одно что второе очень так себе.
То ли дело, сишечка с CVE, лол.
так их и так нету, мне через человека попросили пыхеров найти, спросил всех своих знакомых пыхеров - все переквалифицировались и уже давно забили
А на kwork спрашивали? Там же в основном фрилансеры пыхеры.
это не мне надо, а через меня запустили сарафанное радио, искали по знакомым, чтобы не кота в мешке
2009 год хоронят:
https://www.opennet.me/openforum/vsluhforumID3/56272.html#12007 год хоронят:
https://www.opennet.me/openforum/vsluhforumID3/38291.html#1всё никак не похоронят. А PHP - отличный язык, коль писать грамотно, да умеючи.
Прямо сейчас продавая Пых проекты заработал на дом и машину. И заказчики только просят ещё.
Проекты в какой сфере?
Продажи
Ну так индивидульные сайтики можно клепать в чём угодно, для прода же пых не подходит ни для бэкенда, ни для нормального фронтенда, вот такой вот франкенштейн. Рад, что у вас получается зарабатывать на пыхе деньги.
Есть такое дело что заказчику пофиг на каком языке у него результат ему главное чтобы работало и решало задачи, даже если он просто менеджер.
Ну если сайтик только для внутреннего пользования для десятка человек, и масштабирование не нужно в будущем, то да. Разные бывают сайтики.
а что с масштабируемостью не так? на пухе такие классы писать можно, прибавляя/убавляя что угодно сверху и снизу, что любую необходимую страничку можно рендерить с привязкой к основному инит. ну да, возможно, тяжеловато будет, выглядеть, но если мы берём коммерческий продукт - там же все равно надо динамически отслеживать сессию, баланс, корзину и тп
серьёзно, при выборе каждого товара обновлять всю страницу? точно там нигде аякс или жс не включен?
Единственный язык, в котором при обновлении редко что-то ломается из зависимостей. Вспоминаю ноду, дарт или питон. Особенно питон, у которого даже при обновлении минорки отваливается половина зависимых пакетов.
> Единственный язык, в котором при обновлении редко что-то ломаетсяНу вспомни переход от 5.3 к 5.4
Не надо такое вспоминать.
5.4 позиционировался как 6.0, которая так и не вышла.
Некоторые датасатанисты не указывают версии зависимостей в питоне. Вот где начинается веселуха.
Было:$title = ' PHP 8.5 Released ';
$slug = strtolower(
str_replace('.', '',
str_replace(' ', '-',
trim($title)
)
)
);Стало:
$title = ' PHP 8.5 Released ';
$slug = $title
|> trim(...)
|> (fn($str) => str_replace(' ', '-', $str))
|> (fn($str) => str_replace('.', '', $str))
|> strtolower(...);Мне одному кажется, что было лучше и читабельнее?
Я бы ещё понял, если бы стало так:
$title = ' PHP 8.5 Released ';
$slug = $title
|> trim(...)
|> str_replace(' ', '-', ...)
|> str_replace('.', '', ...)
|> strtolower(...);а эти лямбды, которые нужны всегда, когда у функции не единственный аргумент - жесть полная. Ещё и в скобках зачем-то, не осилили приоритеты в парсере-лексере?
> Мне одному кажется, что было лучше и читабельнее?Абсолютно верно. Более того в новом варианте как-бы перевернут порядок выполнения. Кажется что trim последняя операция.
> Кажется что trim последняя операция.сверху вниз читается ведь, почему последняя, первая ведь.
$output = $input
|> trim(...)
|> fn (string $string) => str_replace(' ', '-', $string)
|> fn (string $string) => str_replace(['.', '/', '…'], '', $string)
|> strtolower(...);
Она то конечно первая, но читать привычнее в глубь стека вызовов$output =
strtolower(...) <|
fn (string $string) => str_replace(['.', '/', '…'], '', $string) <|
$input
|> trim(...)
|>
|>
|> ;
...блин, дописать нормально не получилось.так вот, хотел сказать что удобнее писать как-то так:
$output =
<| strtolower(...)
<| fn (string $string) => str_replace(['.', '/', '…'], '', $string)
<| fn (string $string) => str_replace(' ', '-', $string)
<| trim(...)
<| $input;
> так вот, хотел сказать что удобнее писать как-то так:и чем тогда это отличается от этого?
f(g(h(l(x))))
тут просто избавились от ) скобок, а за место ( - это <|
пс: короче мракобесие
проходной релиз так-то. ждем true async.
Даже при наличии нативной асинхронности, пыху нужны нормальные типы данные при компиляции, не только в рантайме, с этим у пыха беда.
Этого никогда не будет, потому что это будет сильнейший удар по быстродействию в рантайме.
Как таковой, отдельной компиляции в пыхе нет.
Очень печально...
kphp к вашим услугам
У пыха из компиляции только JIT, всё остальное - трансляция.
Зачем это пыху? Есть куча других типизированных языков.
Это будет сложно сделать.В каком-нибудь JS изначально были коллбэки, условным Promisify проблема решается.
А в PHP всё синхронно. Даже если закрыть глаза на глобальное состояние (superglobals и тп), в конце концов это всё можно решить костылём, привязав globals к конкретному условному гринтреду, то что делать с условным $db->query(), как отличить promise от значения? Если расставлять везде await, в мусорку идет 99% написанного кода - не годится.
Можно придумать какой-то костыль, когда обычное обращение к Promise неявно делает await, а чтобы его оставить, надо написать какой-нибудь условный defer, но это явно будет крайне непросто реализовать
ты не в теме) https://externals.io/message/129300
Чувак пишет в том треде:Meanwhile, please cancel this vote. There is no rush.
If we get it right, this could be the most significant feature added to
PHP for 10 years or more. If we get it wrong, we might regret it for 20
years.То есть, там только обсуждение только, а сама асинхронность будет через несколько лет, а пыхеры массово начнут ей пользоваться ещё через N лет.
А вот и результаты голосования, лол:
А, просто ручками корутины делать. То есть весь существующий код на свалку.Для относительно standalone проектов я такое делал на ReactPHP, а до его появления ручками на pecl/ev. Ну, это было давно, когда nodejs и golang были в зачаточном состоянии. Сейчас не знаю зачем такое.
Вот "магию", о которой я говорил, было бы круто сделать. Но это действительно сложно
>В каком-нибудь JS изначально были коллбэки, условным Promisify проблема решается.Не надо нам поганого жопоскрипта, мы не хотим языка с цветными функциями.
Так в том и дело, что эти ваши корутины по факту ими и являются.Цветные функции можно было бы "замести под ковёр" - инвертировав логику, как я и говорил. Если возвращается promise, то без явно указанного defer сразу делаем автоматический await.
Причем поскольку эта "окраска" будет всегда инициирована внутренностями php (или расширений), в сам язык ее можно вообще не добавлять!
Сложно, понимаю
> Если расставлять везде await, в мусорку идет 99% написанного кода - не годится.Ну, как в питоне - asyncio уже был, а базу дёргать асинхронно было нечем. Со временем библиотеки подтянусиль, всё дописали, теперь есть.
Зочем? Модель пыха: одна задача = один процесс. Можно короутины на файберах налепить, если очень хочется - я себе например напилил обвязку и на файберах, и на генераторах, очень хорошо ворочается. Но в целом - если хочешь что-то сделать асинхронно - генери подзапрос или стартуй подпроцесс.
"Одна задача = один процесс" очень плохо масштабируется на I/O bound задачах, которые как бы типичны для веб-бэкенда. При достаточном количестве параллельных запросов добрая половина процессорного времени уходит банально на переключения контекста. Такое себе.На epoll based модели взлетели nginx и node.js (даже с уродливыми колбэками поначалу).
В принципе, когда всё, что может породить ожидание I/O completion, находится внутри языка (условно "языка", PHP это скорее платформа, если выкинуть все ext/* - не останется ничего, на чем можно написать что-то сложнее Hello World), вполне можно неявно возвращать некие Promise objects и неявно "ожидать" их разрешения при любом обращении к результату функции, если только явно не указали какой-нибудь defer. А глобальные переменные так же неявно утащить в контекст запроса.
> "Одна задача = один процесс" очень плохо масштабируется на I/O bound задачах, которые как бы типичны для веб-бэкенда.I/O-bound задачи - это жуткий corner case типа CDN. Т.е. полтора применения из тысяч.
И да, промисы только убьют логику, потому что вполне возможно обрабатывать результаты этого i/o completion по мере поступления, а не ожидая конкретного. По сути в условиях линейного кода - только колбеки.
В JS, блд, даже колбеки _синхронные_. Если не брать всякие навесы типа тредов над нодой.
В ядре процессора вообще всё синхронно. Внезапно.Когда код состоит из ожидания I/O completion чуть менее чем полностью, "кооперативная многозадачность" очень даже хорошо работает. nginx тому пример.
Внезапно блд нет. Причём настолько асинхронно, что приходится даже откат части операций делать (ага, читать про спекулятивное выполнение).
Да? И асинхронность всё ускоррит в 10 раз?
Не в 10, а в 2-3 раза точно.
Не верю.
Ну и не верь. Пиши бэкенд на супер скоростной сишичке, лол.
и не ускорит, а замедлит
по-моему разговор о том, что без рута, если вы какую-нить рутину с клиента запустите - обработку бд, парсер там - то будете ждать пока она не отработает, что определится скоростью соединения, криворукостью написанного и тпдинамически обновляемые блоки без перезагрузки страницы...
как вот это всё на пыхе написать, без жс и фреймворков?
На самом деле даже нативные треды толком не нужны - навешали бы хотя бы тредов и колбеков на асинхронное ожидание выполнения там, где большие интервалы ожидания, можно было бы сделать обвязочку и не торчать колом во время того же разрешения DNS. А пока приходится собственными силами клиент реализовывать, чтобы этого не происходило.
> ждем true asyncЗачем? Это не js какой-то там. В самом PHP асинхронность нафиг не нужна, её обеспечивает Apache (или что там сейчас модно).
вы удивитесь, но каждую отдельную сессию с запущенным скриптом вешает до его выполнения.
Интересно, а кому-то не хватает и без того довольно обширного синтаксиса/сахара? Ощущение что эти версии штампуются ради штамповки хоть что нибудь, но новая версия, и это не только php касается. Нафига все это надо, и кому, впрос. А сахар в больших кол-вах большой пользы не приносит и даже в программировании.
Они хотят быть похожими на джаву/спринг из-за их солидности, однако это всё не нужно, и смотрится смешно.
это Larry Garfield говнякает. этот персонаж специализируется на добавлении всякого неудобоваримого сахара.
https://externals.io/message/128473
Напиши ему, чтобы он не добавлял всякую шляпу в пых.
1995: PHP is dead, learn ColdFusion
2002: PHP is dead, learn ASP .net
2003: PHP is dead, learn Django
2004: PHP is dead, learn Ruby on Rails
2010: PHP is dead, learn Flask
2011: PHP is dead, learn AngularJS
2016: PHP is dead, learn Next.js
2022: okay this is awkward
ASP с си шарпом в нормальных компаниях до сих пор используются, и намного круче пыха.
Интересно - ЯП сравнивается с фреймворками.Это как }|{0пу с пальцем сравнивать.
А ничего что PHP - фреймворк с самого рождения? То что там свой язык используется вообще не роляет, ибо ни для чего больше он не пригоден.
> ни для чего больше он не пригоден.удивись:
<?php
$ffi = FFI::cdef('
void gtk_init(int*, char***);
void* gtk_window_new(int);
void gtk_window_set_title(void*, char *);
void gtk_widget_show_all(void*);
void gtk_main();
void gtk_main_quit();
unsigned int g_signal_connect_data(void*, char*, void (*)(void*, void*), void*, void (*)(void*), unsigned int);
', 'libgtk-3.so.0');
$ffi->gtk_init(null, null);
$win = $ffi->gtk_window_new(0);
$ffi->gtk_window_set_title($win, 'PHP ' .PHP_VERSION);
$ffi->g_signal_connect_data($win, 'destroy', fn() => $ffi->gtk_main_quit(), null, null, 0);
$ffi->gtk_widget_show_all($win);
$ffi->gtk_main();
Таков удел фронтэнда. Поэтому многие вообще не хотят в него заходить, даже в виде фулстак. Говорю в том числе и из личного опыта.
Вообще-то, и в бэкенде тоже не одним язычком всё ограничивается, монолиты на же джаве со спрингом и си шарпом с нэт уже не так популярны, как лет 15 назад. Программирование - штука такая, всю жизнь надо учить что-то новое.
Обновления и ломка языка надоели. php устарел. Нормальные патсаны на питоне или на ноде сайте делают. Я на статические перешёл.
>> Я на статические перешёл.Енто на какой?
Astro.
Не то что устарел, просто появились конкуренты с какой ни какой, но строгой типизацией. Да и отсуствие нативной асинхронности делает выбор не в пользу пыха. Вот два ключевых огромных недостатка.
Какие конкуренты? Популярность PHP 73%. Ближайший конкурент Ruby - 6%.
Популярность среди хомячков, которым нужна просто страничка в интернетике. Абсолютно точно, что пых популярен, но это всё дремучее легаси и примитивщина, на пыхе ничего сложнее CRUD не делают, бложики всякие и админки - да, это максимум пыха. Для современного нагруженного веба, где всё поделено на фронтенд и бэкенд, а бэкенд поделен на монолиты и микросервисы, пых вообще не подходит.
>> Для современного нагруженного веба, где всё поделено на фронтенд и бэкенд, а бэкенд поделен на монолиты и микросервисыА все равно нихорена не работает и даже становится еще хуже. Сейчас дошло дело до того что чтобы отобразить элементарную страницу с текстом на кой-то хрен грузится 100500 json запросов, и столько же js кода который вешает страницу наглухо почти наминуту, а это негативно влияет на посетителей. Все эти навороты в основном это огалделая реклама и допродажа сопутки, плюс аналитика всякая ну вот это вот все... А пользователь всего лишь текст хотел почитать.
Для решения этой проблемы давно придуман graphql.
Или статические генераторы, но надо сказать они не для всего вэба.
Для решения этой проблемы придумали html
При этом пхп сформировал страницу и показал пользователю и все. Все что и требуется от бэка. Так что пхп он хороший ;)
Ага, вот только он начинает пыхтеть от запросов, когда сайтик становится более популярным.
Именно, а они сахаром занимаются...
Несогласен, мы на нем реализовали ерп систему в 2023 используя симфу, самый ближайший родственник по возможностям это джава со спрингом, ни у кого больше нет полноценных фреймворков из-за чего приходится жонглировать 100500 пакетами и писать кучу оберток чтоб все работало, го мы оставили только для узкоспециализированных потребностей, типа аналитических отчётов, использовать дж и питон на беке упаси боже
Ну это вы пишите про внутрикорпоративный сайтик, где нагрузка и не важна, а бизнес логика может быть сколько угодно обширной. А где есть нагрузка, там symfony не прокатит. И в чём проблема с js на бэке? Она получше пыха то точно. Да, батареек как в spring в js фреймворках нет (из-за позднего появления ноды), но на бэке это и не нужно. На бэке куда важнее стабильность ORM и работа с очередями, которую нода предоставляет. Уязвимости? В компостере тоже полно уязвимостей, просто они вообще не раздуваются на опеннете, как в случае с npm.
Найти джс бекендера не для груда анриал, а те что есть приходят из фронта где вообще ничего не знают про архитектуру и паттерны. Лично для нас уязвимости не первый фактор, так как система в закрытом контуре
> А где есть нагрузка...... там пилим нативные модули, оставляя минимум ПХП кода.
На сишке? Хороший юмор.
А что смешного? Зачем тонны кода бизнес-логики держать на скриптовом ЯП, серверную обогревать?
> Популярность среди хомячков, которым нужна просто страничка в интернетике. Абсолютно точно, что пых популярен, но это всё дремучее легаси и примитивщина, на пыхе ничего сложнее CRUD не делают, бложики всякие и админки - да, это максимум пыха.Бабушке моей расскажешь.
А ты пока помучайся с тормознутыми кедо-гномами.
На приведенной вами картинке очень размытый скрин подобия рабочего стола, где ничего не разобрать. Вы что сказать-то хотели?
> На приведенной вами картинке очень размытый скрин подобия рабочего стола, где ничего
> не разобрать. Вы что сказать-то хотели?Хотел сказать что вы ниасилили включить GIF-анимацию.
На питоне....сайт. Ясно-понятно.
мертвый язык пытается бороться за жизнь самоуложнением на ровном месте
вместо того чтобы наоборот вводить strict режим в котором порезать к чертям всякие левые глупые возможности, они наоборот накручивают какой то фигни которая окончательно сделает код не читаемым
Моя версия что нечитаемость для того чтобы стряхнуть с хвоста людей-программистов, в пользу ИИ
пайпы куда хуже выглядят, чем аналоги.
Ох, вовремя ушел из этого стека.PHP сейчас тьма альтернатив получше. Так же java+kotlin, раз пыха хочет стать интерпретируемой явой.
Сайт на джаве, он медленнее php не будет?
И прожорливее, там же вирт машина вроде ж?
Прожорливее на старте.
Нет, да и на джаве сейчас в основном только rest api (бэкенд) клепают, а сервлеты давно в прошлом. Да, джава на старте сначала отжирает ОЗУ побольше, однако чем дольше JWM запущена, тем всё меньше ОЗУ она будет потреблять.
> чем дольше JWM запущена, тем всё меньше ОЗУ она будет потреблять.Это как ? Утечка памяти в обратную сторону ?
Есть надежда- что при достаточном времени работы она будет использовать 0 Байт в памяти, а потом перейдёт на отрицательные значения ?
Нет, особенности работы GC в JWM.
Пока что из особенностей я заметил только то, что оно как отожрало пару гигабайт на минимальное приложение на хибернейте, так и продолжает отжирать, ещё и увеличиваясь.
> Ох, вовремя ушел из этого стека.
> PHP сейчас тьма альтернатив получше. Так же java+kotlin, раз пыха хочет стать
> интерпретируемой явой.Какую проблему решают эти альтернативы, что не может решить PHP, который уже существует вкупе с толпами программистов что его знают, и инфраструктуры что его поддерживает?
Пых не имеет строгой типизации, и именно поэтому его выбрасывают отовсюду, чистый JS тоже уже нигде не нужен, а сейчас строго типизированные язычки на коне, потому что типизация повышает качество результата, даже без всякого тестирования.
> Пых не имеет строгой типизации, и именно поэтому его выбрасывают отовсюду, чистый
> JS тоже уже нигде не нужен, а сейчас строго типизированные язычки
> на коне, потому что типизация повышает качество результата, даже без всякого
> тестирования.Какое качество, какого результата?
Всем плевать на эти подкапотные телодвижения. Людям нужен готовый программный продукт, например такой как Wordpress и сайты на нем.
Не, ну ты конечно можешь написать несколько крупных и известных (!!!) проектов на язычках на коне, даже интересно.
Всё уже обжовано и пережовано тысячу раз, нет смысла начинать заново, просто прийми это, что пых безтиповая шляпа, которую не берут в нормальные компании. На коне сейчас golang с микросервисами, golang просто предназначен для сетевых приложений, а пых - язычок для всяких админок и вордпресов, это очевидно всем. Пых плохо подходит для микросервисного общения. Вот так вот, пых - нескучный шаблонизатор, хотя с ларавелем он может чуть больше, но возможности его масштабирования - никакие, в то время как го легко держит 20k RPS, пых захлёбывается на 1к RPS, вот и всё.
> в то время как го легко держит 20k RPS, пых захлёбывается на 1к RPSдада, нуну... можно сделать обратный тест и совать его всем
> Пых плохо подходит для микросервисного общения
тю, и в каком языке есть такое многообразие библиотек поддержки интеграционных протоколов?
Go супер-классный, но несопоставим с более полными ООП-языками по возможностям описания бизнес-логики + достижения быстрых бизнес-результатов
> Всё уже обжовано и пережовано тысячу раз, нет смысла начинать заново, просто
> прийми это, что пых безтиповая шляпа, которую не берут в нормальные
> компании. На коне сейчас golang с микросервисами, golang просто предназначен для
> сетевых приложений, а пых - язычок для всяких админок и вордпресов,
> это очевидно всем. Пых плохо подходит для микросервисного общения. Вот так
> вот, пых - нескучный шаблонизатор, хотя с ларавелем он может чуть
> больше, но возможности его масштабирования - никакие, в то время как
> го легко держит 20k RPS, пых захлёбывается на 1к RPS, вот
> и всё.Это ты так пошутил?
1. PHP это язык для препроцессной разметки вебсайтов. Он таким создавался, как и другие языки создавались для своих задач. Если ты забиваешь гвозди микроскопом - ССЗБ;
2. PHP исторически работает как интерпретируемый ЯП, получающий информацию от обработчика и отдающий ее обработчику. В этой парадигме у тебя любой ЯП будет тормозить, потому что межпроцессное общение становится бутылочным горлышком, а не скорость языка. Хочешь скорость? Без проблем - пишешь на пыхе свой обработчик, парсишь 80-й или 443-й порт, сам распихиваешь соединения, благо мультитредов там с вагон и тележку, и получаешь свои 20k RPS;
3. Микросервисы - это концепция для мокак, ниасиливших в нормальную архитектуру целостного приложения, в котором вопросы про 20k RPS вообще не стоят;
4. Я уже выкладывал выше. Выложу еще раз: https://ibb.co/Zp0HcSjT
На скрине например полноценный файловый менеджер, написанный на PHP. Запущенный в DE, написанной на PHP. С многозадачностью, панелями, доками, треями, приложениями и тд итп.Разрешаю показать пример того же самого на твоей Go'шечке, масштабизатор =)
С вами даже спорить скучно. Время расставит все по местам.> 3. Микросервисы - это концепция для мокак, ниасиливших в нормальную архитектуру целостного приложения, в котором вопросы про 20k RPS вообще не стоят;
Посмеялся, когда представил у Сбера монолит на PHP. Ну или у Гугла. Ведь в комментариях анон написал что PHP с нормальной архитектурой держит большь rps чем микросервисы на golang.
> С вами даже спорить скучно. Время расставит все по местам.Детская аргументация.
Спрошу по-взрослому: сколько времени вам нужно, чтобы все расставить по местам?
А то время расставляет все по местам с 1995 года, и все никак не расставит.
> Посмеялся, когда представил у Сбера монолит на PHP. Ну или у Гугла. Ведь в комментариях анон написал что PHP с нормальной архитектурой держит большь rps чем микросервисы на golang.
Какой именно монолит?
Их в Сбере много.
> 1. PHP это язык для препроцессной разметки вебсайтов.PHP — Personal Home Page. А если даже и preprocessor, то HTML потому что web site переводится как паутинный узел.
> Пых не имеет строгой типизации, и именно поэтому его выбрасывают отовсюду, чистый
> JS тоже уже нигде не нужен, а сейчас строго типизированные язычки
> на коне, потому что типизация повышает качество результата, даже без всякого
> тестирования.Я не спрашивал что пых имеет, а чего не имеет. Я спросил простой вопрос - какую проблему решают альтернативы? Окей, какие проблемы решает строгая типизация?
Сразу тебе отвечу: никакую проблему не решает ни то, ни другое.
Строгая типизация - отголосок из прошлого, где была вечная нехватка памяти, и ОС нужно было знать, сколько именно памяти нужно программе.
Потом, в годах этак 80хх, появились процы, умеющие в плоскую модель памяти, страничную адресацию и защищенный режим, и памятью стало можно управлять гибко.
Если у тебя содержимое переменной - *char, или же "строка", если по-русски, то ты by design не будешь с ней производить арифметические операции.
Если переменная должна содержать числа, то ты как адекватный программист - проверишь, является ли переменная числом, или выберешь оттуда числа, или сюрприз сюрприз, приведешь ее к строгому типу при помощи $var = (int)$var; А еще проверишь больше ли она нуля, прежде чем на нее делить. И многое многое другое.
- - -
Что ты получишь используя строгую типизацию - так это переусложнение кода, вынужденного быть разбитым на блоки, особенно если твоя программа использует чьи-то API, а у них свои типы. Вот например запрос к методу DBUS может тебе вернуть char, int, uint, array of char, и многое многое другое. Поэтому в твоих ЯП "на конях", простой по идее алгоритм, выливается в простыню кода, львиная доля которого, не алгоритм исполняет, а борется с твоей же строгой типизацией. Иными словами твоя программа еще не знает, какую переменную получит, а уже должна ее объявить - это бред.
В ЯП с динамической типизацией, ты можешь просто отдать значение в переменную, потом проверить его, и в зависимости от того что там - поступить так или по-другому.
<?php
function test ($var) {
if (is_numeric($var)) {return $var+1;}
if (is_float($var)) {return $var*0.75;}
if (is_string($var)) {return "Переменная: $var";}
}Юзкейс я тебе уже указал выше - к примеру DBUS.
А теперь давай аналогичный пример функции на своем ЯП со строгой типизацией, с переменной которая может быть такая, а может и другая - зависит от третьей стороны.
Ой, да пишите на php свои сервисы дальше. Нам больше работы будет.
Меня например, на текущую работу взяли чтоб распилить php монолит на микросервисы на golang, так как масштабировать и поддерживать дорого.
Распилил, бизнес доволен. Проблем не стало.
> Ой, да пишите на php свои сервисы дальше. Нам больше работы будет.
> Меня например, на текущую работу взяли чтоб распилить php монолит на микросервисы
> на golang, так как масштабировать и поддерживать дорого.
> Распилил, бизнес доволен. Проблем не стало.
> Ой, да пишите на php свои сервисы дальше. Нам больше работы будет.Слив защитан.
Микросервисы - это вообще не панацея, и применять их можно в основном там, где latency значения не имеет.
Кстати никто не мешает распилить монолит на PHP на внезапно микросервисы на PHP.
> Строгая типизация - отголосок из прошлого, где была вечная нехватка памяти, и
> ОС нужно было знать, сколько именно памяти нужно программе.А сейчас–то конечно же хватает когда просмотрщик HTML запросто откусывает гигабайт и когда очень много популярных программ это HTML–документы завернутые в Google Chrome и прикидываюшиеся программами.
>[оверквотинг удален]
> function test ($var) {
> if (is_numeric($var)) {return $var+1;}
> if (is_float($var)) {return $var*0.75;}
> if (is_string($var)) {return "Переменная: $var";}
> }
>
То есть шыло на мыло.
Похапе принципиально не может разделять данные между запросами не через какую-нибудь ipc жопу, типа редиса, ставить запросы в очередь итп. Похапешники ничего такого писать в принципе не умеют. Родовая травма из убогой модели выполнения с времён cgi-bin, когда слишком сильно упоролись по юникс-вею, заставляет придерживать костылями n воркеров наготове и ни дай бог они начнут зависать.
Вот я реально не понимаю, на хрена они это делают.
В примерах с |> вторая запись хотя бы читабельно выглядит.
И там ещё можно $temp сразу на $output заменить, убрав лишнюю переменную.
Ещё эти значимые безумные конструкции в комментариях (я про аттрибуты) и прочая бурда.
Лучше бы ей богу занялись тремя реально нужными вещами:
1) Перегрузка операторов (блин, ну вот реально - сахара будет больше чем во всех вот этих потугах)
2) Множественное наследование (Trait в текущем виде - это убожество, из-за которого приходится костылить цепочки классов)
3) Возможность обрезки строк без переаллокации. Куча производительности теряется именно на substr. Понятно что там CoW, и придётся всё равно создавать минимальный объект подстроки, но блд...
(там на самом деле не только CoW, там ещё поисковый хеш и немножко прочей мути - но кто мешает скопировать только метаданные, не копируя всё целиком, дальше пусть сборщик мусора решает, когда убить оригинал).
ну учитывая что в пыхе, если мне не изменяет память,$result = $date + strtotime($value)
не прокатывает, нужно лишнюю строчку прописывать каждый раз - выглядит вообще бомбой
* $result = $timestamp + strtotime($value)ну и, само собой, таймштамп типизирован, а то налетят ща
Почему не прокатывает-то? Всё нормально там, хоть $result = $result + whatever, хоть $result = $whatever + fn($result).
Даже больше скажу, в JIT есть оптимизации под $result = <expr $result>, оригинал при этом может не копироваться.
А, вот, пока обсуждали, вспомнил (4).4. Инлайны (inline) - тоже нужны как воздух, стоимость вызовов в PHP просто безумная.