#ТоксикСреда

Одна из величайших проблем PHP

Кто голосует за PHP RFC?
Кто решает, каким PHP станет?

А зайдите и посмотрите на RFC по дженерикам и тред обсуждения.

Голосовали ПРОТИВ:

Из PHP Core и Foundation:
- Derick Rethans — Xdebug, release manager.
- Tim Düsterhus — core C-слой.
- Matteo Beccati — core/security.
- Gina Banyard (girgias) — core, автор конкурирующего подхода «Compile-time generics» через монтоморфизацию.
Не Core:
- Rowan Tommins (imsop) — активный участник internals.
- Ben Ramsey — release manager 8.1, автор ramsey/uuid, дед.
- Aleksander Machniak (alec) — Roundcube.
Топят за то, что дженерики должны быть нестираемыми и делать проверки в рантайме. Хотят отложить до PHP 9.

Не высказали позицию: Sara Golemon (pollita), Jakub Zelenka (bukka), Kalle Sommer Nielsen (kalle).

Не из Core, но позицию тоже не объяснили:
- Sebastian Bergmann (sebastian) — автор PHPUnit, дед.
- Volker Dusch (edorian) — свита Себастиана.
- Shivam Mathur (shivam) — setup-php (CI-инфраструктура PHP в GitHub Actions), на PHP не пишет.
- duncan3dc — Craig Duncan, мейнтейнер thephpleague/climate.
- jordikroon — Jordi Kroon, нидерландский backend/DevOps-разработчик. Право голоса — по коммитам в инфраструктуру php.net.
- kguest — Ken Guest, «PEAR guy»: мейнтейнер PEAR-пакетов (Services_OpenStreetMap, Net_IMAP), контрибьютор build-инструмента Phing.


Высказались ЗА:

- Ondřej Mirtes — создатель PHPStan.
- Matthew Brown — создатель Psalm.
- Daniil Gentili — мейнтейнер Psalm.
- Brent Roose — DevRel PhpStorm (JetBrains), Tempest.
- Nicolas Grekas — core Symfony.
- Frederik Bosch (MoneyPHP), Benjamin Außenhofer, Arvids Godjuks — работяги из сообщества.

Из них проголосовал только Nicolas Grekas.

—

Это подтверждает тезис, что

Люди, которые будут пользоваться этой функцией каждый день, не голосуют. Голосуют те, кто никогда не напишет Collection<User>

Соглашусь с Брентом из его статьи A generic tragedy, что похрен на то, что дженерики сейчас не приняли.
Меня беспокоит то, что у языка нет дизайнера, нет единого видения.
Почему-то за важные фичи голосуют какие-то деды без всякой аргументации, писатели документации и девопсы.
Да, к настоящим core-разрабам надо прислушиваться, как к технарям-экспертам, но дизайн языка это больше про DX. Чуваки из Core не пишут на PHP.

Вот реально, на списках фичей следующей версии PHP можно ставки делать. Нет дорожной карты. Каждый год хер его знает, что там будет через год.
Как бы Рома Пронский не упрекал меня в душности, я всё равно останусь при своём мнении: текущая система принятия RFC - говно.

PHPF стоило бы заняться именно этим, а не инклюзивностью. Например, найти экспертов в дизайне ЯП (только нормальных экспертов!), составить несколько планов развития и предложить их сообществу, раз без голосования нельзя.

—

Нужен ли нам доброжелательный диктатор на дизайне языка или идти по пути голосований — сложный вопрос. Но я на 100% уверен, что неэкспертов надо убирать из голосований.

Мэтью Браун (автор псалма) сообщает, что перевибрировал Psalm на Rust. Получился Pzoom.
Типа х10 быстрее но хз как писать на него плагины.
Вот песочница.

Позже выяснилось, что ещё один пользователь вибрировал Psalm на Rust. Получился Mir.
Вот песочница.

Куда катится этот мир?

Мольбы услышаны!
VibePHP

В VibePHP нет парсера. Ваш код никогда не компилируется, он только понимается.
Запросы вместе с кодом передаются в аишку, и возвращается хер знает что.

Код можно писать как угодно: с дженериками, асинком, эмоджами, всратым ТЗ из переписки с заказчиком. AI предполагает, что должен вернуть ваш код, и навибрирывает ответ.

| Время выполнения | Задержка | $ / запрос |
|------------------|----------|------------|
| nginx + PHP-FPM  | ~1 мс    | ~$0.00000x |
| ФранкенПХП       | ~1 мс    | ~$0.00000x |
| VibePHP          | ~7 с     | ~$0.0063   |

* Для работы нужен токен OpenAI.

Сделал группировку тестов в Testo.
Как оказалось с фичёй наследования, которую пользователи просили в PHPUnit, но так и не получили.

Продолжаем тему вайба.

Для кого-то нет вайба в пайп-операторе. Кто-то люто вайбкодит. А тут ещё и VibePHP появился.

Да что это за вайб такой? Как его пощупать? Как понять, где вайба больше и хорошо ли это вообще?

Теперь вайб можно померить!

На выходных я навибрировал Github Action, замеряющий Индекс Вайба в репозитории.
Весь отчёт умещается в компактный бейдж с оценкой от 0 до 10: чем больше число, тем более весомый вклад AI и авто-ботов относительно человеческого.
То есть просто считается доля коммитов (из последних 250) и строчек кода за (со)авторством ботов относительно всей репы.

0.0 — всё делается вручную.
4.0 — сбалансированный подход.
8.0 — код вибрируется, но с участием человека.
10 — здесь людей уже нет.

Естественно, оценка может расходиться с реальностью:
- соавторство агентов удаляется из коммитов — меньше вайб.
- статистическая инерция.
- индекс не отображает качество вайба.

Как трактовать индекс — решать вам.

Например, сам пакет Vibe Index имеет индекс 7.5. Он навибрирован на 100% агентами в редакторе ZED с моим пассивным ревью через чат.
Не дотянул до ровных 8.0 баллов просто из-за того, что первые коммиты были нагенерены через Haiku, который не ставит соавторство.
Это не критическая инфраструктура и даже не зависимость в node_modules, поэтому требования к качеству кода минимальные. А значит высокий индекс вайба здесь только на пользу: скорость фиксов или появления новых фичей скорее всего не будет проблемой.

Давайте посмотрим, где вайба больше.
- PHP: 0.0 — подозрительно.
Серверы:
- FrankenPHP: 2.7
- Folk: 5.2 — думал, будет больше.
- RoadRunner — 1.5 dependabot на go-bump.
Тестирование:
- Testo: 1.2 — занижено, т.к. часто удалял соавторство при сквоше.
- PHPUnit: 5.0 — куча коммитов от авто-ботов.
- Pest: 0.1 — да кого вы пытаетесь обмануть?


Пока писал этот пост, Vibe Index стал ещё и пакетом npm. Можно прочекать индекс вайба любого репозитория, например, вот так: npx @roxblnfk/vibe-index spiral/framework

Я думал народ на Пыхник набьётся за один-два дня. А тут 21% всего.

Что с сообществом случилось?

Пацанский стиль

В продолжение поста из канала Пых.

———

Вот есть Йода-стиль if (<scalar> === <var>), который в симфе издревле был за стандарт (хз как сейчас).
Он для додиков, чтобы случайно присваивание в if не записали.

if (false = $x) упадёт в рантайме, в отличии от if ($x = false), и тем самым предупредит, что автор забыл ещё одно равно (а лучше два).

———

А <cond> and/or <act> — немного другое. Это пацанский стиль, из нулевых.
Читается также, как "PVP или зассал!".
А ещё это классика из PHP 4:

mysql_connect($host, $user, $pass) or die("could not connect");

Смотрите, как компактно и понятно выглядит лапша валидации (узкая телега может испортить восприятие. Лучше смотреть на гитхабе или в редакторе):

$warmup >= 0 or throw new \InvalidArgumentException('Warmup must be greater than or equal to 0.');
\count($callables) >= 1 or throw new \InvalidArgumentException('At least one callable must be provided.');
$calls > 0 or throw new \InvalidArgumentException('Calls must be greater than 0.');
$iterations > 0 or throw new \InvalidArgumentException('Iterations must be greater than 0.');

#ТоксикСреда

На днях я запостил в блоге Testo отчёт о том, как я сравнивал тестовые фреймворки в проекте stitcher.io.

В той работе тесты на PHPUnit работали слишком медленно и я полез разбираться. Одна из причин замедления — атрибут #[Before] на методе setUp() приводил к тому, что setUp() вызывался дважды (по конвенции именования и по атрибуту).

Статья ушла в релиз и её даже кто-то прочитал. А потом в PHPUnit появилась вот эта ишуя.

"У меня в голове не укладывается, что человек, впервые обнаруживший эту ошибку, упомянул о ней только в своем блоге, а не создал тикет",
Пишет Себастиан.

Я даже и не подумал, что это баг. Скорее мысли были "а нафига так сделано?".

В общем, сегодня хейтим меня, ибо я, получается, поступил как мудак.

Из хорошего для деда: он прочитал отличную статью.

Давайте тоже заполним этот опросник от JB и напомним миру, что есть такие замечательные опенсорсы, как Spiral, Yii3, Testo, Buggregator, RoadRunner и Rapira.