Что не нравится в PHP?

Что меня раздражает в PHP после 10 лет разработки

Как опытный PHP-разработчик, я должен отметить, что язык за последние годы сильно эволюционировал (особенно с версий 7.4+ и 8.x), и многие старые "больные места" были исправлены. Однако некоторые фундаментальные проблемы и исторические "шрамы" остаются.

1. Историческое наследие и непоследовательность

Консистентность именования функций — классическая проблема. Функции в глобальном пространстве имен появлялись ad-hoc, что привело к хаосу:

// Почему strpos(), но str_replace()?
// Почему htmlspecialchars(), но html_entity_decode()?
$pos = strpos($haystack, $needle); // аргументы: haystack, needle
$arrayKey = array_search($needle, $haystack); // аргументы наоборот: needle, haystack!

Отсутствие единого стиля именования (camelCase, snake_case, смешанный стиль) постоянно требует заглядывания в документацию.

2. Модель типизации до версии 8.0

До PHP 8 строгая типизация была скорее опцией. Система типов была "нестрогой" по умолчанию:

function process(int $value) {
    return $value * 2;
}

process("10abc"); // До PHP 8: преобразуется в 10 с предупреждением
// PHP 8+: TypeError исключение

JIT-компилятор, появившийся в 8.0, хоть и улучшил производительность для числовых задач, но для типичного веб-приложения (I/O bound) дает незначительный прирост, добавляя сложность конфигурации.

3. Проблемы с обработкой ошибок

Исторически ошибки и исключения были разными сущностями. Даже сейчас некоторые внутренние функции PHP генерируют ошибки вместо исключений:

try {
    $file = fopen("nonexistent.txt", "r");
} catch (Throwable $e) {
    // Этот блок НЕ перехватит warning от fopen!
    // Нужно использовать set_error_handler()
}

Переход к исключениям в стиле ООП произошел поздно, и обратная совместимость мешает полностью отойти от старой модели.

4. Проблемы стандартной библиотеки

Многие функции из глобального пространства имен имеют неоптимальные интерфейсы:

• Параметры по умолчанию в неочевидном порядке: explode($separator, $string, $limit) vs implode($glue, $pieces)
• Функции, изменяющие исходные данные: sort() работает in-place и возвращает bool, а не отсортированный массив
• Отсутствие современного API для работы с коллекциями, как в современных языках

5. Сложности с параллелизмом

Долгое время PHP придерживался модели "один запрос — один процесс". Появление Swoole, ReactPHP и Fibers в 8.1 — шаг вперед, но:

// Fibers (PHP 8.1+) — низкоуровневый API, неудобный для повседневного использования
$fiber = new Fiber(function(): void {
    Fiber::suspend('test');
});
$value = $fiber->start();
echo $value; // 'test'

Для полноценной асинхронности все равно нужны сторонние решения или расширения, что дробит экосистему.

6. Конфигурация и суперглобальные переменные

Суперглобальные массивы ($_GET, $_POST, $_SESSION) — удобны, но нарушают принципы инкапсуляции и тестируемости:

// Прямой доступ к суперглобальным — проблема для unit-тестов
function isAuthenticated(): bool {
    return isset($_SESSION['user_id']); // Зависимость от глобального состояния
}

Разбросанность конфигурации (php.ini, .htaccess, ini_set(), runtime-конфигурация) усложняет деплой и отладку.

7. Проблемы сообщества и восприятия

Устаревшие стереотипы о PHP ("язык для новичков", "небезопасный по умолчанию") до сих пор влияют на репутацию, хотя современные фреймворки (Laravel, Symfony) предлагают enterprise-уровень возможностей.

Фрагментация экосистемы между Composer-пакетами и PEAR, разными стилями кодирования (PSR vs индивидуальные стандарты).

Что изменилось к лучшему в современных версиях

Несмотря на критику, важно отметить прогресс:

1. Union types и тип mixed (PHP 8.0)
2. Readonly свойства и конструктор property promotion (8.1, 8.0)
3. Атрибуты вместо док-блоков аннотаций (8.0)
4. Nullsafe оператор ?-> (8.0)
5. Совместимость с современными практиками (Dependency Injection, Event-Driven Architecture)

Заключение

PHP из "скриптового языка для веб-страниц" превратился в зрелый язык для веб-разработки. Многие недостатки — плата за обратную совместимость и 25-летнюю историю. Критичные для бизнеса проблемы решены в современных фреймворках, а оставшиеся "шероховатости" — скорее эстетическая, чем практическая проблема для опытного разработчика, умеющего использовать сильные стороны языка: быстрое прототипирование, огромную экосистему и превосходную документацию.