Why I chose Common Lisp over Python, Ruby, and Clojure

Post by gruseom » Thu, Dec 03, 2009, 3:06 AM UTC

coffeemug wrote: post #56

mahmud wrote: post #16

Did you really choose Lisp over alternatives? Before learning CL I was a fairly decent, C, C++ and Perl programmer. Did assembly, Pascal, TCL and Awk. Up to that point, I always had to pause a for a minute when starting a new project/script, think about its scope, and choose a language based on the necessary performance, development speed, expressiveness, available libraries, etc. (and whether whoever was going to re…

Come on, man. If you're doing something worthwhile, it likely takes 2-3 months (if you're lucky) to just understand the problem. Common Lisp is an amazing language and development environment, but it won't help you actually solve the problem any faster, only to implement the solution. No silver bullets and all. I love Common Lisp, but the whole "code this in a weekend" thing has got to stop. Good software takes a dam…

Post by pwnstigator » Thu, Dec 03, 2009, 4:12 AM UTC

gruseom wrote: post #109

pwnstigator wrote: post #67

Earlier quoted context omitted.

List comprehensions are great, but they're sort of a DSL-- something the syntax recognizes as special and converts to something else. It's unusual that you can pass around higher-order syntactic elements, while every modern language worth its salt allows you to pass around functions. Common Lisp has something similar, called LOOP. Implemented as a macro, it's a within-Lisp DSL for expressing looping constructs, e.g.…

Indeed, we figured out recently that it's basically embedded Algol 68... which seems superbly fitting somehow.

Post by 10ren » Thu, Dec 03, 2009, 5:25 AM UTC

mahmud wrote: post #16

Did you really choose Lisp over alternatives? Before learning CL I was a fairly decent, C, C++ and Perl programmer. Did assembly, Pascal, TCL and Awk. Up to that point, I always had to pause a for a minute when starting a new project/script, think about its scope, and choose a language based on the necessary performance, development speed, expressiveness, available libraries, etc. (and whether whoever was going to re…

Post by mahmud » Thu, Dec 03, 2009, 6:26 AM UTC

gruseom wrote: post #111

coffeemug wrote: post #56

Earlier quoted context omitted.

Come on, man. If you're doing something worthwhile, it likely takes 2-3 months (if you're lucky) to just understand the problem. Common Lisp is an amazing language and development environment, but it won't help you actually solve the problem any faster, only to implement the solution. No silver bullets and all. I love Common Lisp, but the whole "code this in a weekend" thing has got to stop. Good software takes a dam…

I agree with both of you. Mahmud at that point was talking about all those projects that aren't worthwhile, by your (our) crazy definition. Edit: but yeah, the "coding over a weekend" thing annoys the hell out of me too... but that's orthogonal to Lisp.

Post by zephjc » Thu, Dec 03, 2009, 6:33 AM UTC

pwnstigator wrote: post #107

zephjc wrote: post #98

Earlier quoted context omitted.

IMO, it's generally bad form for a program to be dynamically creating named functions, filling the namespace. That's what inner functions are for. This isn't the best example, but you get the idea: def foo(mylist): def n_to_the_n(n): if n > 1: return n**n return 1 return [n_to_the_n(i) for i in mylist]

Do the inner functions get cleaned up after you exit the function body? I'm used to Lisps, where def/defun/define/defn imply internment. For example, in Clojure: (defn foo [list] (defn n-to-nth [n] (Math/pow n n)) (map n-to-nth list)) Would intern the symbol 'n-to-nth in the current namespace. So every time I see "def", I think of something that has that (mild, almost always innocuous) side effect.

  >>> def foo(mylist):
  ...   def n_to_the_n(n):
  ...     if n > 1:
  ...       return n**n
  ...     return 1
  ...   return [n_to_the_n(i) for i in mylist]
  ... 
  >>> print foo([1,2,3,4,5])
  [1, 4, 27, 256, 3125]
  >>> foo
  
  >>> n_to_the_n
  Traceback (most recent call last):
    File "", line 1, in 
  NameError: name 'n_to_the_n' is not defined
  >>>