Hacker News new | past | comments | ask | show | jobs | submit login

What I like most about Common Lisp is how it made me a better programmer. The different paradigm of coding trains your brain in different ways which offer perspectives on problem solving that I otherwise wouldn't have considered.

Note that for the above effect, it is irrelevant what Lisp you choose. Yes, it also applies to learning any additional language, but because Lisp is a different breed altogether (as opposed to Fortran-derived languages), more value is to be had from the diversity.

I used to be a huge fan of Common Lisp (even wrote my own series of blogs on why I love it a few years ago) -- still use it in my daily work -- but I came to realize that it's not perfect. There are many things that Clojure has improved upon, e.g. consistent accessor methods, shared immutable data structures vs copying, and probably many more once I dive deeper -- there's a reason why even pg started recommending Clojure over CL or Arc.

I've been coding in Common Lisp for about 3-4 years. Even the algorithm of my startup is written in Common Lisp. There are definitely moments of sheer joy when I switch back and forth between Javascript and Common Lisp. But also moments of annoyance... sometimes certain algorithms are just more naturally imperative, and CL makes it hard not to write recursive.

tl;dr learning a Lisp is highly recommended. It does not matter which flavour. Or just go read SICP.

It's perfectly easy to write imperative code in CL. You have objects, you have vectors, you have every control structure operator ever conceived except CALL/CC, ... what else do you need?

On the other hand, if you want to write more functionally, CL also now has shared immutable data structures. Check out FSet: http://www.ergy.com/FSet.html

> CL makes it hard not to write recursive.

Say what? Are you sure that you don't mean Scheme? CL has LOOP…

> CL has LOOP...

Oh gawd. The biggest wart on the language.

Let's just agree that it's controversial :-)

Blame Interlisp. We got it from there.

Still the point is, that Common Lisp prefers iteration by loop-like constructs (or higher-order mapping) to recursion, due to the lack of TCO in the standard: DOLIST, DOTIMES, DO, DO*, LOOP, MAPCAR, MAP, ... Many people prefer the design of the ITERATE macro, but LOOP is already included.

The lack of TCO in the standard is almost a non-issue considering that most of the implementations support it. Even Allegro has long done TCO on local calls (calls to functions defined with LABELS or FLET, within the scope of that construct).

The only people who need to worry about TCO are those writing portable libraries. Everyone else can assume it, at least for local calls, which represent 98% of the times that it matters anyway.

> almost a non-issue considering

Almost. It's just that that many implementations support it (ABCL not) and that the language does not support it. TCO interacts badly with many Lisp language features: dynamic binding, unwind-protect, ...

> Everyone else can assume it, at least for local calls, which represent 98% of the times that it matters anyway.

If the right optimizations settings are set.

> TCO interacts badly with many Lisp language features: dynamic binding, unwind-protect, ...

I've never understood this claim. I mean, I understand the technical point: that use of dynamic binding or UNWIND-PROTECT creates a barrier in the stack across which TCO cannot be done. But in practice it seems to me a non-issue. I can't recall ever, in 35 years of Lisp hacking, wanting to write a tail-recursive routine that used one of them on each iteration, in such a way as to cause unbounded stack growth. It just doesn't happen, at least not to me.

Maybe that's partly because I try to keep my usage of dynamic binding to a bare minimum. I think some people overuse it.

Ah right, I forgot about ABCL. I haven't used it, though I keep meaning to give it a try. Hmm, it can't do TCO even on local calls? My code may not run in it, then.

Btw., if you haven't seen it, here is an overview:


Btw., Symbolics Genera also did not support TCO. ;-)

The overview is useful -- thanks. I see Allegro now does full TCO. Either that wasn't true when I was using it (a dozen years ago) or we just didn't have the right optimize switch settings to turn it on. In any case, I thought that the strategy of doing TCO only on local calls was pretty good -- it let me write loops tail-recursively with LABELS, but didn't significantly impact debugging because only local call frames got deleted.

I'm well aware that the LispMs did not do TCO -- I owned several (starting with a CADR) and still have an XL1200 rusting in my closet :-)

Iterate is so much cooler! defmacro-clause has been a godsend for my work.

do you have a link/source for paul graham recommending Clojure?

He's said its probably your best bet:



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact