Представлен первый бета-выпуск новой ветки языка программирования PHP 8. Релиз намечен на 26 ноября. Одновременно сформированы корректирующие выпуски PHP 7.4.9, 7.3.21 и...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53502
Нужно больше непонятных исключений и странного синтаксического сахара
> Изменена логика соединения строк.и почаще менять приоритеты операторов
Есть такая привычка, называется "лишние скобки между разнородными операциями не помешают".
Спасает железно.
Правильно, нафик приоритеты придумали (в си их неск-ко десятков) - есть же скобки!
Правильно! Вон в Lisp нет ни каких приоритетов, и ни кто не жалуется.
(ведь ((это ((так интересно) и (умилительно)) считать) скобки))...
(
Нефиг (
макароны лепить, (
либо (на строки бей),
либо (используй временные переменные)
)
)
Гораздо умилительнее видеть штук 10-15 разных операторов в произвольном порядке, и далее пытаться вслепую сосчитать, какой из них первый по приоритету.
Абсолютно. Иногда берёшь тот или иной код, и без бутылки не разберёшься, чего там напихали в длиннющее выражение. Скобки этот процесс упрощают, и выражения становятся читабельными даже для новичков. Которые почему-то чаще остальных любят зубодробительные выражения, завязанные на приоритеты. А потом сиди разбирай, чего они там накорябали.
Ну здесь явно дело не в скобках, а в том что по рукам надо бить. Новичкам еще чаще.
> Добавлена функция fdiv(), выполняющая операцию деления без вывода ошибкиЗачем?
написано же - чтобы не было вывода ошибки.
А NaN можешь обработать и сам.
Затем, что иногда нужно получить не warning (или ошибку, которая планируется в будущем), а +-INF или NaN.
когда такое бывает?
Когда нужно записать результат и использовать дальше.
С NaN много не наделаешь, а вот +INF/-INF - ценный мех, его можно ещё поумножать-поскладывать.
И даже как-то жалко, конечно, что в современных языках понятие порядка INF почти не прижилось, приходится костылить, где надо.
Затем, что не все настолько упоротые, чтобы из-за какого-то очень частного случая в лице деления на ноль тащить ещё и всевозможные исключения, серьезно усложняя структуру и логику работы кода, тогда как можно просто проверить соответствие результата приемлемым диапазонам и... всё.Всё-таки, обычно в пыхе и прочих не принято кидать исключения на любой чих - это не жаба и её подобия.
Исключения в пыхе выдаются на случай чего-то действительно серьезного.
Это же очевидно, чтобы делить на ноль!
Потому что забыли что у них есть @
Не понимаю, почему его называют простым для обучения. Редкостная хрень, разжижающая мозги.
А чем тогда пользоваться? На голом ассемблере динамические сайты верстать?
> А чем тогда пользоваться? На голом ассемблере динамические сайты верстать?А вариантов только два: пыха и ассемблер?
Почему вместо PHP не взять тот же Питон?
Ну ладно, Питон иногда тормозной, ну JavaScript?
Ну ладно, JavaScript иногда странный, ну TypeScript?
Ну ладно, TypeScript иногда замороченный, ну Kotlin?
Ну ладно, Kotlin иногда тяжеловесный, ну Go?
Ну ладно, Go иногда невыразительный, ну Rust?
Ну ладно, Rust иногда без нужных либ, ну Java?
Ну ладно, Java иногда навевает тоску, ну Scala?
Ну ладно, Scala иногда слишком сложная, ну Haskell?Ну ладно, Haskell иногда тоже слишком сложный. Пожалуй, возьмём PHP, работа стоит!
(c) https://habr.com/ru/company/skyeng/blog/506704/#comment_2174...
На финалочку Erlang
Дед,за 30 лет существования Эрланга на нем было 30 вакансий, оно тебе надо на паперти стоять с протянутой рукой?
Много крутого дорогого и распределенного софта пишут на erlang, включая и банковские процессинг системы и для телевидения.
Упаси Господь Эрланг от популярности Пыха!
а потом удивляются почему для языка нет вакансий. Тут либо eternal september, либо постепенное забвение, мой дорогой элитист
Не может забыть тот, кто никогда не знал. А кто про Эрланг знает - тот не забудет, хотя бы потому, что Эрланг создавался для определённого круга задач, с которыми успешно справляется и конкурентов на своей полянке не имеет (когда писатели фреймворков тужились и угаживались с проблемой 10к соединений, в Эрланге об этом даже думать не нужно было, всё делалось штатными средствами EVM).
Ахахаха. Логика железная: если в стране всего один президент, значит это никому не нужная профессия.
Возьмите добрый старый Perl и не страдайте. :P
кроме асма и пыха других языков - нема?
Ruby, Python, Java, Nodejs и Golang
Java немножно мимо, а на остальном разве что хеллоуворлды лепить.
Ну даже если принять эту чушь за правду, хелловорлды - это всё что PHP умеет, так что перечисленные языки не хуже.
ну я посмотрю, как быстро ты сможешь раскатать админку с бизнес логикой на nodejs, golang, ruby, python. в пыхе это делается установкой laravel, symfony или yii и все.
Rails, Sinatra, Merb, Django, Flask... это так, навскидку, для js даже перечислять не буду там миллион фреймворков на любой цвет и вкус.И пара десятков табличек с несколькими вьюшками и контроллерами вообще не тянет на какую-то сложную бизнеслогику
Merb мертв, детка, Merb мертв.
Впервые слышу о нём. Раби вообще мертво, немного ожило за счёт хайпа рол, но потом питон подтянули и он стал лишним.
Да-да, конечно.
абсолютно так же. только без свистоплясток с нестрогими типами
> laravel initial release: June 2011
> symfony initial release: 22 October 2005
> yii: In October 2006, after ten months of development, the first alpha version of Yii was released, followed by the formal 1.00 release in December 2008.В это время…
Ruby on Rails initial release: August 2004
Будто вчера было, помню как рассуждал на тему этих сырых поделок которые убожеству-пхп слабо помогут. Собственно, менее убогим пхп не стал, а вот битрикс удивил, но это в первую очередь заслуга интеграции с 1с, как мне кажется.
PHP-то может и не стал, а вот где ваши проникновенные руби с хрустом и прочие свистоперделки?
В общем-то, как де факто их не было, так и нет. Только названия.
битрикс - кусок гoвна который оптимизирован под чсв разработчиков
> битрикс - кусок гoвна который оптимизирован под чсв разработчиковА кто спорит? Я просто застал время, когда он был тормозным глючным куском говна буквально. Что-то из него да и слепили с тех пор.
И с 2004 оно так и не взлетело.
Такие дела.
Расскажи это хотя бы FreePBX.
Эпичненький такой хеллоуворлд.
Хотя говнокода там конечно просто воз.
Пых очень многое умеет, но нынче на «чистом» уже почти никто не разрабатывает - применяются всевозможные фреймворки и модули
Это просто от неосиляторства.
На самом деле без фреймворков всё делается не менее просто, и главное - не изобретая велосипедов, но для этого надо немного уметь думать.
> Это просто от неосиляторства.
> На самом деле без фреймворков всё делается не менее просто, и главное
> - не изобретая велосипедов, но для этого надо немного уметь думать."Неосиляторства" чего ?
Вначале изучают сам пых( который очень прост ), потом - библиотеки, модули и фреймворки( что несравненно сложнее и дольше ).
Ну-ну, а потом - очередной самопальный фреймворк от васи пупкина с кучей дыр, околонулевым функционалов и ужасной архитектурой. Таких "гениев" с*ными тряпками из разработки гонят.То ли дело фреймворки - там и норм роутинг и шаблоны и RBAC и ORM'ы без тех дыр, которые скорее всего появятся при самопальной реализации функционала. И, самое главное, есть стандартные подходы к решению тех или иных проблем или доработок.
После "который очень прост" смысла что-то разбирать дальше нет.
Он далеко не прост, и все эти "фреймворки" - попытка хоть как-то упростить жизнь начинающим.
А в итоге рождаются монстры.
[это не значит, что фреймворки - зло, но они зло там, где они не нужны]
> После "который очень прост" смысла что-то разбирать дальше нет.
> Он далеко не прост, и все эти "фреймворки" - попытка хоть как-то
> упростить жизнь начинающим.
> А в итоге рождаются монстры.На фоне тех знаний и умений, которые требуются норм пых-разработчику, изучение именно пыха как языка - одна из самых простых задач, поскольку на чистом пыхе без фреймворков итп сейчас практически ничего нормального не делается.
Наоборот, более-менее нормальные ГОРАЗДО сложнее самого языка и нередко требуют внимания не только в доки, но и в сам код фреймворков.
> и RBAC и ORMНе переживайте, наши области разработки слишком слабо пересекаются.
Все эти кэнди хороши, пока у тебя не появляется сложная задача и реальная нагрузка.
Дальше начинается костылинг поверх и в обход любимого фреймворка, с причитающимися бубном, песнями и плясками. Лишь бы не ложилось.
Это вопрос только опыта.
>> и RBAC и ORM
> Не переживайте, наши области разработки слишком слабо пересекаются.
> Все эти кэнди хороши, пока у тебя не появляется сложная задача и
> реальная нагрузка.
> Дальше начинается костылинг поверх и в обход любимого фреймворка, с причитающимися бубном,
> песнями и плясками. Лишь бы не ложилось.
> Это вопрос только опыта.Какие кэнди ?
Не переживаю, ведь я уже некоторое время практически не имею дел с пыхом :)
Но неплохо припоминаю те времена, когда еще "имел".
И когда кто-то говорит про "очень сложный язык" и про "очень простые фреймворки для неосиляторов" - это говорит лишь о том, что ничего кроме хеллоуворда подобные говоруны на пыхе не делали, ведь тут, в случае действительно серьезных и функциональных фреймворков ситуация ровно обратная."Реальная нагрузка" - это очень растяжимое понятие.
Особенно, в нынешнее время, когда и оперативка и быстрые жесткие диски( SSD ) и неплохие процы стоят вполне умеренных средств.
Особенно, когда всевозможных питомников подобные глупости в принципе не беспокоят.Ну а костылинг - он всегда начинается, если реализация не соответствует задаче.. или задача "внезапно" стало ощутимо сложнее, чем предполагалось изначально.
Надо передать разработчикам докера, талоса, кубернетиса и ещё десятку годных тулз, что на го только хелло-ворлды клепать))
Тссс. Это тулзы для запуска хеллоуворлдов.
Не, ну с большим штатом и на го можно написать что-нибудь стоящее. Разве что вот пример кубернетеса показывает, что шаг влево, шаг вправо — и надо делать костыли над слабой системой типов, ограниченными возможностями языка и остальными проблемами. Всё же неспроста там гигантский пласт кода занимается тем что конвертирует одни типы в другие, как-то их сериализует и десериализует, держится на соплях и тестах, и работает за счёт черной магии и неочевидных сайд-эффектов
И вот всё у них так, да.
Какой язык по-вашему больше подходит для проектов уровня кубернетес?
C++/C#
Вот конкретно это я бы как раз оставил и не трогал.
Язычки стоят проектика.
Щито-щито? Большой штат?... Слабая система типов?.... Надо делать костыли?...Рука-лицо..
Вообще слабо понятно, откуда это взялось - видимо кто-то из хейтеров толкнул.
Это породило кучу недопрограммистов, сформировавших впечатление о себе.Уже с версии 4 язык был гораздо сложнее, чем его считали. А с появлением нормального ООП в 5 пришёл к уровню "классических" языков по сложности. Умножая это на нестрогую типизацию и модель "одна задача - один процесс" получаем даже несколько более высокий порог вхождения, первое требует аккуратности, второе - продуманности.
вам же ясно написали, не?
> Не понимаю, почему его называют простым для обучения. Редкостная хрень, разжижающая мозги.про мозги по-моему всё ясно сказано.
это можно сказать про любой язык программирования :D
это можно сказать про любой язык
Простым для обучения он был лет 15 назад.
Безссмысленный мажорный релиз.
Golang умеет в юникод со своего основания.
golang - Появился в: 10 ноября 2009
php - Появился в: 8 июня 1995
к логопеду, животное (с)
> поддержка именованных аргументов функций - дайте два, элегантное решение проблемы с порядком операндов, где нужно конечно, лепить везде не нужно
> ?-> - заверните, цепочки вызовов с возможностью отлупа становятся реально удобнымиВ целом развитие идёт туда, куда нужно. JIT тоже хорош, уже тестирую альфу - эффект на тяжёлых задачах по обработке тарификационных и маршрутных данных (телефония) заметен сразу.
Сразу становится заметно что изначально не тот язык выбрали?
Как раз таки наоборот, становится понятно, что выбрали то. Теперь код получится ещё упростить.
Улучшение производительности на ровном месте тоже не помешает.
Можно было взять жабу, но там свои тараканы.
> Сразу становится заметно что изначально не тот язык выбрали?и буквы не те, и со знаками препинания надо что-то делать.
маршрутизация и тарификация на php?!? вырезать избушку из кругляка консервным ножом тоже можно
Вот этот вот ступор в глазах - он всегда улыбает :)
Тем временем PHP более чем удобный инструмент для надёжной обработки фиговой тучи данных.
так то если простенький бэк нужно накатать то да, можно поюзать 7ку. А вообще, языки где не нужно заботится о типах данных, об освобождении ресурсов, т.е. там где программист не контролирует хранение данных в ОЗУ, не оптимизирует обработку этих данных, все это деградируют программиста. В модных языках так.
Для низкоуровневых оптимизаций в PHP есть возможность подключать специфичные модули на C.
JIT был создан как раз для помощи долгоживущих с "утечками памяти PHP".
https://habr.com/ru/company/badoo/blog/434272/
https://roadrunner.dev/
все ровно, годится только для быстрых набросков бэка, либо если запросов совсем чутка будет.
а так:
>>PHP-инженеры годами искали способы решения этой проблемы, использовали продуманные методики «ленивой» >>загрузки, микрофреймворки, оптимизированные библиотеки, кеш и т. д. Но в конечном итоге всё равно >>приходится сбрасывать всё приложение и начинать сначала, опять и опять.на нормальном языке это вовсе даже не проблема. Ставим Nginx впереди, он отдает статику + перенаправляет на бэки написанные на норм. ЯП, которые крутятся постоянно, слушают впередистоящий nginx, держат конекты с БД, другую нужную от запроса к запросу инфу. Ситаю такой подход единственным адекватным в задачах с болшим кол.вом запросов.
>> диагностика утечек памяти доводит до бешенства, а использовать отладку по F5 уже нельзя
да потому что невнимательность. Если изначально приучать себя к окуратности то случайные выстрелы в ногу сводятся к нулю.
>>подход: построить взаимодействие между процессами через сокеты/конвейеры. Этот подход за последние >>десятилетия доказал свою надёжность
эфективнее использовать втроенный js , например QTScriptEngine. тяжелые расчеты выносим в классы на С++, динамический пользуемся из js, создаем объект на базе этих классов, вызываем методы, пишем/читаем данные.
На самоме деле это хорошо что люди начали осознавать, что скриптовые языки в связке с компилируемыми дают весьма интересные результаты.
> приходится сбрасывать всё приложение и начинать сначала, опять и опять.
> на нормальном языке это вовсе даже не проблемаЭто не проблема на нормальных мозгах. Просто народ пытается перелезть на пых с классики, и пишет как под классику, тащит всё-всё-всё в память, чтобы отдать 512 байт ответа. Когда там совершенно другая модель работы. Которая имеет свои несомненные преимущества - если что-то падает, то падает один запрос, а не всё приложение.
> окуратности
> эфективнееОткуда ж вы такие берётесь…
но опять же, основной посл )
класическому покемону лилеющий модные языки, реализовать чтото типа roadrunner попросту нереально.
мышление у таких покемонов совсем не то, а это все результат современного подхода мира IT в плане упрощения ЯП, модных так сказать штучек. Молодым программистам самим реализовать аналогичный подход уже весьма тяжело. Их мышление сводится к иному взгляду на реализацию. Только создание контента. Рюшечки, пиченьки, баньтики,, как девочки.
Вы перепутали "нереально" с "не нужно".
Это опять загоны тех, кто так и не смог перестроиться на иную модель работы.
приведите в порядок уже стандартную библиотеку, если уже собрались что-то ломать.
Что не так со стандартной библиотекой? :) Живее всех живых.
В тех же хипстерских репозитарчиках API каждой второй либы каждые полтора релиза ломается - никто не ноет.
отсутствие консистентности
Это результат поступательного развития. Почему сложно изменить, думаю, понимаешь.
Вопрос с порядком аргументов в 8 решили радикально, конечно :D
Ну и как по мне, так лучше лёгкие недочёты по именованию, чем каждый релиз ломающийся API c необходимостью кардинально перепахивать код (питонисты на этом месте поперхнулись).
Да и ничего особо не сломали, тaщемта. Вопрос скорее как писалось.
Мы на тестах пары здоровенных inhouse аппликух ничего нового не увидели.
Они все сломали, можно и обратную совместимость было удолить
Что именно то сломали?
АААА ВСЁ СЛОМАЛОС!
Юникод так и не завезли?
mbstring давно завезен
Так это для аутистов как, чтобы время тратили.
Господа пыхеры, а вы со всеми функциями языка без справочника работаете?
Просто я когда (Будем честными) говнокодил на пыхе это для меня было проблемой.
Ни один программист ни одного языка не пишет код не имея справочника стандартной либы под рукой.
Со многими.
Но в современном мире без справочника работать, когда справочник просто в соседнем окошке на экране (или вообще на соседнем экране) - это что-то странное.
Очень жаль, что не добавили асинхронности... Workerman, Swoole т.д. - всё равно костыли. Хотя, ну, и ладно: есть же Node.js, Go, змей.
В смысле не добавили асинхронности?
Генерируете подзапрос, и имеете столько асинхронности, сколько вам нужно.
Или опять нужны фреймворки?
Интересно, когда кончатся любители пытаться втащить ежа (single process / task queueing) в ужа (task queueing / per-task processes).
Сам с собой разговариваешь? Хмм...
на internal структурах вроде как небольшие подвижки есть, но да, глобальная асинхронность как-то заглохла. было уже несколько реализаций async/away, fiber. но что-то не договорились разработчики.
>Изменена логика соединения строк..изда котенку...
В итоге, хороший язык получился. Его бы от легаси почистить и на юникод перевести, но судя по PHP 6 - такое его разработчикам не под силу.Но главная проблема PHP - его инфраструктура.
PhpStorm - глючное говно. Часть нужных библиотек для PHP - просто корявые и плохо-документированные биндинги к сишным либам. А другая часть написана неадекватными людьми, которые пытаются втюхать пользователям своё видение PHP со своими особенными DI, автолоадингом и разрешённым набором библиотек.
полная чепушня) как раз инфрастуктура php - одно из его главных преимуществ.
А теперь изучите всерьёз инфраструктуру, сопровождающую типичные проекты на Java/.Net/Python/C++ и сравните.Действительно хороших IDE под PHP попросту нет. Фреймворки типа laravel/yii/etc. — похожи друг на друга как родные братья, с примерно одинаковыми сильными и слабыми сторонами. Экосистема откровенно заточена на веб-сервисы, свежая кровь почти не поступает.
У PHP есть свои козыри. Но инфраструктура разработки к ним явно не относится — в лучшем случае, по отдельным моментам, на уровне прочих, но не более.
> Java/.Net/Python/C++да, у этих языков/платформ тоже хорошие инфраструктуры. это как-то отменяет такую же у php?
> Действительно хороших IDE под PHP попросту нет.
PhpStorm? Все продукты jetbrains могут претендовать на роль лучших в своей нише. разве что clion пока не дотягивает.
> Фреймворки типа laravel/yii/etc. —
> похожи друг на друга как родные братья, с примерно одинаковыми сильными
> и слабыми сторонами. Экосистема откровенно заточена на веб-сервисыЕсли бы разбирался в php, то такую чушь не написал бы.
Конкретно эти фреймворки не заточены на написание веб-сервисов. Хочется экзотики? Пощупай swoole/roadrunner/reactphp, например.> свежая кровь почти не поступает
тут правда. такие неадекваты как ты создают негативный окрас вокруг пхп и молодежь бежит ваять на js/go/python.
Это очень хорошо. Чем больше "бегут ваять", тем чище атмосфера, и тем меньше конкуренции.
> PhpStormНе смешите мои тапочки. Да, по сравнению с другими IDE для PHP она хороша. Но по сравнению с эффективностью той же IDEA и даже Qt Creator — увы. Во многом из-за особенностей языка, но ведь про это мы и говорим?
> Если бы разбирался в php, то такую чушь не написал бы.
Возможно. Я из PHP ушёл ещё до их появления, дальше лишь отслеживал в фоне развитие языка. Правда, почему-то в итоге это я порой консультирую типа спецов по этим фреймворкам, которые сам увидел только вчера, как ими пользоваться... Так что, может, я и упустил что-то, для себя пока что понял, что они все прежде всего заточены делать REST API и всякую там унификацию, чтобы по одному URI отдавать то HTML, то JSON, то вообще PDF. Плюс RBAC и всё связанное. Собственно влез во всё это потому что бэкенд в одном моём проекте на Yii2. Прикольная штука, в целом он мне понравился.
> такие неадекваты как ты создают негативный окрас вокруг пхп
Да пусть живёт и здравствует, ничего плохого про язык я не говорил. А только про инфраструктуру. Вон, у той же .Net ещё несколько лет назад был полный позор, а сейчас и VS прилично выглядеть стала, и Nuget-пакеты популярность набрали... PHP тоже выглядит в динамике очень неплохо. Просто глупо закрывать глаза на связанные с ним минусы.
>Собственно влез во всё это потому что бэкенд в одном моём проекте на Yii2. Прикольная штука, в целом он мне понравился.Yii2 - новинка из 2008-го, уже почти закопали. С тех пор столько воды утекло, что лучше промолчу.
Инфраструктура как раз таки один из плюсов современного PHP - компонентные фреймворки и composer, куча тестовых фреймворков, тулзов для стат анализа и тд. Допускаю, что где-то может быть лучше, но упрекать тоже не за что ( +/- как во всех остальных скриптовых языках ).
IDE сдаются только на поддержке магии, и write-only кода. Типизация и отказ от повсеместного использования массивов творят чудеса.
>>Собственно влез во всё это потому что бэкенд в одном моём проекте на Yii2. Прикольная штука, в целом он мне понравился.
> Yii2 - новинка из 2008-го, уже почти закопали. С тех пор столько
> воды утекло, что лучше промолчу.В 2008 году был Yii 1.0, Yii 3.0 я бы ещё побоялся ставить в production. Зачем вы обманываете?
> Инфраструктура как раз таки один из плюсов современного PHP - компонентные фреймворки
> и composer,... который без дополнительных усилий не умеет в reproducible builds... Ну, это я так, о наболевшем.
> куча тестовых фреймворков, тулзов для стат анализа и тд.
> Допускаю, что где-то может быть лучше, но упрекать тоже не за
> что ( +/- как во всех остальных скриптовых языках ).Именно. Всем вышеперечисленным не удивить ни перловиков, ни питонистов, ни дотнетчиков, ни почитателей Ноды.
> IDE сдаются только на поддержке магии, и write-only кода. Типизация и отказ
> от повсеместного использования массивов творят чудеса.Угу. Только это дополнительные усилия со стороны разработчика, которому не дают использовать вкусности языка, потому что иначе его среда разработки станет не полезнее Sublime.
Я не отрицаю, что в мире PHP есть типовой набор инструментов разработки. Речь об их, инструментов, некоторой отсталости в ряде моментов, по сравнению с аналогами для других языков.
PHPStorm, PHPEd
Быдлокодеры отвергли P++ - пусть страдают.
Серебрянные пули и осиновый кол в операционную СРОЧНА!!!111!!
Да ладно вам, ваш хруст ещё потрепыхается.
Наш хруст жив и здоров, спасибо.
Я работал на PHP full time больше года.
При всём уважении, пули и кол, пожалуйста.
> Я работал на PHP full time больше года.ВАУ!
А я на нём почти 20 лет уже пишу...
Ага, с 4.0.
Не люблю его по эстетическим причинам. Многое в подобных языках сразу было не заложено и теперь эти костыли всяко сбоку и прочим образом крепят.Из скриптовых Ruby мне наиболее близок. Ещё есть Crystal/Elixir