Hacker News Reader

Comment by mindstab | Hacker News Reader

Learning to program in lisp (specifically reading Practical Common Lisp [http://www.gigamonkeys.com/book/]) has made me a better programmer in all other languages even if I don't really use Lisp. Even my friends/coworkers have noticed it when coding together. My style is forever improved.

Learning Lisp just seems to promote better ways of tackling programming problems that is transferable to other languages where it's not as encouraged naturally even if superior.

View on HN

After reading up on lisp and associated topics (purity mainly) I rewrote a component in our C# code base and made it magnitudes of order more stable and atomic.

I hadn't written a line of lisp (although counted many brackets when trying to read along) but just studying it helped me think about programming problems a bit differently.

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

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

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

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

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.

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.

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.

Yep! My joke is that "Practical Common Lisp" is the best Javascript book ever written ;)

"Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot."

-- Eric S. Raymond

If we're quoting that then we should also quote PG's objection to it: if Lisp makes you so much better a programmer, why wouldn't you want to keep using it?

Practical reasons: The language is great for enhancing your style but in practice it's been one of the hardest languages I've come across to make do real things. It interacts with the outside environment very poorly and more awkwardly. It's got multiple slightly incompatible implementations and it's library set is relatively light, green, wastefully overlapping and not very well maintained.

There's a reason Java won't go away and that's that it runs everywhere releatively easily and interfaces with stuff acceptably well.

Python is now doing a good job of this too.

Lisp has a looong way to go on this front and I do speak from some limited experience.

It's very pleasant if all you're doing is staying inside lisp and interacting only with your own code but as soon as it's asked to play nice with others it gets a lot less fun.

And staying inwardly focused, never looking out and never talking to anyone else ultimately means get very little real productive work done.

Please take a look at clojure. There are a lot of videos on youtube... there is a specific clojure channel. I don't recall the specific name, and work blocks youtube unfortunately.

Clojure runs on the JVM and has great Java interop, so you get the fun of lisp, and the convenience of all the Java libs.

True, and I recently did the coursera class on clojure. I'm definitely keeping it in the back of my mind for future projects.

I still personally find JVM languages slow memory hogs during development but that's another issue :P

It's definitely a good offering

ABCL, a common lisp running on the JVM is getting better and better by the release. It's java interop isn't quite as polished as clojures, but it is usable, and you get Common Lisp, which I like slightly better than clojure.

Reply on news.ycombinator.com