4 ms·
I love these kinds of articles. I know about partial function application, and I'm already sold on the merits of higher-order functions, et al. (A one-two punc
by wonderzombie 14y ago
I love these kinds of articles.
I know about partial function application, and I'm already sold on the merits of higher-order functions, et al. (A one-two punch of Haskell and Clojure sold me.) Maybe that's why it's nice to see other ways of describing or encoding these concepts— it was a neat little "aha" moment when we got to pluck. Immediately it reminded me of how, in Clojure, keywords are functions.
For those of you who aren't familiar, Clojure has symbolic keys like in Ruby (e.g. :foo), called keywords. So given the 'inventories' variable in the pluck() example, you could write:
(map #(get % :oranges) inventories)
The #(get % :oranges) syntax is an anonymous function, invoking get to retrieve :oranges from each inventory in inventories. But it turns out you don't even need to do that. You can just do this instead:
(map :oranges inventories)
Anyway, I guess what's funny to me is that I used JS for a little while, and I liked it pretty well. It's only in retrospect that I start to see the extent to which it seeded my brain with these patterns.
- raganwald 14y agoI left "compose" out of this excerpt, but in the book: var pluck = compose(splat, get);
- wonderzombie 14y agoCompose is another piece I wish more languages had. The functional style of small, orthogonal functions has changed the way I write code, but in many imperative languages, function composition as I know it just doesn't exist. And sometimes that disparity is a real bummer. You can get close in dynamic languages, as with JS, Ruby, and Python. But if we're talking about Java or C++, it's just not happening, not without a bunch of work and not within an existing codebase where the introduction of new styles might actually be counterproductive.