Hacker News Reader

Comment by monkeyfacebag | Hacker News Reader

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).

View on HN

I'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))

Personally, 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.

The 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/02...

http://mitpress.mit.edu/sicp/full-text/book/book.html

Functional 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.

I 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.

As 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.

yes, 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 (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).

I suppose that most of the data structures which are naturally understandable in their recursive forms (like merge sort) would already be accessible via libraries.

I 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.

Reply on news.ycombinator.com