Комментарии 69
А перечислимые типы (enum) подвезли уже?
Да, в 8.1
Вот понять не могу. К php программистам так с презрением относятся, а сам язык мне нравится. Сколько статей читал про то, что он плохой, что лучше его не использовать и на php только веб макаки сидят, но он развивается и сайтов много на нем работает.
С этими словами ты опоздал на 5-6 лет
Посмотри исходный код 1с Битрикс или wordpress и потом посмотри количество вакансий на битрикс и wordpress и всё встанет на свои места. А так на мой взгляд современный php уже сложнее чем c#, но при этом в c# на dotnet 7 есть простая асинхронность, простой entity framework и linq для работы с множествами и бд, включая миграции бд, и ещё есть хороший и быстрый фреймворк для web api и всё это дело поддерживает крупная компания. И вот на фоне такой технологии стоит php в котором Битрикс самый популярный фреймворк в РФ, а ларавел занимает последние места в тестах производительности и как то получается что сейчас лучше взять c# с dotnet 7 и получить за то же время более качественный результат.
с c# в комплекте идет весь M$ серверный стек с хорошим ценником. да, можно запускать в моно, все в курсе, но кто так делает? да и аргументов что результат будет более качественный вы не привели, так что тут я не уверен что С# будет хорошо выглядеть. да, как язык он ничего так, но языком дело не ограничивается
А зачем mono?
.Net Core уже не первый год существует.
dot net 7 кроссплатформенный и open source, это если вы про то что для него требуется windows. Если нет поясните что вы имели в виду под MS серверным стеком
Если вы еще не смотрели .net 7 то очень рекомендую посмотреть https://dotnet.microsoft.com/en-us/download/dotnet/7.0 Он стал бесплатным, кроссплатформенным а исходники лежат на гитхабе. Разрабатывать можно в бесплатной версии visual studio под windows и при этом есть кросскомплияция бинарников под линукс и можно сформировать self hosted выполняемый файл и не ставить саму платформу .net на сервер как с тем же php.
В самом простом варианте проект на .net 7 выглядит вот так https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-7.0
Просто просмотрите сверху вниз и обязательно попробуйте. Сейчас благодаря asp net core разрабатывать веб на C# проще чем на том же php а результат работает в разы быстрее чем на php даже если использовать полноценную открытую ORM Entity Framework Core. А если вы использовали laravel то результат на asp net core будет выдерживать нагрузку в 10 и более раз выше.
Врать таки не обязательно. Фреймворк бесплатный, библиотеки тоже. Развернуть можно в докере. Плюсы в виде ef linq и прочего товарищ выше уже привел.
Не нужно называть битрикс фреймворком. По сути это CRM, к которой прикрутили кучу функционала. К нормальным фреймворкам он имеет крайне опосредованное отношение.
Смешали кучу понятий
Может быть и CRM, и CMS, и фреймворк
Ели не видели в реальной жизни больших проектов, где Bitrix как фреймворк используется, то это не значит что они не существуют
Я могу понять использование битрикса как CMS из-за большего кол-ва готовых модулей для приёма платежей, расчёта доставки, интеграции со складскими системами и т.п., но вот использовать как фреймворк это странно. У него ведь ужасный код ядра, плохая документация и отсутствие какого либо дружелюбия к разработчику
На Bitrix не только интернет-магазины делаются.
Прекрасно работает на php8, что свидетельствует о решении многих проблем.
"Странно" это относительная оценка, а не факт. Факт в том что как фреймворк он работает.
Код ядра читается, если в документации чего-то нет, IDE помогает. Документация не самая лучшая, согласен.
"Ужасный код" снова оценка. Есть отвратительные места в коде, а есть и отличные современные. "Ужасный" код легко находится и фреймворках и во всеми любимом WP.
Не стоит уверенно судить о том, чего в реальности не видели.
У меня основные претензии к битриксу были такими:
Отсутствие взрослой системы накатывания обновлений. Все обновления накатываются через web интерфейс в котором может что угодно пойти не так. Плюс обновления не повторяемые, я не могу зафиксировать что мне нужно обновить до конкретной версии, через web интерфейс обновляется до последней возможно версии (поправьте если ошибаюсь). Это приводит к тому, что я как разработчик не могу протестировать обновление локально и накатить обновление условно через месяц т.к. за это время может выйти новая версия того или иного модуля.
ORM которая не ORM, а просто набор классов для работы с БД. В нормальных ORM мы манипулируем записями БД как объектами, но не в битриксе, в битриксе только массивы.
P.S. Как решение можно использовать сторонние пакеты вроде этого https://github.com/sheerockoff/bitrix-entity-mapperОтсутствие вменяемой документации. D7 анонсировали около 8 лет назад, но до сих пор документация находится в плачевном состоянии.
Несоблюдение стандартов разработки, весь код написан в стиле который идёт в разрез со всем PHP сообществом. В коде используются короткие открывающие теги PHP, методы классов вызываются как статические хотя таковыми не являются, PSRы не соблюдаются, отсутствует единая точка входа, composer не используется
Сам битрикс не заточен на контейнеризацию, опять же это следствие нескольких факторов:
1.стандартные модули поставляются не через менеджер пакетов composer
2. обновления накатываются через web интерфейс
3. редактирование некоторых настроек приводит к изменению файлов, а эти изменения затираются после передеплояу разработчиков битрикса постоянное желание писать свои решения, хотя можно использовать сторонние пакеты которые уже стали стандартом в разработке. Тогда бы разработчики не плевались от отсутствия документации и получали бы релевантный опыт
Это всё что удалось быстро вспомнить (т.к. давно не работал), но если надо могу долго продолжать описывать минусы с которыми сталкивался при разработке на битриксе. Всё эти минусы простительны когда мы говорим о битриксе как о CMS, т.к. CMS ориентированы на пользователей, но при позиционировании его как фреймворка такие проблемы сложно игнорировать, потому что фреймворк ориентирован на разработчиков и должен помогать в написании кода, а тут получается что разработчику приходится бороться с фреймворком пробираясь через тернии документации и легаси кода
В этом плане Joomla 4 дальше Битрикса по многим позициям.
ORM которая не ORM, а просто набор классов для работы с БД. В нормальных ORM мы манипулируем записями БД как объектами, но не в битриксе, в битриксе только массивы.
это не совсем так. Точнее это (только массивы) будет устаревшим подходом. fetchObject, fetchCollection и вперед....
Код ядра: а вы не смотрите :) Если серьезно, вы же не смотрите в код всех программ и инструментов, все равно оцениваете именно то, как оно выполняет свою работу.
Документация и "дружелюбие"... Относительное понятие - когда мало работаешь или пытаешься освоить - может быть.
У меня есть свой проект и осознанно выбрал Битрикс. (конечно сыграло роль, что и по основной работе именно с битрикс проектами работаю). но.. У меня проект это SaaS. Более конкретно упрощенный САПР. Битрикс в первую очередь дал мне быстрое создание сайта, интеграции с платежными системами и т.п. в общем как инструмент донести информацию до пользователя и обеспечение взаимодействия с ним. Т.е. тут вообще на это потрачено минимум времени...
Далее идет уже тот самый модуль являющийся сутью проекта. Фреймворк Битрикс используется только на инфраструктурном уровне: там контроллеры для аякса, контроллеры для нового роутинга битрксового, репозитории (работа с ОРМ инфоблоков), классы таблиц - по сути тоже работа с ОРМ, но только уже со своими таблицами БД, ну и все возможные агенты (что по сути контролеры для CLI), работа с настройками... ну в общем все взаимодействие с апи битрикс.
Все это легкое, без какой то тяжелой логики. Все уже в сервисах.... Т.е. условно говоря, мне не проблема все перенести на симфони, ну или иной фреймворк. И будет доработан именно и только инфраструктурный слой с легкими классами.
И даже если бы писал "с использованием симфы" - все бы оставил точно так же - без взвешенной необходимости сильно завязывать на какой либо фреймворк это, на мой взгляд, не правильно...
В общем если обсуждать с точки зрения "пользователя-разработчика". Инструмент как инструмент, строить все на массивах не заставляет. А писать плохой код можно хоть на симфони хоть как. Тут от "программиста" зависит.
Симфони, кстати, тоже использую. Точнее консоль от нее - некоторую автоматизацию разработки реализовал для удобства.
Ну и как вероятное развитие. Часть проекта (уже где идет непосредственная работа пользователя с сервисом) - прям напрашивается SPA. Как знать, может психану :) И весь фронт вообще на vue + node.js переделаю. (все равно однажды надо дизайн сделать "приличный" вместо шаблонного из коробки).. Вот и получится, что от битрикса останется только бизнеслогика и админка. Стоит ли переписывать это все когда у меня по основному модулю работы по определению не могу быть ни когда закончены - там "фишек" хоть обвнедряйся"?
Ели не видели в реальной жизни больших проектов, где Bitrix как фреймворк используется
Весьма категоричное суждение - "если ваше мнение не совпадает с моим, значит вы ничего в жизни не видели".
Мне доводилось работать с корпорталами для госорганизаций, на несколько тысяч человек. Не знаю, считается ли это "большими проектами" в вашей системе ценностей; однако контракты там крутились миллионные, и под определение "интернет-магазин" они точно не попадают.
Так вот. Туда смогли вкрутить git, composer, самописную систему миграций и много чего еще. Словом, все практики нормальной разработки, которые по-умолчанию реализованы во фреймворках, но отсутствуют в битриксе. Собственно, от изначального "коробочного" решения там осталось разве что ядро (и то было перепилено в нескольких местах).
О чем это говорит? При наличии грамотных разработчиков (и миллионных контрактов) можно сделать практически что угодно. Стал ли от этого битрикс фрейморком? Думаю, нет.
Категоричность не я ввел в диалог. Предлагаю почитать определение понятия фреймворка сначала.
Предлагаете меряться проектами? Конкретика под NDA, но что то вы назвали "большими проектами" для нас обыкновенная каждодневная рутина. Как минимум это разного рода ЛК, аукционные площадки и другие узконаправленные бизнес-сервисы.
Смогли "вкрутить git, composer, самописную систему миграций и много чего еще" это все много лет как стандарт разработки и инструменты, не нужно пугать людей. Что-то есть из коробки, что-то ставится поверх. Это все прекрасно работает. Как и инструменты типа rector, phpstan, phpunit и т.д.
Раз перепилили ядро, то изначально был выбран неверный путь архитектором.
О чем это говорит? Вы просто не знаете актуального состояния инструмента.
Так ведь ни кто и не говорит что битрикс стал фреймворком. В битриксе есть фреймворк, который вполне можно использовать. Естественно брать Битрикс именно в качестве фреймворка для нового проекта - тут надо смотреть именно на возможности. Если существующие модули (как "бонус" к фреймворку) покрывают значительную часть планируемых работ почему бы и нет?
Есть такая штука стоимость владения решением. Возьмите бизнес задачу и опишите ее решение на стеке Х и на стеке Y, посчитайте во что обойдется владение в одном и в другом случае, например в течении 5-7 лет и сравните результаты. Можете получить, что "качество" языка программирования в принципе не важно.
А как же symfony? Отличный фреймворк, современны, мощный, насыщен современными лучшими подходами в вебе. А-ля спринг на пхп. Кроме него есть ещё несколько хороших фреймворков, которые отлично подходят для Энтерпрайза. Конечно же, есть свои нюансы, в целом, лучше, имхо, выбрать джаву или го. Но на пхп можно собрать не менее устойчивое и надёжное приложение. А в определённых ситуациях, даже, будут свои преимущества перед другими стеками.
хейтить пыху это традиция. традиции не надо понимать, им надо следовать.
У каждого ЯП есть плюсы и минусы. Есть хорошие и качественные реализации, а есть плохие. Возводить что-то в абсолют, не снимая розовых очков, в корне неверно.
Проблема РНР не в том, что он плохой, а в том что простой. На РНР, как и на любом другом языке, можно писать хорошо и можно писать плохо. Но из-за того что РНР очень прост в освоении, на нем реально может начать писать любая кухарка, освоившая HTML. Вот кухарки и пишут. А потом еще и начинают других учить. Но надо все-таки отличать кухарок от программистов. Которые прекрасно пишут на РНР отличный код.
А дальше все просто — о языке судят по таким вот кухаркиным программам и книжкам. Если взять наугад какое-нибудь руководство по РНР или ответ со Stack Overflow, или какую-нибудь программу, которую начали писать еще в прошлом веке — например Wordpress — то там все так и будет — код плохой, авторам стыдно. Но вот делать вывод о том что РНР "лучше не использовать" — вот это будет уже глупость. Надо просто самому не быть макакой, а учить программирование. Тогда и язык вдруг станет нормальным.
Мы все понимаем, что Wordpress (а еще MediaWiki итд итп) хорошо бы переписать с использованием современных практик.
Но кто этим будет заниматься? И кому это нужно? (риторические вопросы)
Мне довелось работать в компании, где суровые бородатые дядьки с академическим образованием пишут на Java бизнес логику в шапке сайта, и хихикают над php.
В последние годы пых подрастерял свои позиции в своей традиционной нише веба, под давлением других языков.
Это нормально, хотя и немного напрягает, потому что при формировании архитектуры часто делается выбор в сторону решений, менее удобных и имеющих меньший объем наработок (бэкграунда). Например, по причине того, что в команде больше опыта в питоне - выбор делается в пользу питон/джанго или фласк. Сильно стал прирастать именно питон - ввиду частоты его использования как учебного языка. Первый - это как первая любовь ;-) уже не забыть. Так новички часто подсознательно делают выбор в его пользу.
В последние годы пых подрастерял свои позиции в своей традиционной нише веба, под давлением других языков.
"подрастерял" – это потерял 3%?) было 80%, стало 77%
кто подрастерял, так это ASP.NET у которого раньше 20% было, а теперь 7%
Довольно странные подписи. JS — это нода? "ASP" — это Си шарп?
JS это JS. Его не только нода использует https://en.wikipedia.org/wiki/List_of_server-side_JavaScript_implementations
ASP.NET – это все языки под .NET, туда не только C# входит.
Все началось со статьи "PHP: фрактал плохого дизайна" (*). Понятия не имею, что хотел сказать автор, называя так статью - но он был из тех танцоров, которым мешают яйца.
С тех пор прошло много лет. Как бы не десять, да.
Язык очень серьезно изменился.
PHP тех лет и PHP нынешний - это два совершенно разных инструмента.
Ситуация в некоторой степени усугубляется тем, что в сети все еще полно рецептов и рекомендаций использовать PHP неправильно. Вплоть до, да, рекомендаций использовать mysql_connect(), эмулировать композер (потому что тогда композера ещё не было) или, прости господь (Тьюринг), не использовать классы в принципе. К счастью, сайты с такими советами совершенно естественным образом приказывают долго жить и исчезают.
Но люди-то помнят! Помнят, что когда-то PHP был плохим, что его было модно ругать, а таковой ругающий в глазах окружающих обретал ореол некой особенной праведности!
P.S. (*) а может быть, и немного раньше - но популярной проблема стала, по моим наблюдениям, именно с этого фрактала.
Как-то так.
К php программистам так с презрением относятся
Сам php-программист, сам отношусь с презрением к php. И вот почему:
хоть многие пункты и поправлены с годами, многие всё ещё актуальны.
Таблица сравнения значений разных типов: https://www.php.net/manual/en/types.comparisons.php
считаю, что одно наличие таких гигантских таблиц, которые ещё и меняют поведение от версии к версии языка - это признак, что что-то идёт не так.
и в целом на пхп люди очень часто злоупотребляют тем, что у них динамическая типизация.
Я прямо грущу, когда вижу очередной __invoke() или __get() у непонятного нечто, которое мне подкинули через di. Без запущенного дебаггера не узнаешь, что за код выполняется. А иногда смотришь в дебаггер - а там Closure. Я так недавно сходил с ума с ловлей утекающей памяти в http-клиенте Guzzle. Взгляните на его код. это ппц - тройная вложенность билдеров замыканий с "промисами". Плот-твист: в php нет промисов.
Душнила mode on =)
Раньше писать в них код и читать его можно было только в конструкторе
Нет, писать в них значения (один раз) и читать их можно было где угодно https://onlinephp.io/c/7a36c
<?php
class Test
{
public readonly string $title;
public function init(): void
{
$this->title = 'some';
}
}
$t = new Test();
$t->init();
var_dump($t->title);Теперь вместо того, чтобы указывать тип mixed для аргументов в методах, можно просто перечислять необходимые типы через амперсанд.
Тоже нет. Это означает, что в PHP 8.2 можно использовать и конъюнкцию и дизъюнкцию одновременно. Раньше можно было использовать либо одно (И), либо другое (ИЛИ). Более того, любая подобная форма так же подвержена правилам Барабары Лисков:
abstract class ParentClass
{
abstract public function test(): (A&B)|null;
}
class ChildClass extends ParentClass
{
public function test(): A&B {}
}Это изменение единогласно приняла вся команда разработчиков PHP, так как в ядре PHP есть методы, классы и функции, которые возвращают false или true.
Не совсем. Вначале речь в обсуждении (если не путаю) шла о добавлении true, т.к. уже был отдельно false (который использовался в stdlib часто из-за СИшного легаси апи). Для того, чтобы просто привести систему типов к единообразию (а не для каких-то практических целей).
А выделение подобных типов в standalone было сделано для того, чтобы их можно было сужать по LSP:
// parent
public function request(): Response|false;
// child
public function request(): false;И вроде как даже в отдельном обсуждении было.
Теперь можно передавать в методы iterator_() тип \Traversables
И раньше можно было. А сейчас можно iterable (т.е. входящие аргументы \Traversable заменили на array|\Traversable).
Да и проверять на тип раньше тоже не обязательно было, можно было просто count([...$iterable]) писать вместо count + iterable_count для разных типов. Просто это работало долго.
так, я не понял, и что ни одного комментария в духе "а что на нём кто то ещё пишет?" ?
где я вас спрашиваю холивары?
да, хабр уже не торт.
Вот и представьте, насколько умер язык, что даже холивары на тему "кто на нём вообще пишет" устарели!
Скорее хабр не торт после февраля. Вы посмотрите с каким опозданием новость появилась об новой версии. Всякие дайджесты об php уже наверно как пол года никто не делает, да и не только по php, а вообще по любому языку. Такое чувство, что только переводчики тут остались.
Если интересуют дайджесты по php - их можно найти здесь: https://t.me/phpdigest
PHP резко просел по популярности в 2022, я прямо вижу это невооруженным взглядом. Но это ему пошло на пользу. На Тостере все вопросы из серии "я не понимаю, что мне надо, но мне надо это прямо сейчас!!" ушли в питон. РНР остался обычной рабочей лошадкой, на которой делают сайты.
А по индексу Tiobe он в 2022 на 2 позиции вверх скакнул
Эм, я не очень понимаю все эти пузомерки. Но в предполагаю, что этот скачок явно за счет еще более неудачливых технологий, потому что в абсолютных цифрах он стабильно едет вниз.
PHP уже пережил всех хейтеров.
С readonly для меня непонятно. Почему не использовать getter/setter? Фактически, readonly поля - это private поля + getter'ы.
Всё новое конечно хорошо)
…но бывает обновился, запускаешь свой движок который ты сам лет 10 назад начал писать и он оброс кучей всякий модулей - то одна функция под обновление, то другая отвалилась…
Это конечно касается исключительно только меня, и я все равно обновлюсь) а с ворнингами и деприкейтед методами полюбому жить…
Хотя было бы как для приложений andriod studio, само пометилось и предложило переписать везде в коде новую тему)
В любом случае - они молодцы, развиваютя)
async await мы похоже не дождемся
Среди списка нововведений затерялась интересная новая функция mysqli_execute_query - is a shortcut for mysqli::prepare(), mysqli_stmt::bind_param(), mysqli_stmt::execute(), and mysqli_stmt::get_result().
Ну кстати да, ее давно не хватало. Но опять же, те, на кого она рассчитана — начинающие, которые только учат язык и еще не освоили никакой ORM, про нее не узнают, потому что учатся по руководствам прошлого века… А остальным она не особо-то и нужна.
Какое-то слишком абсолютное утверждение. Не весь код на php сводиться к веб приложению на фреймворке с продвинутым ORM. Есть ещё микроскрипты для автоматизации, различные тестовые веб выплёвывалки из базы и прочая мелочь для которой просто неприятно тратить время на создание развесистой системы объектов и думать над проекцией всего этого в реляционную базу данных
В микроскриптах я использую PDO, чисто по привычке.
Тут ведь надо еще учитывать, что mysqli — уж очень нишевая либа, и кроме как при обучении почти нигде не применяется. И в первую очередь имеет смысл её рассматривать именно в этом контексте. Главным добавлением, которое действительно поменяло весь ход игры, было включение режима исключений по умолчанию. В одно мгновение сделав весь этот говнокод, if (!$conn) die(mysqli_error()) бессмысленным не только в теории но и на практике, вне зависимости от желаний говнокодера. Вот это в учебно-воспитательном плане действительно крутая фича.
А передача параметров в execute() вещь хорошая, но очень уж опоздала. Вот если бы можно было, наплевав на обратную совместимость, сделать чтобы execute() возвращала стейтмент — вот тогда да, я бы в микроскриптах переключился только на mysqli!
Современный PHP это просто какой-то подарок, по крайней мере лично для меня.
Скорость великолепная, сильно ушли в строгую типизацию. Скажи мне об этом несколько лет назад, не поверил бы.
Занимаюсь разработкой сложной CRM системы для сельхозкомпаний и у нас все крутится на 7.4, мы пропустили 2 версии PHP, но на 8.2 точно обновляться будем.
Хотя изначально система была построена на базе PHP 5.4 со всеми вот этими mysql_* функциями, без тестов, пакетного менеджера, автозагрузчика.
Помню, сколько трудов было сделать апгрейд до 7.0, но сейчас скачек с 7.4 до 8.2 мне кажется будет безболезненный.
Как выглядит код в PHP 8.2:
readonly class BlogData
{
public function __construct(
public string $title,
public Status $status
){}
}Такой код был бы более правильным...
Не факт, всё зависит от контекста. Это разные конструкции и работает код в примере и у вас по-разному. Если мы говорим, например, о Доктрине, то у вас как раз неправильный код.
В данном случае предлагаю поиграться с ReflectionClass::newInstanceWithoutContructor() и найти отличия в поведении у вас в коде и в оригинальном примере ;)
Вот что мне не нравится в новых функциях PHP так-это их синтаксическая неизящность.
Вот я обоими руками за асимметричную видимость. Но почему предлагается такой странный RFC? Почему этот синтаксис должен выглядеть как
public private(set) string $bar;
Откуда тут эти скобки?
В PHP скобки используются только для функций (их вызов и определение) и для порядка выполнения операторов. А тут предлагается добавить их и для переменных (свойств).
Вдобавок рушится ритмика текста. Глаз раньше чётко разделял свойства и методы по наличию у метода скобок
Почему бы, например, не использовать синтаксис public private-set string $var, т.е. просто расширить пространство зарезервированных слов public, private, protected?
Вышел PHP 8.2: разбираем главные изменения