[peferron]

I'm a big fan of static typing, including sum types. But can someone explain to me what's so great here?

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):

    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
    ...

"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.

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.

And if we really need it, it's not like JS cannot do it:

    function apply(action, todos) {
        switch (action.type) {
            case 'ClearCompleted':
                return todos.filter(todo => !todo.completed);
            case 'DeleteItem':
                return todos.filter(todo => todo !== action.todo);
            ...
        }
    }

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.

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 could do but chooses not to.

(Regarding footnote #4: Swift also has sum types and is fairly popular.)

[L8D]

You're not missing anything. What you and the author are describing (in terms of pattern/architecture) has existed for quite a while but was widely popularized recently by Facebook's [Flux](https://facebook.github.io/flux). The author is either naive towards current state of the JavaScript landscape or their just being arrogant about what is actually unique to 'functional' programming.

[christopherscot]

Yep, was thinking the same exact thing when I saw "actions".

[codygman]

> it's simpler to directly call the right function, rather than over-engineering things with a short-lived intermediary representation.

That intermediary representation can enforce that your input is valid. Then you can create functions based on that intermediary representation and act as if your data is valid because it is.

The intermediary representation can also ensure you cover all cases if your states are encoded with sum/product types thanks to exhaustiveness checking in supported languages.

> 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 could do but chooses not to.

JS can't turn runtime errors into compile time errors because it doesn't have a compiler or a powerful type system. In fact it has a very weak/dynamic type system.

[chriswarbo]

Really, the author is in favour of polynomial types (sums of products); the emphasis on sums is probably because tuples/records/arrays/etc. are already quite well known.

To see the distinction, notice that many Actions have some associated data:

    data Action a
      = ClearCompleted
      | DeleteItem ItemId
      | EditItem ItemId
      | EditItemCancel ItemId
      | EditItemDone ItemId a
      | Filter (Maybe ItemStatus)
      | NewItem a
      | NoAction
      | Refresh
      | Toggle ItemId
      | ToggleAll

In your analogy, the `action` value is actually quite complicated: it's an object (record) containing a field called "type" containing a string; if the "type" field contains the string "DeleteItem" then the action object also contains a "todo" field, containing an item ID; if the "type" field contains the string "EditItem" then the action object also contains a "todo" field, containing an item ID; and so on.

This is known as a "dependent record", and requires a much more elaborate type system than polymonial types. In fact, without careful consideration, dependent type checking can end up being undecidable!

Compare this to the polynomial type, where the parameters (item IDs, etc.) are right there in the value. We can never have an Action without the corresponding parameters (if we try, we'll end up with a function rather than an Action, thanks to Currying). We can never switch the type of an action while forgetting to change the parameters; etc. Plus, of course, we've denoted a finite set of actions, rather than relying on strings (AKA "stringly typed" programming).

Another point to note:

> it's simpler to directly call the right function, rather than over-engineering things with a short-lived intermediary representation.

Of course it would be simpler, but the entire point of the exercise is to use MVC to separate concerns, even though it's clearly overkill. If we're going to do MVC anyway, then the Action type provides a very simple interface between the Controller and the Model: the Controller just spits out an Action, the Model just receives an Action; no need for any further coordination. Plus, it's all really easy to reason about and type check.

[wz1000]

This article doesn't really do justice to Haskell's type system, but the main benefit I achieve is that with a properly defined type, it is often impossible to put the internal state of the program in a inconsistent state, eliminating a large class of bugs and crashes.

[creichert]

It's about encoding the specific problem in the safest way possible. Typos and missing cases represent a very large set of trivial bugs which crop up in many situations like teams, changing requirements, scale, and reuse. The JS function will continually suffer from all of these and your apply function is oversimplified solution. If the bug can be detected and encoded by the computer, why not utilize that?