shared mutable state

а как вы в ФП стиле (в стиле ли?) сайд-эффекты генерите?
ну, получается что-то вроде такого кода, но какой-то красивой возможности пропихнуть эффект, который основан на чем-то из нового состояния - невозможно.

например, состояние копит массив из 15 значений, потом отрезает их, формирует объект и кладет в базу, а массив начинает копить заново.

так вы утверждаете, что в котлине можно делать ФП

В моем определении, распрекрасный

а как вы в ФП стиле (в стиле ли?) сайд-эффекты генерите?
ну, получается что-то вроде такого кода, но какой-то красивой возможности пропихнуть эффект, который основан на чем-то из нового состояния - невозможно.

например, состояние копит массив из 15 значений, потом отрезает их, формирует объект и кладет в базу, а массив начинает копить заново.

Ну ты считаешь, что миф. А я дал определение и радуюсь.

а что такое StateUpdate?

можно на fun consume(vararg effects: Any) заменять
просто обертка смены состояния, которая содержит новое состояние и эффекты

тогда пожалуйста не плюйте им в других, а то мало ли, кому-то понравится, будут хуйню делать

кек, а просто Pair не подошел?)

Вот сегодня буквально, надо собирать мапу было из разных кусков. Сначала написал какую-то ересь в духе ((a?.keys ?: emptySet()) + b.keys).asscociate{...}. А потом просто сделал мутабельную мапу и в нее набил элементы. На порядок читабельнее получилось.

Довольно часто нужно, с мапами очень сложно в фп стиле

чем это не фп?

Ну можно же. но да, далеко не всегда обосновано

Господа, вы по-моему забываете о первопричинах появления/доминирования тех или иных технологий)
Обычно какая-то технология или парадигма появляется в ответ на возникшую проблему. Когда все устали писать многостраничные листинги ассемблера, все подумали: «Давайте будем куски кода писать в подпрограммах, а подпрограммы распихивать по файликам и будет нам счастье». Здравствуй Алгол и структурное программирование.

Потом сложность расчётов, которые люди захотели делать на компах выросла ещё больше и деления программ на блоки кода стало недостаточно. В ответ на эту проблему появляется что? Правильно - ООП вместе с симулой и Smalltalk. Они пытались решить одну задачу - сделать так, чтобы сложные программы было легче писать.
После, как эволюция (или недопонимание) появляются плюсы, джава и тд, которые немного перекраивают понятия ооп, но преследуют всю ту же цель - уменьшить нагрузку на мозг программиста, так как он не способен адекватно воспринимать такие объемы информации, какие стали писать программы.

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

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

К чему я это всё - если вы говорите что «ФП не нужон» то вам оно действительно не надо. И то, что любую технологию (вообще любую) иногда пихают не на совсем положенное место все знают. НО! Есть софт, задачи, разработчики для которых фп - охуенное решение их проблем.

Когда появился smalltalk, все тоже говорили что ооп нах никому не нужно и наверняка в BBS’ах также срались о его необходимости. Однако поглядите

формально, да, StateUpdate == Pair
чет мне отдельный тип для такого больше понравился

но вопрос именно в том, как сформировать эффект на основании старого/нового состояния

глядя на conduitlurker, появилась такая мысль:
1. отдать в эффект предыдущее состояние и уже внутри чекнуть, удобвлетворяет ли этот массив условиям для расчета и сохранения
2. новое состояние сформировать просто через when с проверкой на достижение лимита - очистить, если привысили лимит, или продолжить наполнение

Я тут, кстати, пока были обсуждения по мульти-ресиверам, придумал новое определение: на ряду с чистыми функциями, можно говорить о чистых скоупах. То есть тех, в которых есть изменяемое состояние, но так, что бы это состояние не убегало за предел скоупа. Инетересно, что -то такое формулировалось? Наверное да, ведь в реакте по сути оно и есть.