Why I chose Common Lisp over Python, Ruby, and Clojure • Hacker News Board

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

#141

Post by rbanffy » Thu, Dec 03, 2009, 4:29 PM UTC

ube wrote: post #71

smanek wrote: post #49

Earlier quoted context omitted.

That's a fair point. For a programmer without Lisp experience, that would be true. But I've written enough Lisp-based webapps that there aren't really that many 'unforseen' problems for me anymore (rule of thumb: use software by Edi Weitz - everything he writes is golden :-D)). That being said, I still ran into trouble with Elephant, so I probably should have taken these sort of 'unknown unknowns' (which are more pre…

If you are going to be the only programmer on the project then your reasons make sense. However, if you are going to have other people on the projects - then your reasons do not make sense from a longer term point of view. How many lisp programmers do you have out there as compared to python or ruby programmers? If you and the founders decide to go your separate ways how likely is the project going to be continued in…

"How many lisp programmers do you have out there as compared to python or ruby programmers?"

This one is a tired argument. Any good programmer will grok Lisp (or Python, or Ruby). If your Python/Ruby programmers can't get Lisp from a couple days of training, then they are not good programmers.

And, BTW, I would risk betting they are writing FORTRAN code in Python and Ruby.

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

#142

Post by foldr » Wed, Dec 30, 2009, 12:04 PM UTC

holygoat wrote: post #101

amix wrote: post #15

Earlier quoted context omitted.

Most times you are interested in doing the simple, e.g.: filtered = [x for x in seq if x>10] Python's list comprehension is much more readable than using map/filter/reduce - at least for Python programmers :) Anyhow, I really like Guido's decision on dropping these - it creates a cleaner language and forces people to think Pythonic when programming in Python.

Um... (filter #(> x 10) seq) sure is readable for me, and I'm fluent in Python and various Lisps. (That example is Clojure.) I would like to point out, however, that CL allows you to write: (loop for x in seq when (> x 10) collect x) which you might think is verbose ("why do I need that 'collect'?")... except that loop allows you to write things like (loop for i in *random* counting (evenp i) into evens counting (odd…

>Loop knocks Python's trivial list comprehensions into a cocked hat.

CL could really use something like Python's generators though. The loop macro is an ugly hack in comparison.

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

#143

Post by foldr » Wed, Dec 30, 2009, 12:13 PM 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.

>I'm used to Lisps, where def/defun/define/defn imply internment. For example, in Clojure:

With regard to 'define', it doesn't work like that in Scheme. A define in a function body behaves just like a let.