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…
I have to second this. I switched from CL to Python years ago because of problems with the infrastructure, but now I'm in the process of switching back, largely due to Clozure becoming really ready for prime time, and tremendous improvements in the stability and usability of available libraries. The situation is still not perfect, but it vastly improved and getting better all the time.
Why I chose Common Lisp over Python, Ruby, and Clojure
51–60 of 143 posts
Re: Why I chose Common Lisp over Python, Ruby, and Clojure
#52Earlier quoted context omitted.
I don't get how map/filter is more flexible than list comprehensions. Map/filter require nesting: (filter (map expensive_call X) cond) So do list comprehensions: [y for y in [expensive_call(x) for x in X] if cond(y)] Near as I can tell, the only difference is that list comprehensions also provide a syntactic sugar for the convenience function filter_then_map. Sometimes this saves you a level of nesting, sometimes not…
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,…
List comprehensions are not conceptually like procedural code at all. They are completely declarative.
List comprehensions: the set contains this.
Map/filter: apply these functions to the set.
Procedural: follow this recipe for turning one list into another.
Re: Why I chose Common Lisp over Python, Ruby, and Clojure
#53The fact that he proposed removing map, reduce, filter, and lambda from Python 3. In the case of map and filter, is there any compelling reason to use either of those instead of list comprehensions or generator expressions?
I like lambda because it allows anonymous functions-- functions that can be defined on the fly (dynamically) and then thrown away. IMO, it's generally bad form for a program to be dynamically creating named functions, filling the namespace. Also, I like map and filter because they aren't just functions in the procedural sense but combinators: you can pass them around, using them as arguments and returning them. It's…
You bring up a good point about passing map and filter around. I hadn't really thought of that.
I still prefer to user list comprehensions, and don't think it would be so bad to have map, filter, reduce live in the itertools module. This would stylistically match what is done with the comparison operator functions living in their own module, which you can import if you need to pass the functions around.
Re: Why I chose Common Lisp over Python, Ruby, and Clojure
#54Basically: I started with my conclusion, and then went through all the other options and rationalized them away until it seemed like my choice was based on objective reasoning.
A man always has two reasons for what he does: a good one and the real one. - J.P.Morgan
Re: Why I chose Common Lisp over Python, Ruby, and Clojure
#55Did 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…
Heh, funny you learned from the Winston & Horn book - that was my first too. The biggest philosophical problem I have with Lisp (and a lot of dynamically typed languages) is the lack of compile time safety-nets (it really bites me when I'm trying to work with a large, distributed team). I miss interfaces/abstract-classes, type checking, etc. I know they aren't necessary - but I'm human and make more than my share of…
Compile-time type checking is available only in a limited form.
For 'interfaces' and 'abstract classes' - add them if you need them (I have seen them in some projects).
Re: Why I chose Common Lisp over Python, Ruby, and Clojure
#56Did 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 damn long time to develop in any language, because the language isn't the bottleneck.
Re: Why I chose Common Lisp over Python, Ruby, and Clojure
#57Did 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…
What is was it about CLOS that made you feel it was a killer language feature? Many seasoned Lisp programmers do not even consider it or OO in general particularly useful.
Re: Why I chose Common Lisp over Python, Ruby, and Clojure
#58I predict you will get a great deal of pythonic fire. Nevertheless, I find it very nice that you plan to deal with the specific libraries you're using in the next posts. The greatest problem in adopting CL seems to be the extremely decentralized (not to say disorganized) library spacs.
"Python 2 is fine now – but in the coming months and years new libraries,
features, and performance improvements are only going to be introduced
in Python 3, and I didn’t want to get left behind or forced to take on
an expensive and time consuming port in the future."
Re: Why I chose Common Lisp over Python, Ruby, and Clojure
#59Earlier quoted context omitted.
Really? What has improved in Common Lisp in the past two years? Thanks for this comment.
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.
Re: Why I chose Common Lisp over Python, Ruby, and Clojure
#60It's funny, that the decision to choose Common Lisp for some project often has to defend itself (because of so much FUD around the language). CL has one killer feature, that will appeal to any mature developer: it's the only production-ready language around, in which you are virtually not constrained by any third-party design decision. That's it. Discussing other details just boils down to the question of tastes (that differ).