Методы update/view у модели, по-хорошему, должен быть методом тайпкласса. В этом случае удастся убрать весь шум из использования tea-combine и выводить update/view автоматически, если модель построена из сумм, произведений и других моделей.

А если ещё HKT добавить, то можно сделать type Fix f = Fix (f (Fix f)), сделать для него инстанс и выкинуть из Recursive примера всю логику update/view, кроме вертикального склеивания заголовка с поддеревом.

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

> выводить update/view автоматически, если модель построена из сумм, произведений и других моделей
это звучит вкусно, да

А так же делать map, foldr и прочее над любыми Functor/Foldable-контейнерами

я на самом деле спрашиваю не столько в разрезе Elm, сколько для определения родмапа одного внутреннего проекта, который очень сильно Elm-like, но используется на бекэнде для описания бизнес-логики

имплементации похожи до смешения, поэтому и проблемы заимствованы те же

Вот что я скажу: тайпклассы это круто. Я уже и не помню, как я без них жил

Ну тут только Моноид бы пригодился

Меня лично больше всякие приземлённые штуки напрягают вроде невозможности сделать мапку с кастомными ключами

Прям дико раздражает

s/только/не только/

Да, не хватает класс Ord

Аппликатив нормальный, фолтаблы с траверсаблами

Дадада

Всё вот это. Alternative ещё иногда

Это довесок к аппликативу :)

Его наличие подразумевается

А я всё время пытаюсь сделать import Control.Alternative

Я уж молчу, что в хаскеле тайпклассы ещё и с дерайвингом идут. Дерайвить маршаллинг — бесценно

Это только мазохистам нравится писать билдеры JSON для каждого типа