Как правильно создать объект класса Request в Workerman?

Question

[azuf]

В документации для Workerman есть пример использования объекта класса Request для получения URI.

use Workerman\Worker;
use Workerman\Connection\TcpConnection;
use Workerman\Protocols\Http\Request;
require_once __DIR__ . '/vendor/autoload.php';

$worker = new Worker('http://0.0.0.0:8080');

$worker->onMessage = function(TcpConnection $connection, Request $request)
{
    $connection->send($request->uri());
};

// Запуск воркера
Worker::runAll();

Хочу создать отдельный объект этого класса, но не могу понять какой аргумент нужен конструктору. Код класса Request здесь. Код конструктора такой

public function __construct(protected string $buffer) {}

Нужно передать какой то буфер. Как понять что это должно быть? Зачем нужен модификатор доступа protected для параметра? Какие свойства он ему придаст?

Comments

[Виктор]

1) Зачем создавать Request, если Workerman сам его создаст? Тут просто регистрируется callback фукнция с аргементами, которые сервис сам прокинет
2) protected string $bufferэто PHP8, можно объявлять свойства объекта прямо в контрукторе (constructor promotion)

[azuf]

Виктор, что значит сам создаст? Мне нужно получить uri не в методе onMessage. Я почитал, что это появилось в PHP8, а как все таки создать экземпляр, если не понимаешь что передать в конструктор?

[Виктор]

azuf, что пробрасывается buffer можно найти по ProtocolInterface::decode, например

Мне нужно получить uri не в методе onMessage

не понимаю зачем, куда, когда.. Но этот uri можно в onMessage передать куда-нибудь еще или сохранить в переменную, например

$uri = null;

$worker->onMessage = function(TcpConnection $connection, Request $request) use ($uri) {
    $uri = $request->uri();
    $connection->send($uri);
};

[azuf]

что пробрасывается buffer можно найти по ProtocolInterface::decode, например

К сожалению, не понял что пробрасывается и причем здесь приведенный код.

не понимаю зачем, куда, когда..

Обрабатывать маршруты в роутере. В реквесте есть и другая нужная информация. Зачем засорять onMessage не относящейся к нему логикой?

или сохранить в переменную

Я и хотел сохранить в переменную, только не в методе onMessage, а используя экземпляр объекта.

[Vitsliputsli]

azuf, судя по коду, в buffer кладется сырой запрос, объект Request его парсит и предоставляет удобные методы для получения отдельных составляющих запроса: тип, хедеры, куки и т.п., в том числе uri. Затем вызывается метод onMessage и этот объект закидывается в него. Т.е. onMessage эта реакция на запрос, соответственно с него все и начинается.
Хотите обрабатывать отдельно, вызывайте обработчик из onMessage, и передавайте в него uri. Хотите один объект обработчик, закидывайте его в onMessage через зацепление.

[azuf]

Vitsliputsli, то есть нельзя создать экземпляр Request? Здесь Request используется вне onMessage, правда класс наследуется от исходного. Не знаю важно ли это, плохо разбираюсь в работе конструкций классов и объектов. Можно как то понять как и когда возникает объект request? Про буфер я так и не понял, что он из себя представляет, откуда, когда и как берется. Мне сложно мыслить объектами, потому что они имеют какое то состояние, нужно понимать когда и где оно возникает, и как, когда, и где изменяется. Мне проще мыслить функциями как черными ящиками. Принимает и возвращает значение. Так же можно построить всю программу, максимально исключив изменение состояний.

[Виктор]

azuf, а зачем взяли этот проект? Для изучения ООП можно что-нибудь по проще, тем более что Workerman хреново написан и по нему не стоит изучать ООП.

Обрабатывать маршруты в роутере.

роутер от какого-нибудь фреймворка или пакета? Думаю там есть свой Request. Если хотите обрабатывать все подряд, можно маску пути сделать и т.д. Изучайте документацию роутера.

[azuf]

зачем взяли этот проект?

Потому что он позволяет использовать PHP как полноценный язык, способный держать постоянный процесс. Что дает много новых возможностей, в отличие от общепринятой CGI модели использования PHP, когда процесс запускается отдельным веб-сервером, а после процесс умирает. И дает еще и увеличение производительности. И потому что он проще чем Swoole.

Для изучения ООП можно что-нибудь по проще, тем более что Workerman хреново написан и по нему не стоит изучать ООП.

У меня нет цели изучать именно ООП. Моя цель разобраться с Workerman. Мне непонятно как изучать ООП. Я вижу класс Request, везде учат, что нужно создавать экземпляр объекта от класса, а тут выясняется, что просто так объект Request не создашь. То есть чтобы понять как работать конкретно с таким классом, нужно сразу углубляться в какие то тонкости, как это сделать непонятно, так как во всех книжках одна и та же общая информация.

роутер от какого-нибудь фреймворка или пакета?

Нет, буду писать свой, усложняя по мере необходимости.

[Vitsliputsli]

azuf,

Vitsliputsli, то есть нельзя создать экземпляр Request? Здесь Request используется вне onMessage, правда класс наследуется от исходного. Не знаю важно ли это, плохо разбираюсь в работе конструкций классов и объектов.

Можно, но объекты не в вакууме существуют, их чтото создает и передает необходимые данные. Какие данные вы будете передавать для создания объекта? А нужно передавать buffer, т.е. сырые данные запроса http.
Пример который вы здесь привели, это оперирование с объектами класса Request, пожалуйста, можете сделать также, но чтото предварительно должно создать объект класса Request.
В Workerman гдето есть код по созданию объекта класса Request, и есть вызов onMessage с передачей туда Request.

Потому что он позволяет использовать PHP как полноценный язык, способный держать постоянный процесс. Что дает много новых возможностей, в отличие от общепринятой CGI модели использования PHP, когда процесс запускается отдельным веб-сервером, а после процесс умирает. И дает еще и увеличение производительности. И потому что он проще чем Swoole.

Демоны на php это такая же общепринятая модель, как и cgi, уже давно. И с ними все тоже самое, кроме некоторых нюансов. Обработка http-запросов демоном на php скорее всего будет менее производительно чем через php-fpm, потому что fpm максимально оптимизирован для такой работы.

У меня нет цели изучать именно ООП. Моя цель разобраться с Workerman. Мне непонятно как изучать ООП. Я вижу класс Request, везде учат, что нужно создавать экземпляр объекта от класса, а тут выясняется, что просто так объект Request не создашь. То есть чтобы понять как работать конкретно с таким классом, нужно сразу углубляться в какие то тонкости, как это сделать непонятно, так как во всех книжках одна и та же общая информация.

Зря, не разберетесь с ООП, дальше не сможете продвигаться.
Так у вас уже создан экземпляр класса, Workerman его создал. Весь смысл ООП, что вам не нужно вникать, что и как там делал Workerman - вам не нужно самому парсить запрос http, у вас есть есть готовый объект Request, с набором функций-методов, для удобного получения различных параметров запроса.

[azuf]

объекты не в вакууме существуют, их чтото создает и передает необходимые данные

Я же и спрашивал про $buffer. Код в ООП стиле сложно понять. По крайней мере мне. Код библиотеки/фреймворка преимущественно состоит из каких то деклараций. Они просто объявлены, но ничего не делают. Между ними передается какое то состояние. Отследить его путь крайне сложно. Может у меня подход не правильный, не знаю. Какой в этом смысл? Это же усложнение. Никаких преимуществ. Видимо Дейкстра был прав, сказав, что ООП плохая идея, которую могли придумать только в Калифорнии.

А нужно передавать buffer, т.е. сырые данные запроса http.

Это понятно. Почитал немного документацию, там кое что объясняется про объект запроса.

В Workerman гдето есть код по созданию объекта класса Request, и есть вызов onMessage с передачей туда Request.

Это тоже понял, почитав код.

Обработка http-запросов демоном на php скорее всего будет менее производительно чем через php-fpm

Откройте Techempower benchmark. Вчера тестировал workerman с помощью wrk, на одном ядре 50 000 запросов в секунду, на нескольких ядрах сотни тысяч. FPM с Nginx и стандартными настройками показывает 4 500 запросов в секунду.

Зря, не разберетесь с ООП, дальше не сможете продвигаться.

Буду разбираться. Посоветуйте что нибудь практичное для обучения. Чтобы по больше практики. От толстых книг клонит в сон.

Так у вас уже создан экземпляр класса, Workerman его создал. Весь смысл ООП, что вам не нужно вникать, что и как там делал Workerman - вам не нужно самому парсить запрос http, у вас есть есть готовый объект Request, с набором функций-методов, для удобного получения различных параметров запроса.

Понемногу складывается понимание. Спасибо за помощь!

[Vitsliputsli]

azuf,

Видимо Дейкстра был прав, сказав, что ООП плохая идея, которую могли придумать только в Калифорнии.

А "высокомерие измеряется в нано-Дейкстрах"©. Если серьезно, то неважно что он и о чем говорил в прошлом веке, ООП сейчас основная производственная парадигма.

Код в ООП стиле сложно понять. По крайней мере мне

Это всем так с непривычки. Потому что привыкли в программе мыслить другими критериями. Нужно просто писать код, и понимание придет само, по мере преодоления ошибок. Вообще ООП-шный код даже на незнакомом языке зачастую выглядит вполне понятным.

Откройте Techempower benchmark. Вчера тестировал workerman с помощью wrk, на одном ядре 50 000 запросов в секунду, на нескольких ядрах сотни тысяч. FPM с Nginx и стандартными настройками показывает 4 500 запросов в секунду.

Если бы все было так просто, но синтетические тесты мало информативны на практике. Что такое "запросы"? Это запросы к php или статика тоже? Не поверю, что веб-сервер на php отдает статику быстрее nginx. А если у нас сайт, то там большая часть это статика. Ок, допустим это api, и все запросы к php, "50 000 запросов в секунду" - это 20мкс на запрос, "4 500 запросов в секунду" - это 222мкс на запрос. За сколько у нас отрабатывает api-запрос, не беря тяжелое и совсем легкое, в среднем 50-100мс. Т.е.10-20 запросов в секунду, причем особо нет разницы для какого варианта, потому что php-код отрабатывает гораздо дольше расходов на веб-сервер. И это мы еще не тестировали как себя поведет php-шный вебсервер при реальных запросах, где работа с базой, ошибки, а иногда и фатальные и т.д. К примеру, fpm очень хорошо шарит память между своими процессами, а на сколько хорошо workerman это делает? Разумеется есть shared memory, но все же. Кажется, что цепочка nginx > php-fpm > php слишком длинная, и просто демон на php лучше, но в реальных условиях nginx может быть вообще не один, и шифровать надо, что проще всего опять в nginx сделать.

Буду разбираться. Посоветуйте что нибудь практичное для обучения. Чтобы по больше практики. От толстых книг клонит в сон.

Сложно чтото советовать, со временем забываешь, что помогало. Чисто субъективно

тут

Обобщенно, не зная уровня обучающегося - я бы начал с примитивных описаний ООП как оперирование с объектами реального мира, на самом деле это не так, но чтобы въехать помогает. Дальше писать код, читать код популярных решений, если не идет (а оно сразу не пойдет) - берешь более простые задачи или решения. Плохо если проект не живой, т.е. в него не прилетают постоянно правки по реальным требованиям, именно внесение изменений показывает, где ошибся.
Прочитать про распространенные ошибки, супер-классы и т.п. На первых порах лучше забыть, что статика вообще существует, а то есть риск свернуть не туда. Знал одного программиста из крутого банка, который писал статикой, по-сути он процедуры оформлял как методы, а классы были как namespace, и делал так много лет, но это было давно. Писать длинные методы по-привычке нормально, даже если их не разделить сразу, когда в будущем прилетят правки они покажут, что это надо было сделать, и где это надо было сделать. Использование примитивов не преступление, но только внутри объекта, если данные поплыли между объектами нужно быть очень осторожным. Иначе, когда с примитивом нужно будет передать еще данные, придется перепиливать весь путь, поэтому в таких случаях лучше сразу заложить объект, к нему прицепить дополнительные данные не проблема. Патерны не являются каким-то уникальным инструментом, но удобно в названии классов использовать название патерна, чтобы сразу было понятно для чего класс. Наследование это связь между родственными объектами, не стоит его использовать для других целей.
Прочитать про dependency injection, для начала понять, что зачастую удобнее объект передать из предыдущего обработчика, а не создать в текущем.
Прочитать про SOLID, и повторять их для себя время от времени. Дело в том, что в начале достаточно будет только буквы S, одно только соблюдение single responsibility убирает огромное кол-во проблем, остальное придет позже. А есть еще всякие GRASP и не только.
Что касается ООП в php. Private/protected/public обязательны всегда, и для методов, и для свойств. Static поначалу забыть, что он есть. Interface можно оставить на потом. Trait я бы не использовал вообще.
В общем, у меня получается, что нужно больше читать не как надо писать, а как не надо писать.
Я не знаю хороших книг по ООП, боюсь, в любом случае, только практика поможет. Из того, что вспомнилось. "Чистый код" - это что-то оторванное от жизни, вообще не стоит читать. "Совершенный код" - отличная книга, но вряд ли сильно поможет в начале изучения ООП. Патерны - это больше как принято называть устоявшиеся решения, лучше знакомиться после практики.

.

[azuf]

ООП сейчас основная производственная парадигма

Большинство не могут ошибаться?

Мнение большинства - всегда ошибочно, ибо большинство людей...

Дальше цитировать не буду, чтобы не нарушить правила.

Вообще ООП-шный код даже на незнакомом языке зачастую выглядит вполне понятным.

Он только выглядит понятным. Такой код состоит из множества запутанных изменяемых состояний, а это зло. Никакого выигрыша не дает, только усложняет, прибавляет лишнего кода.

Если бы все было так просто, но синтетические тесты мало информативны на практике.

Известная мантра. Любой реальный пример ее опровергает.

Это запросы к php или статика тоже?

Plain text. Не имеет значения. Никогда FPM даже не приблизится к производительности workerman или подобных апликейш серверов.

Не поверю, что веб-сервер на php отдает статику быстрее nginx.

Не знаю, не тестил, но вообще, сервера на C++ могут быть медленнее серверов на Go. И даже медленнее серверов на Node.js (uWebsockets.js). Просто потому, что хуже написаны. Вы ведь не заботитесь о производительности, правильно понимаю? И другие не заботятся. Просто пишут код и всё. Опытных системных программистов мало. Поэтому в 2025 году большинством используется устаревший во всех смыслах FPM. Заметьте, большинством. Так как большинство всегда ошибочно.

А если у нас сайт, то там большая часть это статика.

Смотря что понимать под сайтом. И смотря как будет устроен этот сайт. Блог это сайт? Блоги на Next.js даже без оптимизаций значительно производительней чем такие же, использующие php-fpm.

Ок, допустим это api, и все запросы к php, "50 000 запросов в секунду" - это 20мкс на запрос, "4 500 запросов в секунду" - это 222мкс на запрос.

Так это на 1 ядре! На 8 ядрах ~300-400к rps. То есть во много раз превосходит fpm + nginx. И это всего лишь hello world. Будь что сложнее, fpm и 1000 rps не покажет. Это вообще смешно.

За сколько у нас отрабатывает api-запрос, не беря тяжелое и совсем легкое, в среднем 50-100мс.

За столько Next.js полноценную страницу отрисовывает.

И это мы еще не тестировали как себя поведет php-шный вебсервер при реальных запросах, где работа с базой, ошибки, а иногда и фатальные и т.д. К примеру, fpm очень хорошо шарит память между своими процессами, а на сколько хорошо workerman это делает?

FPM в реальных приложениях показывает <1000 rps и все другие показатели соответствуют. Это как сравнивать скорость велосипеда и автомобиля.

[Vitsliputsli]

azuf, вы реально хотите вести техническое обсуждение с помощью казуистики и демагогии?.. Надергать фраз и агитировать не нужно, просто запустите ваше идеальное решение в работу и зарабатывайте миллионы, раз "мнение большинства - всегда ошибочно, ибо большинство людей..."

Большинство не могут ошибаться?

Могут. И глаза могут ошибаться, и мозг. Вопрос вероятности, кто с большей долей вероятности ошибается: те, кто ежедневно используют в промышленных масштабах решение, или некий azuf с форума с аргументацией "большинство могут ошибаться, значит я прав, т.к. не смог изучить ООП". Даже и не знаю...

Он только выглядит понятным. Такой код состоит из множества запутанных изменяемых состояний, а это зло. Никакого выигрыша не дает, только усложняет, прибавляет лишнего кода.

Насчет "выглядит понятным" вы уже лукавите, сами же говорили, что не осилили, значит не можете это оценить.
Что "зло"? Изменяемые состояния? Ну как бы без них никак не получится. "Запутанные" - зло? Так вы не запутывайте. Вообще запутать можно при любом подходе, а ООП предлагает очень годные инструменты, чтобы не запутывать. Почему вы решили, что выигрыша нет? Просто так захотелось? А "лишний код" вообще не аргумент.

Известная мантра. Любой реальный пример ее опровергает.

Ага, реальный пример: php7 быстрее php5 в 2-3 раза по синтетическим тестам, что на практике все знают. Вам бы и к своему синтетическому тесту следовало бы добавить реальный пример, глядишь и все бы стало понятно. А то получается: на статику забьем, https тоже выкиним, nginx здесь будем использовать, чтобы помедленнее, а там не будем, чтобы побыстрее, при этом выполнять код мы вообще не будем (оно ж логично, проверять выполнение кода, без выполнение кода).

Не имеет значения. Никогда FPM даже не приблизится к производительности workerman или подобных апликейш серверов.

Звучный лозунг. Прям красиво! Сразу видно техническое обсуждение вопроса.

Не знаю, не тестил, но вообще, сервера на C++ могут быть медленнее серверов на Go. И даже медленнее серверов на Node.js (uWebsockets.js). Просто потому, что хуже написаны. Вы ведь не заботитесь о производительности, правильно понимаю? И другие не заботятся. Просто пишут код и всё. Опытных системных программистов мало. Поэтому в 2025 году большинством используется устаревший во всех смыслах FPM. Заметьте, большинством. Так как большинство всегда ошибочно

Откуда вы знаете, о чем заботятся разработчики? Если бы вы читали мой предыдущий ответ, то поняли бы, что все намного сложнее, чем бессмысленное число, которое вас так зацепило.

Смотря что понимать под сайтом. И смотря как будет устроен этот сайт. Блог это сайт? Блоги на Next.js даже без оптимизаций значительно производительней чем такие же, использующие php-fpm.

Вы прям на лозунги горазды сегодня. А куда делся workerman, откуда ни с того, ни с сего Next.js? Вы так забавно пытаетесь увести в сторону...

Так это на 1 ядре! На 8 ядрах ~300-400к rps. То есть во много раз превосходит fpm + nginx. И это всего лишь hello world. Будь что сложнее, fpm и 1000 rps не покажет. Это вообще смешно.

Вам эти цифры прям покоя не дают, что вы даже не читаете что я пишу.

За столько Next.js полноценную страницу отрисовывает.

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

FPM в реальных приложениях показывает <1000 rps и все другие показатели соответствуют. Это как сравнивать скорость велосипеда и автомобиля.

Ага, это как сравнивать скорость велосипеда и бетмобиля.

[azuf]

Vitsliputsli, CGI, fastcgi - устаревшие подходы с низкой производительностью. Если я не прав, то можете привести пример когда php-fpm может нести большую нагрузку чем workerman и подобные серверы. Любое самое тормозное веб-приложение на таком сервере становится более производительным, чем аналогичное на php-fpm. Тот же Laravel на Swoole как пример. Не обязательно вдаваться в тонкости чтобы это утверждать. Нет примеров где php-fpm лучше, а если есть - покажите.

Не только я плохо отзываюсь о так называемом ООП, но и многие всемирно известные деятели в IT. Не только Дейкстра. Нужно привести их имена? По вашему современная индустрия лучше во всем разбирается чем лауреаты премии Тьюринга? Вероятно не все они могли отличать грамотные элегантные идеи от дурацких. У всех же разный тип мышления. Есть универсальные критерии для оценки. Простое лучше сложного. ФП - простое, ООП - сложное. Чем меньше кода - тем меньше проблем. ФП - мало кода, ООП - много кода. Человек не приучен мыслить в моделях вычислений с состояниями. Зато с детства приучается мыслить в аппликативных моделях вычислений. Потому ФП - естественная модель программирования, а ООП - нет.

У большинства нет своего мнения. Они просто следуют за кем то. Так было и будет всегда. Поэтому аргумент большинством - не аргумент.

[Vitsliputsli]

azuf, про workerman и fpm уже расписал. Но толку, вы все проигнорировали.

Не только я плохо отзываюсь о так называемом ООП, но и многие всемирно известные деятели в IT. Не только Дейкстра. Нужно привести их имена?

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

По вашему современная индустрия лучше во всем разбирается чем лауреаты премии Тьюринга?

По вашему вы лучше во всем разбираетесь, чем современная индустрия и лауреаты премии Тьюринга. Алан Кэй кстати именно за внедрение ООП получил ее, забавно, да?

Есть универсальные критерии для оценки. Простое лучше сложного. ФП - простое, ООП - сложное. Чем меньше кода - тем меньше проблем. ФП - мало кода, ООП - много кода.

Эта логическая ошибка называется предвосхищение основания, она у вас любимая. ФП не такое уж и простое, а ООП не такое и сложное.
По вашему идеальный программист тот, который не написал ни строчки кода.

Человек не приучен мыслить в моделях вычислений с состояниями. Зато с детства приучается мыслить в аппликативных моделях вычислений. Потому ФП - естественная модель программирования, а ООП - нет.

Вам когда в детстве давали инструкцию "купи хлеба и вынеси мусор", вы покупали хлеб и сразу его выбрасывли в виде мусора? Или все же знали, чтото о состояниях и обрабатывали их независимо?

У большинства нет своего мнения. Они просто следуют за кем то. Так было и будет всегда. Поэтому аргумент большинством - не аргумент.

Вы горазды на логические уловки, у меня не было такого аргумента.
Аргумент был, что с одной стороны хорошо зарекомендовавшее себя решение, используемое повсеместно, а с другой стороны недовольный с форума с аргументом "не освоил, но осуждаю".

[azuf]

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

Это уже пошли выкрутасы. Вы сами высказали, что мое мнение не авторитетное. Поэтому уточнил, что это не только мое мнение.

Алан Кэй кстати именно за внедрение ООП получил ее, забавно, да?

Вот только он против современного так называемого ООП. Его слова: "Я придумал термин ООП, но не имел ввиду C++". Есть еще его высказывания подобной направленности.

ФП не такое уж и простое, а ООП не такое и сложное.

И чем же ФП сложное? С любой стороны ФП проще. Потому что Лямбда-исчисление само по себе простая модель. Может ли быть полноценный удобный язык проще чем Лисп? Идея о том, что приложение это просто функция - простая. Даже такие сложные приложения как компиляторы/интерпретаторы прекрасно реализуются в таком стиле. Можно легко разложить такое приложение на функции и держать все это в голове. Подобное приложение в стиле современного ООП будет монструозным и запутанным, его невозможно будет держать в голове.

Вам когда в детстве давали инструкцию "купи хлеба и вынеси мусор", вы покупали хлеб и сразу его выбрасывли в виде мусора? Или все же знали, чтото о состояниях и обрабатывали их независимо?

Человек - не машина. Инструкции не любят читать и плохо понимают. Потому что императивность. Декларативный язык математики понимают намного большее количество людей. Только не надо цепляться за слова и утверждать, что ООП концептуально не является императивной моделью. ООП всё то же последовательное изменение состояний, только в другом виде.

используемое повсеместно

Это не означает, что идея не дурацкая. Повсеместно - значит используется большинством. Большинство - всегда ошибочно, потому что нет своего мнения, потому что толпа, у толпы нет интеллекта. Все побежали и я побежал. Самые лучшие идеи всегда не находятся на поверхности.

[Vitsliputsli]

azuf,

Это уже пошли выкрутасы.

Это да, например:

Вот только он против современного так называемого ООП. Его слова: "Я придумал термин ООП, но не имел ввиду C++". Есть еще его высказывания подобной направленности.

Дейкстра в прошлом веке точно не имел ввиду современную реализацию ООП, но вас же это не остановило.

И чем же ФП сложное? С любой стороны ФП проще. Потому что Лямбда-исчисление само по себе простая модель. Может ли быть полноценный удобный язык проще чем Лисп? Идея о том, что приложение это просто функция - простая. Даже такие сложные приложения как компиляторы/интерпретаторы прекрасно реализуются в таком стиле. Можно легко разложить такое приложение на функции и держать все это в голове. Подобное приложение в стиле современного ООП будет монструозным и запутанным, его невозможно будет держать в голове.

Я и не говорю, что сложное. Но и ООП не сложнее, объект сам по себе простая модель. Хотя причем здесь Лямбда-исчисление, когда мы рассматриваем подходы с точки зрения программиста, я так и не понял.
Какой вы "случайно" выбрали пример. Компилятор это та задача, где у ФП нет особых проблем, побочных эффектов практически нет, самих эффектов мало, просто сказка. А вот с ООП, ах да, там тоже никаких проблем, т.к. побочек нет, то и в ООП будут преобладать чистые функции. В принципе это будет почти тот же код, что и при функциональном подходе.

Человек - не машина. Инструкции не любят читать и плохо понимают. Потому что императивность. Декларативный язык математики понимают намного большее количество людей.

Предвосхищение основания. Опять ни на чем не основанные, безаппеляционные утверждения.
Эмпирически доказано, что инструкция это пока единственный способ выполнить задачу так как нужно. И это касается не только людей, но и машин. В том же декларативном sql периодически надо переходить на императивные прямые указания.

Это не означает, что идея не дурацкая. Повсеместно - значит используется большинством. Большинство - всегда ошибочно, потому что нет своего мнения, потому что толпа, у толпы нет интеллекта. Все побежали и я побежал. Самые лучшие идеи всегда не находятся на поверхности.

Это также не означает, что идея дурацкая.
Остальное уже полный бред.
Выключите компьютер, им ведь пользуется большинство, а значит ошибочно им пользоваться. Да и вообще все электричество. Можно и не есть, и не пить, ведь так вообще все делают!