4 ms·

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 persp

by mck- 12y ago

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.

wirrbel 12y ago
do you have a link/source for paul graham recommending Clojure?
- juliangamble 12y ago
  He's said its probably your best bet: https://news.ycombinator.com/item?id=4487793 https://news.ycombinator.com/item?id=4487793
- eruditely 12y ago
  Seconded.
wtbob 12y ago
> CL makes it hard not to write recursive. Say what? Are you sure that you don't mean Scheme? CL has LOOP…
- ScottBurson 12y ago
  > CL has LOOP... Oh gawd. The biggest wart on the language. Let's just agree that it's controversial :-)
  - lispm 12y ago
    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.
    - ScottBurson 12y ago
      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.
      - lispm 12y ago
        > 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.
        ScottBurson 12y ago
        > 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.
ScottBurson 12y ago
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 http://www.ergy.com/FSet.html

by mck- 12y ago

wirrbel 12y ago

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

juliangamble 12y ago
He's said its probably your best bet: https://news.ycombinator.com/item?id=4487793 https://news.ycombinator.com/item?id=4487793
eruditely 12y ago
Seconded.

wtbob 12y ago

> CL makes it hard not to write recursive. Say what? Are you sure that you don't mean Scheme? CL has LOOP…

ScottBurson 12y ago
> CL has LOOP... Oh gawd. The biggest wart on the language. Let's just agree that it's controversial :-)
- lispm 12y ago
  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.
  - ScottBurson 12y ago
    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.
    - lispm 12y ago
      > 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.
      - ScottBurson 12y ago
        > 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.

ScottBurson 12y ago

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 http://www.ergy.com/FSet.html