1. 17

  2. 4

    One of the best parts of the article is the “Operations Catalog” near the bottom, with concise pictorial representations of the discussed operations. http://martinfowler.com/articles/collection-pipeline/#op-catalog

    1. 2

      Wow, those are great!

      1. 2

        I like how you can translate the symbols to types pretty straightforwardly (sort of):

        -- Col representing a collection

        filter:: Col a -> Col a

        flatten:: Col (Col a) -> Col a

        map :: (a->b) -> Col a -> Col b

        reduce :: (a -> a -> a) -> Col a -> a

        groupBy is a little more problematic: either the result of the function has an ordering and you return the same collection with that ordering or you lose the nesting collection and return a map as the article indicates, but I guess the symbol is somewhat understandable:

        groupBy :: Ord b => (a -> b) -> Col a -> Col (Col a)

        groupBy :: (a -> b) -> Col a -> Map (Col a)

        flatMap is the one I don’t think the pictorial representation gives much grasp of what’s happening, as the “shape” of the function is what differentiates it from map

        (I guess the pic should be something like f: o => [ x ... ] )

        flatMap :: (a-> Col b) -> Col a -> Col b

        The interesting part is when you replace Col with any abritrary “thing that can have other things ”“inside”“ ” (formally, any type constructor of kind *->* if I got it right :) )

      2. 3

        Is this a sign that more and more functional programming concepts are leaking into mainstream languages?

        1. 3

          Yes, I think that’s been a big theme of language design and use in the last decade. (Lambdas in Java, Ruby style settling on filter/map/reduce rather than loops, many JS libraries like React/Elm/Om)

          I think it’s been a big improvement, and I’m diving into functional programming (and submitting lots of lobste.rs stories) to get ahead of it. :)

          1. 2

            hopefully! :)