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

Post by ube » Wed, Dec 02, 2009, 8:13 PM UTC

smanek wrote: post #49

wheels wrote: post #36

Earlier quoted context omitted.

I too thought the logic was weak. Here was my basic objection: you chose not to use two popular web programming languages because of their potential volatility, but then went with one that has been so infrequently used in web programming that it almost certainly has opaque deffeciencies. It's not that your reasons were bogus, they just didn't carry the decision.

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…

Post by smanek » Wed, Dec 02, 2009, 8:21 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…

Post by aerique » Wed, Dec 02, 2009, 8:51 PM UTC

nearestneighbor wrote: post #59

mahmud wrote: post #21

Earlier quoted context omitted.

In the last two years? Clozure Common Lisp at least: an open source multithreaded Lisp implementation with unicode on Win32. Before then it was all Unix. Lisp platform independence is so good, I hack on win32 all day and when I am ready to deploy on Linux, the only warning I get is from git telling me it's converting line endings to Unix style. The staggering number of new and maturing infrastructure libraries; borde…

It's funny, when I googled "Clozure CL" I got: An open-sourced Common Lisp implementation for LinuxPPC. and didn't look at it again. If you are using OSX/Linux anyway, is Clozure CL useful (considering you we already got CMUCL/SBCL)?

Post by ellyagg » Wed, Dec 02, 2009, 8:56 PM UTC

azanar wrote: post #22

smanek wrote: post #6

Earlier quoted context omitted.

Nope - just a style thing. You don't need lambdas either - named functions are just as powerful. But I often think 'functionally.' Since I have options, I'd rather go with a language that allows me to program how I think - instead of being forced to translate my thought into its semantics.

Nope - just a style thing. You don't need lambdas either - named functions are just as powerful. It depends on what you define as power, and how wide of a continuum you are willing to presume that it runs. Named functions add two levels of clutter. The first is to the actual code, because you have to add a name to something that never wanted one, and it has to be defined apart from where it is used. You could give it…

Post by riobard » Wed, Dec 02, 2009, 9:01 PM UTC

frig wrote: post #47

riobard wrote: post #41

Earlier quoted context omitted.

Well, FP is mostly about nesting, but it's uniform and people get used to thinking that way. List comprehensions, on the other hand, are more like procedure code (conceptually), and it sucks to nest them. Nesting aside, it's the different level of abstraction that matters for FP-ers. Plus, you get 5 mentions (3 y's and 2 x's) of some intermediate variables instead of 0 in your code, so both token-wise and char-wise,…

I have a longer comment here that argues the opposite: list-comprehensions are only a syntactic pun or two away from set-builder notation, which is a higher level-of-abstraction (it declaratively states what it is) than map+filter (which specify a procedure to generate it, albeit at higher level of abstraction than a for-loop). If you can put together a nontrivial usage of map+filter with at least three source collec…

    map(lambda (w,s,l): {'widget': w, 'sprocket': s, 'location': l}
        filter(lambda (w,s,l): l.hasInStock(w) and l.hasInStock(s) and w.isUsableWith(s), 
            product(widgets, sprockets, locations)))