5 ms·

And yet the following is profoundly more intelligible to a wide range of functional programmers: -- Using Elm syntax pipeline : List (Int -> Int) pipeline =

And yet the following is profoundly more intelligible to a wide range of functional programmers: -- Using Elm syntax pipeline : List (Int -> Int) pipeline = [(\x -> x + 3), (\x -> x * 2), abs] applyPipeline : Int -> Int applyPipeline value = List.foldr (\func val -> func val) value pipeline -- or more succinctly applyPipeline_ value = List.foldr (<|) value pipeline Getting lost in the mathematical abstractions is really no help here. In niche circumstances I'm sure it's great, but like.... not here.

willtim 10y ago
Yes it is a bit unnecessary in the simple list example above, but Endo becomes useful when using arbitrary nested Foldable structures and when composing monoids, e.g a pair of monoids is also a monoid. In other words, it becomes useful at scale. To quote from Paul's post: "The trouble is that very often, the sorts of examples that are easy to discuss aren’t of sufficient scale to reveal any major differences between A and B."
evincarofautumn 10y ago
I agree Endo doesn’t add a lot of value. I tend to use “compose = foldr (.) id” for this, if it’s even necessary—most of the time my “pipelines” are not dynamic, so there’s no reason to put them in a list in the first place.
- montanonic 10y ago
  This brings to mind what I consider to be perhaps the biggest issue with Haskell (I'm not accusing you of this, you've done a great job explaining): due to language expressiveness, overly generic code is far too often a baseline, when it really shouldn't be. The language itself doesn't demand we write code this way, but the community, understandably, loves to be as expressive as possible in many cases. But all of this comes with a cost of cognitive overhead that seems to rarely be worth paying. Elm was an enlightening experience for me, having started with Haskell, because it helped me to realize just how little I ever took advantage of a lot of the very generic Haskell code, and how far the simplest of functions and types could take you in the overwhelming majority of cases.
  - kqr 10y ago
    I like overly generic code when I refactor. The more generic, the fewer edge cases possible!

willtim 10y ago

Yes it is a bit unnecessary in the simple list example above, but Endo becomes useful when using arbitrary nested Foldable structures and when composing monoids, e.g a pair of monoids is also a monoid. In other words, it becomes useful at scale. To quote from Paul's post: "The trouble is that very often, the sorts of examples that are easy to discuss aren’t of sufficient scale to reveal any major differences between A and B."

evincarofautumn 10y ago

I agree Endo doesn’t add a lot of value. I tend to use “compose = foldr (.) id” for this, if it’s even necessary—most of the time my “pipelines” are not dynamic, so there’s no reason to put them in a list in the first place.

montanonic 10y ago
This brings to mind what I consider to be perhaps the biggest issue with Haskell (I'm not accusing you of this, you've done a great job explaining): due to language expressiveness, overly generic code is far too often a baseline, when it really shouldn't be. The language itself doesn't demand we write code this way, but the community, understandably, loves to be as expressive as possible in many cases. But all of this comes with a cost of cognitive overhead that seems to rarely be worth paying. Elm was an enlightening experience for me, having started with Haskell, because it helped me to realize just how little I ever took advantage of a lot of the very generic Haskell code, and how far the simplest of functions and types could take you in the overwhelming majority of cases.
- kqr 10y ago
  I like overly generic code when I refactor. The more generic, the fewer edge cases possible!