3 ms·

For me, the important point is that higher-order functions (map, fold, etc.) compose well with other higher-order functions, whereas hand-coded recursion doesn'

For me, the important point is that higher-order functions (map, fold, etc.) compose well with other higher-order functions, whereas hand-coded recursion doesn't really compose with itself or anything else. Using recursion in a functional language is a little like using a for loop in an imperative one.

fogus 16y ago
hand-coded recursion doesn't really compose with itself or anything else That's not true. If you look at the implementations of the functions composed in the OP, you'll see: * `partition-by` implemented via recursion * `comp` implemented via recursion * `map` implemented via recursion * `repeat` implemented via recursion The point is that recursion should be a last resort[1] and something squirreled away in combinators. [1]: Last resort is a flexible term, but my meaning should not be taken as "never use recursion", just be thoughtful about it.
- barrkel 16y ago
  I think you missed Tim's point. A better analogy might be duplicating code vs writing a function once and reusing it. Hand-written recursion with the operation inlined is not usually very reusable (i.e. composable); however, if you factor out the recursive traversal and parameterize it by the operation to be performed, it composes much better. But at that point you're writing a library routine, rather than logic specific to the task at hand. (As an aside: in my way of thinking about software design, generic library code is "free" - it doesn't count towards the number of lines of code for the actual task being solved. I try to make as much of the software that I design library-like, and the core of the app not a lot more than composing these pre-fabricated bits, as possible, potentially even to my detriment in short-term productivity. But this approach handles scale much better, in my experience.)
  - deleted 16y ago
    [deleted]

fogus 16y ago

hand-coded recursion doesn't really compose with itself or anything else That's not true. If you look at the implementations of the functions composed in the OP, you'll see: * `partition-by` implemented via recursion * `comp` implemented via recursion * `map` implemented via recursion * `repeat` implemented via recursion The point is that recursion should be a last resort[1] and something squirreled away in combinators. [1]: Last resort is a flexible term, but my meaning should not be taken as "never use recursion", just be thoughtful about it.

barrkel 16y ago
I think you missed Tim's point. A better analogy might be duplicating code vs writing a function once and reusing it. Hand-written recursion with the operation inlined is not usually very reusable (i.e. composable); however, if you factor out the recursive traversal and parameterize it by the operation to be performed, it composes much better. But at that point you're writing a library routine, rather than logic specific to the task at hand. (As an aside: in my way of thinking about software design, generic library code is "free" - it doesn't count towards the number of lines of code for the actual task being solved. I try to make as much of the software that I design library-like, and the core of the app not a lot more than composing these pre-fabricated bits, as possible, potentially even to my detriment in short-term productivity. But this approach handles scale much better, in my experience.)
- deleted 16y ago
  [deleted]