<story><title>Higher-kinded types: the difference between giving up and moving forward</title><url>http://typelevel.org/blog/2016/08/21/hkts-moving-forward.html</url></story><parent_chain></parent_chain><comment><author>tveita</author><text>So tuple() for lists takes two lists and gives all combinations with one item from each list.
We could call it product.&lt;p&gt;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.&lt;p&gt;For Either... It&amp;#x27;s not unambiguous, but presumably it&amp;#x27;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.&lt;p&gt;For State I&amp;#x27;m just guessing. getBothWithStateOfLast?&lt;p&gt;These may all have interesting mathematical similarities, but the way you would use them in a program would be pretty different. I don&amp;#x27;t think you are making your program clearer by giving them all the same name.&lt;p&gt;Sometimes reading &amp;quot;overabstracted&amp;quot; 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&amp;#x27;s intent in using them. If you give me a chain of them without any comment, I&amp;#x27;ll need to work backwards to figure out what you&amp;#x27;re actually trying to accomplish.</text></comment>
<story><title>Higher-kinded types: the difference between giving up and moving forward</title><url>http://typelevel.org/blog/2016/08/21/hkts-moving-forward.html</url></story><parent_chain></parent_chain><comment><author>justusw</author><text>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.&lt;p&gt;It is actively discussed in the Elm community (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;elm-lang&amp;#x2F;elm-compiler&amp;#x2F;issues&amp;#x2F;1039&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;elm-lang&amp;#x2F;elm-compiler&amp;#x2F;issues&amp;#x2F;1039&lt;/a&gt;), 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.</text></comment>