I've recently used Elm for a real-world internal tool and was looking over the PureScript documentation today to see whether it'd be worth looking at PureScript in the future. I was disillusioned with the boilerplate of writing JSON decoders and encoders in Elm.

I quickly stumbled across this:

https://github.com/slamdata/purescript-halogen/blob/master/G...

This is pretty much the Elm Architecture, except fully understanding every detail there requires the reader to be conversant with some pretty hairy concepts, including free monads and the Free functor. That's not just something that's under the hood. It's built right into the user-facing API, and the user even has to tend to this free construction when writing `eval` functions by manually writing lines like `pure next` or `pure (continue value)`, which occur in the first example.

It seriously concerns me that the user will have to write lines that they couldn't truly understand without understanding free monads, because frankly nobody new to Haskell and PureScript is going to be comfortable with free monads until they've spent some serious time with the language.

I happen to be very well-versed in Haskell so this stuff is not an issue for me -- in fact the use of Free here is not only clever but kind of beautiful -- but I wouldn't really want to onboard someone onto a PureScript project who'd never used Haskell or PureScript before and didn't even know what a functor was. "Why do I have to write this `pure (continue value)` line? What does that mean?" -- "Oh boy... grab a seat and clear your schedule."

Some boilerplate for JSON decoding looks pretty tame in comparison, to be honest.