I'm a big fan of static typing, including sum types. But can someone explain to me what's so great here?<p>The highlight of the article is having a unique Action sum type instead of a myriad of separate functions. But the action still has to be processed by a myriad of separate equations (is that the correct Haskell term? Not familiar with the language):<p><pre><code> apply ClearCompleted tds = over todosItems (Map.filter (\x -> view itemStatus x /= Completed)) tds
apply (DeleteItem x) tds = over todosItems (Map.delete x) tds
apply (EditItem x) tds = set todosEditing (Just x) tds
...
</code></pre>
"Only one of the 68 frameworks defined an Action" is probably because it's simpler to directly call the right function, rather than over-engineering things with a short-lived intermediary representation.<p>If actions need to "be serialized, recorded for later analytics, and generated automatically" then it makes much more sense. But this is a TODO sample app. YAGNI.<p>And if we really need it, it's not like JS cannot do it:<p><pre><code> function apply(action, todos) {
switch (action.type) {
case 'ClearCompleted':
return todos.filter(todo => !todo.completed);
case 'DeleteItem':
return todos.filter(todo => todo !== action.todo);
...
}
}
</code></pre>
The above has probably been done a billion times in one form or another. Of course it's not safe from typos in the case strings or missing cases, but that's a broader issue with JS in general, not specifically related to sum types.<p>I'm not trying to shoot down Haskell here, I really wish someone will point to something I'm missing and make it click. But right now it just looks like over-engineering that JS <i>could</i> do but <i>chooses</i> not to.<p>(Regarding footnote #4: Swift also has sum types and is fairly popular.)