Кругозор это, конечно, очень хорошо. Но только вот все равно

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

Не соглашусь

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

Думаю, что проблема ООП в строении абстракций очень высоко -- ближе к реальной жизни. Это приводит к коду которую сложно композировать и часто нужно вещи заново писать. А ФП строит концепты ниже -- ближе к маленьким, но часто встречаемым проблемам. Например: Отсутсвуещие значения (Maybe), значения которых можно комбинировать (Semigroup & Monoid), складывать в одно (Foldable), функции корых можно использовать везде одинаково без страха (Pure functions), части котда которых можно рефакторить без страха (Referential Transparency) и тд тп

Где вы видели в последний раз в реальном мире фабрику фабрик?

Выигрывает

Сложные термины возникают не каждый день и далеко не у всех(как я понял, только у тех, кто хочет, чтобы они фигурировали) Кругозор даже сам по себе - это классно и полезно, потому что: 1) тебе каждый день приходится принимать какие-то решения. Лучше прокачан кругозор - лучше решения будут получаться в среднем по больнице 2) скорее всего, ты и так используешь ФПшные приблуды. Ну или они могли бы упростить тебе жизнь в некоторых моментах(ставь класс, если хотя бы раз в жизни ставить куда-нибудь @NotNull или хотел какой-нибудь асинхронщиной по управлять и тд). Зацепил лучше фп кругозором - больше/легче проблем решаешь, где надо с фп пересечься К тому же, ты в скалачатике. Тебя тут не заставят отрекаться от опп (скорее всего)

А вы Zygohistomorphic Prepromorphism?))

Паттерны - уже более высокий уровень использования. Если смотреть в корень, в основу, то ООП вполне себе обращается к понятиям из реальной жизни

Rajven
https://ws.apache.org/xmlrpc/apidocs/org/apache/xm...

В реальной жизни, а не в программистких фантазиях

Использовал apache xml-rpc на реальном банковском проекте буквально в прошлом году. Или по-вашему легаси не существует?

По моему, фабрик фабрик не существует в реальном мире, так что и кивать на моделирование реального мира как преимущество ООП несколько... Неразумно

А, в реальной жизни как в реальной жизни, а не как на практике. Тогда мои извенения.

3D принтер, способный напечатать сам себя? Пока не существует, но к этому стремятся...

.

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

Objects are poor man's closures

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

То что вы про ООП говорите это миф. В фп сложных мат терминов нет если вы не берете хаскель и теоркат. А это далеко не главное в фп и вообще не совсем суть фп

.

у вас изначально процедурное, а у кого-то изначально функциональное

Вот есть у меня вот такой тезис, уже не раз описаный.

Если нам надо держать реализацию того, что мы вызываем в данной единице кода, то он сложен и стремится к повышению сложности. Уверена, что вы видели это и не раз

допустим, но не понятнро как это вытекает из "Если у нас код не является чисто функциональным и мы не следуем моим идеям ооп, то он скатывается в процедурный рано или поздно, как минимум в своих частях"

Процедурный код - это код, в котором программа описана данными и операциями над ними. Если мы должны держать в голове вызываемые куски кода, то у нас состояние не инкапсулировано. То есть у нас данные и операции над ними. То есть процедурный код

как будто промт чат гпт прочитал

Да, я не редко пишу слишком топорно и математично, знаю