4 ms·
Completely agree that learning functional programming has improved my thinking and code. The one difficulty I continue to encounter is switching back and forth
by monkeyfacebag 14y ago
Completely agree that learning functional programming has improved my thinking and code. The one difficulty I continue to encounter is switching back and forth between recursive and iterative thinking. From a computational perspective they may be equivalent, but from a cognitive perspective they aren't (at least in my case). I don't know how many times, for example, I've been bitten by a stack overflow when jumping into Python from Haskell (or equivalently, jumping directly into the ST Monad because I want to iterate through some lists).
- pavelludiq 14y agoI've been using Common Lisp for two years now, I've written exactly ONE recursive function that wasn't an exercise or an example. Functional interfaces to functions with local state in loops? What exactly is wrong with that? For example it is my opinion that this function is in no ways inferior to a recursive equivalent: (defun range (end &key (start 0) (step 1)) (loop for i from start to end by step collect i))
- baddox 14y agoI suppose that most of the data structures which are naturally understandable in their recursive forms (like merge sort) would already be accessible via libraries.
- Falling3 14y agoAs far as I know (which isn't too much), there's nothing wrong with that. But since monkeyfacebag mentioned the psychology of code writing, there definitely seem to be algorithms that lend themselves to recursion. At the very least, some algorithms are more intuitively grasped as recursive - and the same obviously holds for iterative.
- pavelludiq 14y agoyes, usually anything having to do with recursive structures, like threes, is a good fit for recursive algorithms. In fact, the function I wrote had to generate a directory structure out of a template: https://gist.github.com/pvlpenev/4760658 https://gist.github.com/pvlpenev/4760658 (and i still used loop :) But keep in mind that some things, although recursively defined, are better computed in other ways, the most obvious example is a Fibonacci sequence, which if I really needed, I would precompute and stick in an array for constant time access or something like that(maybe memoize a recursive function).
- betterunix 14y agoPersonally, I find that traversing data structures recursively is more straightforward than iterative approaches, at least for most of the data structures I deal with. This sort of thing, for example: (defun search (tree val) (cond ((null tree) nil) ((= (car tree) val) tree) ((< (car tree) val) (search (cadr tree) val)) ((> (car tree) val) (search (cddr tree) val)) ) ) I write this sort of code all the time for more complicated structures; iterative solutions would involve keeping track of a bunch of local variables, which only makes the code more difficult to deal with.
- baddox 14y agoThe Little Schemer is the book that got me thinking about data structures recursively (starting with linked lists), and that was later furthered by SICP. http://www.amazon.com/Little-Schemer-Daniel-P-Friedman/dp/0262560992 http://www.amazon.com/Little-Schemer-Daniel-P-Friedman/dp/02... http://mitpress.mit.edu/sicp/full-text/book/book.html http://mitpress.mit.edu/sicp/full-text/book/book.html
- aerique 14y agoI noticed my usage of recursive functions going up and becoming more natural to me after reading The Little Schemer. Check it out, it is a really nice book.
- gruseom 14y agoFunctional interfaces to functions with local state in loops That's how I write Lisp too. It seems to me the nicest way to minimize overall complexity.
- wglb 14y agoI remember a correspondence between Knuth and Dijkstra about a deep problem involving four (!) stacks in the recursive solution. One or the other of them stepped back and found an iterative solution that was much easier to understand. However, whether or not your example shows something that is not inferior is likely a matter of opinion, not fact.