Здравствуйте, gyraboo, Вы писали:

G>Здравствуйте, dsorokin, Вы писали:

D>>И заметь одну важную вещь. Почти нигде в документации в подобных случаях не указывают на прямую связь ФП. Если тебе напишут, что Java Stream — это моноид, то тебе такое понравится?

G>А как ответить на такой вопрос: если из этого моноида вызвать транзакционный jpa-код, к какому треду и связанному с каким тредом и tx-менеджером его соотнесет EE-фреймворк, от этого ведь будет зависеть логика коммита/отката? И вообще, этот моноид исполняется на треде реквеста или на вторичном треде из некоего пула? А этот пул какой вместимости? Не станет ли он узким местом? А с секьюрностью что будет, если секьюрити контекст с авторизацией привязан к треду реквеста, он што, потеряется и тред моноида будет выполняться анонимно? Значит, код моноида подвержен атакам? Секьюрность контекста у моноида вообще можно обеспечить гарантией java sdk, как у классического threadlocal, или это обеспечивается лишь псевдо-гарантией на уровне самописных реактивных библиотек? А шо там у моноидов с OneToMany/ManyToMany? Не поддерживается, и нужно вручную реализовывать? Надо же, какая досада, но зато функционально! А шо там у них с пробросом эксепшнов? А стектрейс человеческий (кто это когда и с чем по цепочке вызвал) можно посмотреть без установки в ide спец-приблуд? Нельзя, но зато функционально!
G>Столько вопросов, столько рисков, это же не просто голые computation, может надёжнее не открывать эту кротовую нору и писать enterprise-код в общепринятом процедурном стиле с анемичной моделью?

Если честно, то я немногие слова разобрал. Но скажу так, что транзакции, пул потоков и исключения (даже бывают асинхронные исключения) в полном достатке присутствуют и в функциональных языках, например, в Haskell. Они же сбоку. Идее о композиции вычислений не противоречат.

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

Ты летал на самолете на высоте 10 километров при смене дня и ночи? Там будет такое явление, как "терминатор", когда день и ночь поделили ровно словно масло ножом. Но на самой земле свет рассеивается, и такой жесткой границы нет. Так и нет жесткой границы между функциональным стилем и императивным. Более того, их по-моему даже часто неправильно противопоставлять друг другу. Это как есть профиль и анфас лица человека. Лицо человека — это как задача программирования, а смотрим мы на нее сбоку или прямо — саму задачу не особо-то и меняет. Просто могут быть разные пути решения для достижения одной цели. Так, и функциональное программирование и императивное — это иногда разные пути достижения одной цели. Часто они даже работают в тандеме.

Есть такое понятие как шаблоны проектирования. Считай, что моноид — это тоже такой шаблон. Просто слово шаблон/паттерн так часто использовали, часто без понимания сути ради соблюдения формы, что от этих слов уже порядком тошнит. И в мире функционального программирования эти слова не особо-то и любят, но по своей сути все эти моноиды, монады, полугруппы, стрелки и т.п. — это ведь тоже шаблоны, преимущественно, шаблоны вычислений, которые можно комбинировать друг с другом, создавая целое из малых кусков, где целое уже больше суммы частей. И там тоже есть место всем этим транзакциям, исключениям, потокам исполнения и тому подобному.

Ты так не дели мир на черное и белое! Все куда сложнее и проще одновременно