4 ms·

There is truth to giving more thought in functional programming. Writing recursive functions requires thought especially when implementing tail recursion.

by dbul 18y ago

eru 18y ago
I tend to avoid explicit recursion. It's nearly as much to think about as the iterative loops you are trying to escape from. Combinators like map, filter, foldl/foldr keep your mind free of clutter.
- dbul 18y ago
  I suppose my point was that iterative loops didn't make you think very much and so sometimes you become careless as was the case with that Zune bug from January. Recursion keeps you on your toes and if you practice enough then you can manage so-called clutter well and still have room to think.
  - eru 18y ago
    Perhaps I am too much into Scheme and FP in general. I have come to view iterative loops as special case of tail recursion, necessary because some languages do not support general proper tail recursion. Iterative loops and explicit recursion make you think about stuff you'd rather not think about. For example if I want to apply a function on a number of items: > for(int i=0;i<n;i++) > b[i]=f(a[i]); plus managing the length of the array and creating the new array b in the first place. With explicit recursion (in Haskell syntax): > foo :: [a] -> [b] > foo [] = [] > foo (x:xs) = (f x: foo xs) You no longer have to care about the length of the list or an index. But you still have to think about where you place the recursive descent and how to make it tail recursive. And the same function with combinators: > foo :: [a] -> [b] > foo = map f Perhaps you will have to think a bit harder to write such a version, especially when you use the more advanced combinators like foldl/foldr, but reading is a pleasure. Of course you also have to define the combinators somewhere --- but those definitions are way easier when they are not mirred in domain specific details.
- gord 18y ago
  yep. well I don't avoid recursion per se, it can sometimes be very clean. But I sure did notice the power of map-, fold-, reduce- style programming from playing with KDB+/K/Q [an apl derived terse language for handling stream/column data] and the lisps.

There is truth to giving more thought in functional programming. Writing recursive functions requires thought especially when implementing tail recursion.

by dbul 18y ago

There is truth to giving more thought in functional programming. Writing recursive functions requires thought especially when implementing tail recursion.

eru 18y ago

I tend to avoid explicit recursion. It's nearly as much to think about as the iterative loops you are trying to escape from. Combinators like map, filter, foldl/foldr keep your mind free of clutter.

dbul 18y ago
I suppose my point was that iterative loops didn't make you think very much and so sometimes you become careless as was the case with that Zune bug from January. Recursion keeps you on your toes and if you practice enough then you can manage so-called clutter well and still have room to think.
- eru 18y ago
  Perhaps I am too much into Scheme and FP in general. I have come to view iterative loops as special case of tail recursion, necessary because some languages do not support general proper tail recursion. Iterative loops and explicit recursion make you think about stuff you'd rather not think about. For example if I want to apply a function on a number of items: > for(int i=0;i<n;i++) > b[i]=f(a[i]); plus managing the length of the array and creating the new array b in the first place. With explicit recursion (in Haskell syntax): > foo :: [a] -> [b] > foo [] = [] > foo (x:xs) = (f x: foo xs) You no longer have to care about the length of the list or an index. But you still have to think about where you place the recursive descent and how to make it tail recursive. And the same function with combinators: > foo :: [a] -> [b] > foo = map f Perhaps you will have to think a bit harder to write such a version, especially when you use the more advanced combinators like foldl/foldr, but reading is a pleasure. Of course you also have to define the combinators somewhere --- but those definitions are way easier when they are not mirred in domain specific details.
gord 18y ago
yep. well I don't avoid recursion per se, it can sometimes be very clean. But I sure did notice the power of map-, fold-, reduce- style programming from playing with KDB+/K/Q [an apl derived terse language for handling stream/column data] and the lisps.