> We do not make the (unwarranted) assumption that this transformation can or should be expressed as a pure function. While that would be nice, there are many reasons why this is not a good idea, some pretty obvious.
So obvious they are left as an exercise for the reader?
This whole article seems to be based on the idea that pure functional programming is absurd and impossible, and this is just obvious and doesn't need to be shown. For someone who has written a decent amount of Elm, it certainly isn't obvious to me.
The article is explaining those reasons, which the author feels are obvious but he spells out nonetheless. The gist of his argument is that because UI is not a pure function of a little pile of centrally defined state, React has to come up with lots of new concepts and mechanisms to wallpaper over the conceptual gap. Hence his table which by the end is boiling down to "OOP toolkits don't need this" alongside explanations of very complex FP approaches.
Well, in reading it, those reasons didn't seem to follow on from those points to me. They don't really address working in a pure way from state, just specific things they don't like in a particular implementation.
Specifically "UI is not a pure function of a little pile of centrally defined state" is just this assumption that isn't true, Elm literally gives you no choice, you only have that, and it works, so it clearly can be.
It also ignored all the value you gain from doing it that way. As I say, I've written a fair bit of Elm at this point, and it can often be verbose which can be annoying, but it is actively not complex in the best way, with it being very easy to reason about and bulletproof once it compiles.
I should have specified "for UI", I suppose, but the quote I gave, and:
> The idea of UI being a pure function of the model seems so obviously incorrect, and leads to such a plethora of problems, that it is a bit puzzling how one could come up with it in the first place, and certainly how one would stick with it in face of the avalanche of problems that just keeps coming. A part of this is certainly the current unthinking infatuation with functional programming ideas. These ideas are broadly good, but not nearly as widely or universally applicable as some of their more starry-eyed proponents propose (I hesitate to use the word "think" in this context).
So obvious they are left as an exercise for the reader?
This whole article seems to be based on the idea that pure functional programming is absurd and impossible, and this is just obvious and doesn't need to be shown. For someone who has written a decent amount of Elm, it certainly isn't obvious to me.