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 :) )
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. :)
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
Wow, those are great!
I like how you can translate the symbols to types pretty straightforwardly (sort of):
-- Col representing a collectionfilter:: Col a -> Col aflatten:: Col (Col a) -> Col amap :: (a->b) -> Col a -> Col breduce :: (a -> a -> a) -> Col a -> agroupBy 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 bThe 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 :) )Is this a sign that more and more functional programming concepts are leaking into mainstream languages?
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. :)
hopefully! :)