So tuple() for lists takes two lists and gives all combinations with one item from each list.
We could call it product.<p>For options it takes two options and return an option with a tuple of values if both are set, otherwise it return None. We could call it bothOrNone.<p>For Either... It's not unambiguous, but presumably it's similar to option, returning either a tuple of Rights, or the first Left of the arguments, following convention of using Left for errors. We could call it bothRightsOrALeft.<p>For State I'm just guessing. getBothWithStateOfLast?<p>These may all have interesting mathematical similarities, but the way you would use them in a program would be pretty different. I don't think you are making your program clearer by giving them all the same name.<p>Sometimes reading "overabstracted" code can feel similar to reading assembly code. Sure, add and mov are simple operations with a clear definition of input and output, just like flatMap and fold, but they say very little about the programmer's intent in using them. If you give me a chain of them without any comment, I'll need to work backwards to figure out what you're actually trying to accomplish.
Interesting article and funny to see the shout out to Elm. I think the first few code samples made it very clear that Elm is missing something, at least for this type of generic programming, namely higher order types. Too many times I had to re-implement something that could have been solved in a generic fashion. Kind of similar to how Go programmers have to reimplement instead of generalise.<p>It is actively discussed in the Elm community (<a href="https://github.com/elm-lang/elm-compiler/issues/1039" rel="nofollow">https://github.com/elm-lang/elm-compiler/issues/1039</a>), but with a Wait-And-See-Approach. In my opinion, this is really laudable, as it signals readiness to add higher order types, and at the same time keeps developer friendliness of the resulting feature extension in mind.
What I wish to see in these blog posts are real-world examples. My day job is coding an MVC app in Rails / Ember. Fine, I won't be able to get past Chapter 11 in a book, but what am I REALLY missing out on? Are these solutions meant for a different problem set, or would I be able to use these concepts in my day-to-day (assuming we were written in a Scala, Haskell, etc.)?
I really hope that higher-kinded types can be brought to TypeScript. I really want that kind of power on the front-end, but I can't count on getting an entire team up to speed with PureScript.
I'm really confused is he saying that fsharp can't have functional combinators? That seems incorrect. Also the title is just generally abrasive. I could just as well say scala doesn't natively support dependent types, so clearly it's between F* and giving up.