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

http://postabon.posterous.com/why-i-chose-common-lisp-over-python-ruby-and

by smanek • 17 years ago

134 135 17 years ago

postabon.posterous.com

icey• 17 years ago

You could probably get rid of the "(fixed)" in your title; I bet most people didn't see your original submission, and the ones that did will know what happened.

smanek7• 17 years ago

Thanks. Sorry for the trouble before. I had an old personal wordpress blog that I'd originally posted this on - but there were some technical issues with upgrading WordPress to a modern version.

Just reposted the same content on Posterous.

ricree2• 17 years ago

The 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?

smanek7• 17 years ago

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.

azanar2• 17 years ago

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 a fluff name, but that is worse than no name at all. The reader is left wondering what the function is for, which requires carrying unnecessary mental baggage. It would seem more powerful to me that you just define a function where it is used, and not worry about having to carry around that extra mental information for later on; the less state you need to keep the better. But I may only say that because I, like you, tend to think functionally.

The second is to the namespace, because now there is a symbol in the environment that doesn't need to be there. It's not a huge deal, but it is just another bit of extraneous fluff.

Anyway, not meaning to turn this into a language war. Just a couple of thoughts that popped into my head when I read your first paragraph.

maxtilford3• 17 years ago

Obviously, map and filter are better because ... ah, hmm, I don't know.

I think it is a matter of language design. Higher order functions are not as prominent in Python as say, Haskell, where map & friends are generally preferred for composability. Lispers prefer map & friends just because list comprehensions add all that messy syntax.

If I were a Python programmer, I would probably use list comprehensions, since they seem to be the preferred idiom.

riobard10• 17 years ago

A single, non-nested list comprehension or generator exp is basically map(filter). You need nesting to get filter(map).

e.g.

    map(expensive_call, filter(cond, seq))

equals

    [expensive_call(each) for each in seq if cond(each)]

but

    filter(cond, map(expensive_call, seq))

equals

    [each for each in [expensive_call(x) for x in seq] if cond(each)]

note because of "expensive_call", it's inefficient (and silly) to do

    [expensive_call(each) for each in seq if cond(expensive_call(each))]

So map/filter combination gives more flexibility than list comprehension, and for functional-thinking minds, it's just so natural to think in abstract terms of passing functions around. List comprehension is pretty syntactical sugar to do similar things, but it forces you think about the "how to do" instead of "what to do".

That said, it's not really "compelling" though -- there is no real "compelling" reason to switch from one Turing-complete language to another given that you can do the same thing eventually. But hey, it's the itches that drive us nuts, isn't it? :)

Just my 2 cents

amix• 17 years ago

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.

yummyfajitas2• 17 years ago

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.

Incidentally, this isn't even an issue in a pure functional language with sufficiently smart compiler.

frig5• 17 years ago

It depends slightly on how you came to functional programming.

You can arguably trace Python's list comprehension syntax all the way back to setl, a "set-theoretic programming language", and the resemblance to mathematical set-builder notation is intentional; compare

- let B = { g(a) s.t. | a \in A and f(a) holds}

- B = [g(a) for a in A if f(a)]

If you're used to thinking in sets having to decompose into "maps" and "filters" is a speedbump; easy to do but nice to avoid.

Where list comprehensions really start to shine is making it comparatively trivial to pull from multiple source collections without a lot of ugly machinery:

    [{'widget':w,'sprocket':s,'location':l} for w in widgets for s in sprockets for l in locations if l.hasInStock(w) and l.hasInStock(s) and w.isUsableWith(s)]

...which is about where explicit map + filter start to become annoying. You can use:

    map(lambda i: {'widget':i[0], 'sprocket':i[1], 'location':i[2]}, filter(lambda i: i[2].hasInStock(i[0]) and i[2].hasInStock(i[1]) and i[0].isUsableWith(i[1]), itertools.product(widgets,sprockets,locations)))

...but to my eyes that is not only very ugly but just going by character count the # of characters given over to keywords (map, lambda, filter) instead of "what i'm doing here" is huge. Additionally use of itertools forces use of tuples for your intermediate values and thus the lambdas are gobbledegook until you get to the tail end of the statement and see that i[0] == widget, i[1] == sprocket, and i[2] == location. I could define some constants (WIDGET = 0, SPROCKET = 1, LOCATION = 2, etc) but now it's even longer.

It gets even worse if you try to be clever with the sequence of operations.

You might look at that definition and say lo! I can pre-filter out stuff not in stock at each location and make things more efficient. Naively you'd wind up with:

  map(lambda d: {'location':d[0], 'widget':d[1], 'sprocket':d[2]}, flatten(map(lambda l: list(filter(lambda p: p[1].isUsableWith(p[2]), itertools.product([l],filter(lambda w: l.hasInStock(w), widgets), filter(lambda s: l.hasInStock(s), sprockets)))), locations))) #nb must-supply-you-own-flatten-method

Under some circumstances that might be substantially faster than the previous approach. But compare the equivalent but you could have instead gone with:

    [{'widget':w,'sprocket':s,'location':l} for l in locations for w in [widget for widget in widgets if l.hasInStock(widget)] for s in [sprocket for sprocket in sprockets if l.hasInStock(sprocket)] if w.isUsableWith(s)]

So you lose a little flexibility in simple cases at in exchange for increasing the scope of what you can get away with as "readable" one-liners.

pwnstigator6• 17 years ago

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 much harder to pass around a syntactic entity like a list comprehension (although I'm glad list comprehensions exist; as shorthand they are great in source code.)

All this said, I haven't used Python in 3 years, in favor of purely functional languages such as Clojure and ML, so I might be way out of date.

megaman821• 17 years ago

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.

zephjc2• 17 years ago

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]

algorias• 17 years ago

map, filter and reduce were not removed from python3.x, however. They'll be there for the next decade at least.

tjr• 17 years ago

After that, I was planning to dig into some specifics about the best way to manage/deploy a production Common Lisp webapp, which I hope would help a new Lisper get off the ground.

Looking forward to that.

pcof• 17 years ago

I 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.

benhoyt• 17 years ago

   "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."

Does this argument hold some water, or is Python 2-to-3 conversion often pretty trivial in practice?

etal• 17 years ago

Word on the street is that the 2to3 tool is magical. Just run the Py2.6 interpreter with the "-3" flag for warnings, fix the warnings, and run the 2to3 tool to get your port.

WilliamLP• 17 years ago

Basically: 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.

smanek7• 17 years ago

I think you drawing that conclusion may be a result of how I structured my essay (I introduced my conclusion, then my reasoning).

I freely admit my personal biases and experiences eliminated a lot of potentially good options without ever giving them due consideration (e.g., Haskell, Scheme, Lua). But I really did try to give the 3 options listed in the article a fair shake at the time.

For what it's worth - I was about 50-50 on using Python till the very end ...

wheels• 17 years ago

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.

LucaDuval• 17 years ago

I don't read the article this way. He candidly admits his bias towards functional languages and he says that Ruby and Clojure could have been his choice if not for reasons related to the specific time-frame in which he took the decision.

scott_s3• 17 years ago

To be fair, I think most explanations for the decisions we make work this way.

Confusion2• 17 years ago

I think it just seems that way, because it takes effort to explicitly pull all those arguments into our consciousness, to explain a decision that was taken subconsciously. The subconscious is often equated with the emotional or the irrational, but there is no reason to suppose the subconscious is incapable of rational decision making.

Looking at it from that perspective, you are not rationalizing an irrational decision when you explain your reasoning: you are simply remembering/recreating the process that lead to the initial, perhaps even rational, decision.

btilly• 17 years ago

A man always has two reasons for what he does: a good one and the real one. - J.P.Morgan

scott_s3• 17 years ago

Python's multiprocessing library (http://docs.python.org/library/multiprocessing.html) provides a similar interface that one would expect from a multithreaded library. For example,

  from multiprocessing import Pool
  p = Pool(5)
  def f(x):
    return x*x

  p.map(f, [1,2,3])

I do not have direct experience with the library, but from what I've seen, the code you would write is not significantly different from the code you'd write using a decent multithreading interface.

fauigerzigerk2• 17 years ago

Multiple processes cannot share regular in memory data structures. That makes the multiprocessing library unsuitable for a growing class of applications. However, unladen swallow aims to remove the GIL, so there's still hope for Python.

scott_s3• 17 years ago

There is an API for both communicating data explicitly, and for allocating shared memory data structures which can be shared implicitly.

mahmud5• 17 years ago

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 read the code afterward knew the language; C was often a natural choice for code shared with others on Unix, C++ for MFC/COM, Perl for sysadmin stuff, and TCL and Awk for my own tools.)

I learned Lisp in over a month, to spite someone (I dared a notorious troll I would write an AI bot of his choice if he stopped spamming us, youthful bravado for sure, and I lost the bet) While researching "AI" I came across Winston and Horn's "Common Lisp", then the hyperspec, then a few more books over the course of a month. I sat down with SICP and did the exercises on my break, while I was in school and waiting tables.

After I learned it however, specially with CLOS, there was no contest. Three months after buying Sonya Keene's CLOS book it was fair to say I forgot all other programming languages. There were no more "projects"; I no longer had to sketch out designs on paper or do "requirement analysis" (something I was told in school was necessary for all software.) For once, the great ideas in my head were a new emacs buffer away. I could write code faster than I would in Perl, Awk or TCL, it ran as fast as C++, and it was more expressive than the English in my head. I could type "commands" into a shell get a dialog embedded in my window, a few more commands and it would move to the upper right corner, I could change its name property and add text to it, then I could fold that dialog box into a menu-item named "Help" in the menubar and call that dialogbox "About". Amazing.

I went on hacking like this for about year when I realized I was doing the "wrong thing". You see, I have been using CMUCL with its builtin editor and writing GUI applications in Motif (it was 2001 and Motif wasn't open source yet, so I got the hang on Lesstif and learned its quirks.) Right around this time, Linux GUIs were maturing and people were being snobs about their Enlightenment themes and dissing each other over their choices of Windows Manager. So I was peer-pressured into learning DHTML and Web Design. I read comp.lang.lisp and those too were snobbish condescending idiots who flamed everyone, specially competent programmers whose work I admired (including Scott McKay and Robert Fahlman (the very people who gave me my CMUCL.))

It was really hard to be a Lisper for a while, specially a young impressionable one who read cll uncritically; news of corporate giants coming with new tools and programming languages to enslave humanity were abound. First C++, then Java, then XML, and finally .NET. You literally had to pick your battles and choose a corporate sponsor or you would have no future in computing! (you think I am kidding?) cll is all doom and gloom, and of course, there is the obligatory stabs at Lisp vendors by Open Source proponents, and stabs at Open Source for people alleging it's killing our beloved vendors. Every once in a while there was news of a Lisp dialect that's going to kill Common Lisp (Smalltalk, Dylan, and the ancient religions of Mesopotamia.)

Fuck, that was painful.

All the while I was following this 4-year long intellectual funeral, becoming ever more "hardcore" and learning mathematics, there was a small group of "Yobos" silently kicking ass and churning out great software. CMUCL got forked to SBCL, added unicode support and threads, not to mention easy building, SLIME was a new Emacs mode better than anything before and since, Cliki was launched, C-L.net, and the #lisp IRC channel was born and hit puberty overnight. Perfect ecosystem.

Today, Lisp is nothing like what it was 8,7,6, even 2 years ago. It's not just "good" in the well-explored text book fashion; no, it's _good shit_. Get work done good. Think, hack, ship, bill for it good. 2-3 products per month good. You still have to know where things are, who is working on what, what's maintained and what's obsoleted by what. Sure. But there is absolutely no lack of libraries.

herdrick3• 17 years ago

Really? What has improved in Common Lisp in the past two years? Thanks for this comment.

mahmud5• 17 years ago

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; bordeaux-threads, usocket, CFFI, ASDF, Closure family of XML tools, etc. Lisp-World interop has become trivial. It's not their existence that's new, but their universal adoption by the community. Few years ago you couldn't just download a random lisp library and expect it to work; you had to read the sources and figure things out. Now dependency libraries get downloaded behind the scenes.

smanek7• 17 years ago

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 stupid mistakes (and I prefer my mistakes be caught at compile time). Unit testing/etc alleviate the pain to the degree - but it requires a lot of discipline to maintain good coverage.

The real trick is that I'm probably faster in Lisp than anything else, but I've met Python and Haskell hackers who are just as fast as I am - so it must be possible to use those languages well (you might argue that they'd be even better in Lisp ;-)).

lispm• 17 years ago

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).

coffeemug• 17 years ago

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.

Periodic• 17 years ago

That first 80% always takes only 20% of the time, and that's the first month for you. Some languages seem to let you do that month of work in three weeks, or two weeks, or with a framework it might take a week. But that last 20% is the part that always takes 80% of the time, and it often seems like whatever language you use, there are always the same, small, insidious errors and tweeks that need to be done.

holygoat3• 17 years ago

Sure, there's some hyperbole in his post… but don't underestimate the ability of good technology and a REPL to aid you in actually understanding the problem, or the available technology, or how you might solve it.

As a recent example, I find Clojure's REPL to be invaluable when wrapping my head around Java libraries. The features of a Lisp make sketching and exploring easier, and that's part of understanding the problem.

I forget the exact quote, but it's something like "I never learned to see properly until I tried to draw". Pertinent.

gruseom5• 17 years ago

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.

mahmud5• 17 years ago

Right, however don't forget there is a continuum of software types. The great majority of the code I write is customization of previous software for a new client. If you write enough business software, you will find out there are about 5-10 main components that they all have, and each new project differs only in how they're assembled, and the per-client business rules used to orchestrate them.

For example, it took me months to implement a decent RBAC system in CLOS; prototyping it literally took hours, just reading the wikipedia page. However, I had to refine that after every client, not just customizing it for the client, but iterating over it to make future customization unnecessary.

Billing, accounting, collaboration, knowledge management, human resources, lead management, CRM, inventory, etc. Do web-based implementations of those for a year and you will end up with the core necessary to ship any business software product in a very short time, assembling from your own repo. Augment that with web APIs (which I happily pay for) and you're there.

Another thing that I have become expert at is using other people's software. I am a hopeless cliki addict, mainly because I rarely code to scratch an itch; I have been writing Lisp code for years now, and for the last year, that's what I did full time :-) I have come to know huge libraries so intimately, including their quirks, that I can patch together something fairly quickly and get it out of the door.

nearestneighbor5• 17 years ago

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.

nearestneighbor5• 17 years ago

> Cliki was launched, C-L.net, and the #lisp IRC channel was born and

Google doesn't see any uptrend: http://www.google.com/trends?q=common+lisp

SwellJoe2• 17 years ago

Not only that, it's noise compared to a few other dynamic languages:

http://www.google.com/trends?q=perl%2C+python%2C+ruby%2C+com...

nearestneighbor5• 17 years ago

> I could write code faster than I would in Perl, Awk or TCL, it ran as fast as C++

Was that GUI code (as the rest of your post seems to imply)? CL is not competitive with C++ in terms of raw speed, in my opinion. Without type declarations, it's close to Perl.

10ren• 17 years ago

aside: Tim Bray on corporate sponsorship of languages: http://www.tbray.org/ongoing/When/200x/2009/10/01/C-dot-next...

jcapote• 17 years ago

"it's _good shit_. Get work done good. Think, hack, ship, bill for it good. 2-3 products per month good. You still have to know where things are, who is working on what, what's maintained and what's obsoleted by what. Sure. But there is absolutely no lack of libraries."

this is exactly how I feel about Ruby...

babo• 17 years ago

I don't buy the author's argument against Python and clojure but anyway, that's they system.

wgj• 17 years ago

Some of the conclusions are inconsistent. For example, Ruby got canned mainly for having a heavyweight framework, since he wants to write everything from scratch. What keeps one from doing that in Ruby? Ruby does not depend on Rails.

His complaint about different versions and implementations is a red herring. Lisp is not immune from this.

smanek7• 17 years ago

There are different implementations, of course. But the the multiple version problem was worked out over a decade ago.

gruseom5• 17 years ago

It's the other way around. For things you've decided to write from scratch, especially if they're hard, CL is a dream. There's nothing comparable in my experience [~]: you can build unbelievably powerful and concise programs easily, then just as easily transform them in major ways. It's the ultimate combination of malleability and expressive power. (Oh, and performance, when you need it.) I can think of only three reasons to prefer Ruby over it: (1) you want Rails etc.; (2) you don't like Lisp; (3) you really like Ruby. The latter two are matters of taste, which leaves #1.

[~] I haven't tried Clojure yet. Then again, I don't need to: the JVM is a drawback for me, and I don't need all those Java libraries right now.

akkartik• 17 years ago

No mention of mzscheme?!

herdrick3• 17 years ago

I like the choice. I love to see people using lisps but some of the path to that choice makes me cringe. Like this:

I probably could have written a ‘bare-bones’ implementation of the site’s back-end in Rails in a week instead of two weeks, but I would rather ‘waste’ that one week up front to have more flexibility later.

YAGNI. Speed kills (the competition).

gruseom5• 17 years ago

It was the previous sentence that resonated with me:

I’m a bit wary of using ‘heavy weight’ frameworks like Rails (or Django) on large custom projects. In my experience they make the first 90% of what I’m trying to do be really easy – but then make the last 10% a living hell since I need to modify something the framework never intended me to control.

That is a very true statement, in my experience. It's also an elusive insight, because once you commit to a framework you begin to interpret your problem, the universe, and everything in terms of the framework's conceptual space.

helium• 17 years ago

Ok, so Rails is too heavy weight for you? What about Merb? Or Sinatra, which was designed for just that reason? Dismissing Ruby as language because only one of a dozen available web frameworks is too "heavy-weight"sounds a bit short-sighted to me.

seiji• 17 years ago

Not everybody has time to keep up with the continuous and rapidly increasing micro-speciation of all ruby projects from the VMs down to template formats.

jamesbritt2• 17 years ago

" ...continuous and rapidly increasing micro-speciation of all ruby projects from the VMs down to template formats."

This is simply bullshit. There are merely a fair number of solid choices, as one would hope any decent language would offer. Being able to select appropriate tools for basic Web framework, ORM,and template language is a Good Thing.

There are only a handful of viable VMs, and for Web development the practical choices are MRI, REE, and JRuby.

"micro-speciation"? That's hysterical. Literally.

If Ruby doesn't interest you, fine. Bogus characterizations don't help anyone though.

Tichy2• 17 years ago

I am not the OP, but I have a problem with Rails and alternatives: there does not seem to be a viable alternative to ActiveRecord around? I looked into DataMapper (I think that was it's name) which initially looked great. But then I could not find any information on how to use transactions, and also received no answers on the newsgroup. I guess I should have read the source, but I gave up at that point.

Since I hate ActiveRecord, I have now subconsciously decided that Rails probably isn't for me.

It's great that Sinatra is spawning lots of imitators for other languages, though.

steveklabnik• 17 years ago

Just so you know, one of the stated goals of Rails 3 is to make it super-easy to swap in your own ORM layer, DataMapper included.

jamesbritt2• 17 years ago

" ... there does not seem to be a viable alternative to ActiveRecord around?"

Sequel, which seems to be the most common ORM used with Ramaze, and DataMapper.

(I had been a fan of Og from years back, but development has, I think, stopped. )

Ramaze lets you swap in the ORM of choice and is the best alternative for folks who find Rails heavy-weight or heavy-handed.

joevandyk2• 17 years ago

ActiveRecord is a small part of Rails. Lots of people use Rails without using ActiveRecord.

See http://whitepages.com for an example.

IgorPartola• 17 years ago

I forget where this came from but this applies 100%:

You ask a person to rate 5 paintings 1-5. You then tell them that you have spare paintings that they happened to have rated as 3 and 4 and ask them if they would like one. They will take a "4". Come back in a week and ask them to rate the paintings again. The "4" becomes a "5" and the "3" becomes a "2".

Our brains will rationalize decisions to make us happy (whatever that means).

revorad• 17 years ago

You may be referring to this TED talk by Dan Gilbert - http://www.ted.com/talks/lang/eng/dan_gilbert_asks_why_are_w...

vseloved2• 17 years ago

It'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).

pwnstigator6• 17 years ago

What about Clojure, circa now? Do you not consider it "production ready"?

I've used both CL and Clojure. I'd prefer either over Blub, but Clojure wins in my opinion.

vseloved2• 17 years ago

Clojure is nice, although I didn't use it in production. But it is Java deep underneath (so not completely homoiconic) and comparing to CL there are restrictions, albeit mild.

For some specific tasks I might have preferred it (until CL catches up with concurrency support). But in general CL gives you more freedom.

natmaster• 17 years ago

"The completely broken implementation of closures."

That's what the nonlocal keyword is for.

silentbicycle2• 17 years ago

When the fundamental design of the language is stacked against your style of working, the cognitive dissonance of using so many workarounds is a serious problem.

I just switched to Lua during the Python 2 to 3 transition, and I haven't looked back. Real closures and tail calls, no GIL, a vastly more tasteful design, a dead-simple C API, and the whole shebang is a tenth the size of Python.

silentbicycle2• 17 years ago

Meant to add: Lua's not perfect, but its whole design favors embedding it in another language, so it's a hell of a lot better about gracefully getting out of the way when it's better to write the parts that matter in other languages.

pge• 17 years ago

I appreciated the article, but I didn't find the reasoning compelling. What I took away from the article was the following line of reasoning: 1. You strongly prefer functional programming to OO programming (no reason given other than personal preference) 2. You don't have enough experience with any languages that are well-suited to FP other than CL that you would be comfortable undertaking a large project 3. You confirmed that many languages you are familiar with (Java, Python, Ruby) are better suited to OO than FP style (not a surprise at all except perhaps Python as I touch on below), so as a direct consequence of (1) and (2), you were left with CL.

CL is my first-choice language for certain kinds of projects as well, but I didn't come away any new insights from your article. Your choice seems to hinge around two key conclusions for which you give very little explanation: FP is better than OO for your project, and Python is not a good language for FP. I single out Python because I don't think anyone would argue that Java or Ruby is well-suited to FP. Guido insists that Python is not an FP language, but many users (myself included) would argue that it is reasonably well-suited for FP. That FP was better for your project does not require any further explanation. As others have noted, for a project where scalability of the development team is not an issue (i.e. you are the primary or only developer), it makes sense to choose the style and language you are most comfortable with. If you were starting a project that was going to require several years and a large number of developers, I would have found it more surprising if you committed to a functional programming model. But, given the nature of the project, it didn't seem like there was any need to defend that decision further.

All in all, I'm very excited to see CL being used for more commercial web apps, but I didn't find any insight in the thought process you laid out.

I am, however, much more interested in Pt. II - your description of rolling out a web app in CL. I learned CL ten years before I learned Python and would prefer to write in CL when possible, but for web apps, I have turned to Python for a number of reasons, most notably the obvious availability of libraries. I would love to hear what you used and hear a cogent argument that rapid commercial web app deployment can be done in CL as easily as in Python.

Thanks for sharing your story.

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

Related Stories