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

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 prevalent in unusual languages like Lisp) into consideration upfront. To not do so was certainly an oversight.

It seems like a somewhat precarious decision to let you use Lisp for this project. There's nothing supremely special about the problem you are attacking that warrants Lisp (outside of your comfort level which you clarified very clearly in your post).

Perhaps I'm just old and cynical but I've been on too many projects where the first (and therefore "lead") developer chose a particular language and architecture that in the long term was not sustainable.

As a point of reference, ITA Software has no trouble hiring 100s of Lisp programmers.

Minor correction: I am a founder - and if I were to leave (while my co-founders continued), I'd make a point to find my replacement first.

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.

This also alludes to the popularity of do-it-yourself microframeworks. If you're planning on using a microframework anyway, I'm not sure your argument really holds up. You can pretty much use whatever not-completely-marginal language you want and be just fine.

Honestly the only valid argument that I come up with is that you can't find enough programmers that know or are excited to know that language to join your team.

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.

On the Wikipedia page for 'Anchoring', there is an example about thinking of a number and subsequently bidding (experiment by Ariely). What happens when you tell people with a high number that they are likely to make a relatively high bid, so they should try to make a relatively low bid? Do they make 'normal' bids or extremely low bids?

This shows that saying people can't rid their decisions of that influence is an overstatement. When you are consciously aware of the heuristics and the decision is taken over a period of time, you can downplay them.

One way to explain would be to think about the number of variables we should account for in virtually any everyday decision. Finding even a fairly optimal solution would consume too many resources and evolution has taught us to deal with this using emotional shortcuts. On the evolutionary time scale, the 50 years when the question of choosing a programming language was relevant would be a tiny dot.

On the other hand, rational knowledge can by absorbed subconsciousness eventually. But when it does, we become unaware of it, by definition.

Looking forward to that.

In the case of map and filter, is there any compelling reason to use either of those instead of list comprehensions or generator expressions?

e.g.

    map(expensive_call, filter(cond, seq))

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

    filter(cond, map(expensive_call, seq))

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

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

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

    (filter (map expensive_call X) cond)

    [y for y in [expensive_call(x) for x in X] if cond(y)]

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

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, map/filter alternative is shorter, and less a mental burden (think about the "succinct" idea by PG).

If you can put together a nontrivial usage of map+filter with at least three source collections that's more concise than the equivalent list comprehension I'll (figuratively) eat my hat.

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

The argument in favor of set-notation being higher level is it's less specific (it doesn't explicitly provide a sequence of operations, just an outcome).

List comprehensions look like set notation but have an implicit procedural translation you have to keep in mind to use them well, so it's a toss-up.

I prefer map/filter/reduce when sequencing has large performance implications but for simple filtering or raw-data-shaping comprehensions read more smoothly.

http://books.google.com/books?id=RvY5BM0Xt1wC&lpg=PT367&...

Now you know why many people like me are gradually pissed off by Python and start the exile ... currently trying Scala and it seems a nice language (with list comprehension too! :)

> List comprehensions look like set notation but have an implicit procedural translation you have to keep in mind to use them well, so it's a toss-up.

Actually I think that's the problem I have with list comprehensions: I use them a lot in my code, usually 1~3 levels nested and then have a hard time tracking down the order of implicit loops (which is inner vs outer) and make sure the intermediate variables (x for x in y for y in z ...) do not clash ... OK maybe I'm using it too much and in the wrong way :(

> I prefer map/filter/reduce when sequencing has large performance implications but for simple filtering or raw-data-shaping comprehensions read more smoothly.

I didn't know map/filter is faster than list comprehensions? I thought both are optimized by Python interpreter. But I like the idea of knowing that at least map can be parallelized easily. But since Python does not utilize multicore in a decent way, all bets are off :(

  do { w <- widgets;
       s <- sprockets;
       l <- locations;
       guard (l `hasInStock` w);
       guard (l `hasInStock` s);
       guard (w `isUsableWith` s);
       return (w, s, l); }

If eg I edited it to be:

    do { l <- locations;
         w <- widgets;
         guard (l `hasInStock` w);
         s <- sprockets;
         guard (l `hasInStock` s);
         guard (w `isUsableWith` s);
         return (w,s,l); }

List comprehensions: the set contains this.

Map/filter: apply these functions to the set.

Procedural: follow this recipe for turning one list into another.

    [fn(x) for x in xs for xs in xss if cond(xs)]

  filtered = [x for x in seq if x>10]

For simple cases, yes. But I wouldn't say

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

    filter(cond, map(expensive_call, seq))

Now the problem is, some people see Python as a very functional language (with first-class functions etc) and want to use it that way (like Lisp), but BDFL and some core Python devs believe it is better to keep it Pythonic, thus those functional people are kinda pissed off by this and switch away from Python.

Personally I don't think it will make Python a lot cleaner to remove two auxiliary functions and force people to use list comprehension when it is completely trivial to add these missing pair back (two lines of code).

(disclosure: I prefer FP, but I also think keeping things Pythonic is fine most of the time. It's just that in this case, I think map/filter is pretty "Pythonic" according to me. :)

Later, I ran into some cases where I wanted a multi-line lambda. And my thought was "aaragh134!#?!"

Then, a weird thing happened. I started making a conscious effort to follow PEP 8. 79 column limit? Seriously? That sucks. But after weeks of struggling with it, something finally hit me. I realized I was writing better code by forcing myself to reduce code density. Sure, it was a little bit longer, but I spend way more time reading it than writing it.

Stop trying to fight it; assign a name to that lambda. Readability counts.

Stop trying to be clever; assign a name to that inner expression. Flat is better than nested.

De-emphasizing functional operations makes it more likely for libraries to work in a non-functional style, for tutorials to do so, etc.

It's tiring fighting against a community and a (benevolent) dictator that disagree with you.

That summarizes the problem I guess :D

Actually only one line of code is enough for each of map/filter:

    def map(fn, seq): return [fn(each) for each in seq]
    def filter(cond: seq): return [each for each in seq if cond(each)] 

    (filter #(> x 10) seq)

I would like to point out, however, that CL allows you to write:

    (loop for x in seq
          when (> x 10)
          collect x)

    (loop for i in *random*
          counting (evenp i) into evens
          counting (oddp i) into odds
          summing i into total
          maximizing i into max
          minimizing i into min
          finally (return (list min max total evens odds)))

I switch between map/filter and loop depending on whether I'm working with predefined functions (e.g., (filter 'less-than-ten seq)), handling multiple sequences, doing side-effects, etc.

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

The question is whether "Pythonic," as the community defines it today, is optimal in all cases. As an analogue, there have been enough talks about things the Java community considers to be stylistically optimal that look really horrible compared to implementations in other languages -- like Python. :-) Pythonic style should be a guide, not an edict, and should be deviated from or redefined when it makes sense. The examples riobard provided already show the syntax weighing things down, a situation where syntax should give way to a more functional style approach.

As for it creating a cleaner language, I try to approach this, as with all things, from the perspective of being an language-agnostic programmer. From that perspective, I do like the python syntax for simple things like what you defined, but under heavier weight mapping and filtering operations, the map/filter function call syntax seems a lot cleaner. There's nothing wrong with syntactic sugar, but I would assert that it will tend to suck when it is all you have.

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

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

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

    [{'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)]

Level 0: for-loops with an explicit accumulator

Level 1: map + filter (!)

Level 2: ??? arguably an atemporal set-theoretic approach

In practice in python list comprehensions are a superior syntax for computing with multiple source collections.

(!) Really all you need is reduce

    map = lambda f,l: reduce(lambda h,t: h + f(t), l, [])
    filter = lambda f,l: reduce(lambda h,t: h + t if f(t) else h, l, [])

A saner map/filter/product version:

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

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.

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.

  result = []  
  for item in iterable:
      # here goes multiline lambda as an explicit suite
      # that computes value
      result.append(value)

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.

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.

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.

Common Lisp has something similar, called LOOP. Implemented as a macro, it's a within-Lisp DSL for expressing looping constructs, e.g.

(loop for i from 1 to 10 sum i) => 55

(loop for c across "bar" collect c) => (#\b #\a #\r)

It's controversial within the CL community, because the loop language looks much more like traditional languages than Lisp.

It's an influential language, for sure, but I prefer Clojure for a number of reasons.

That CL contains TAGBODY is a brilliant thing. It amazes me that a language can be at once so high-level and so low-level. I haven't had occasion to use it yet, but the fact that it's there, and that the higher-level abstractions are built in terms of it, is a thing of beauty to me. (I don't know about PROGV.)

I'd prefer to code in CL over Java/Blub, but I prefer Clojure over CL, and probably Haskell or ML over Clojure. (Lisp has better syntax, and macros are very cool, but static typing wins for large projects, in my opinion.)

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]

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

  >>> 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
  <function foo at 0x6e5f0>
  >>> n_to_the_n
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  NameError: name 'n_to_the_n' is not defined
  >>>

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

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

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

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.

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.

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.

Edit: but yeah, the "coding over a weekend" thing annoys the hell out of me too... but that's orthogonal to Lisp.

I know what you're thinking; the previous project gave you the hindsight necessary to implement the second so quickly. Well, not really. The stuff I did in Lisp where things that have been on my requirements for the first project but was never able to implement without huge investments in time. MFC is the most brittle, most fickle and fidgety POS of all time; it generates the boilerplate for you and it expects to you to use its skeletons just the way they are. It took me months to experiment with the various data access APIs, ADO, DAO, and ODBC, moving from one to the next as problems arose, and each change of backend requiring a complete code overhaul.

Now I write database code in native idiomatic code; I can change the backend with a feature. I would sometimes forget to #+postgres on deployed code and find everything working but not see any change in the postgres logs, just to realize I have :sqlite3 pushed into my features ;-)

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

For 'interfaces' and 'abstract classes' - add them if you need them (I have seen them in some projects).

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.

Yeah, that was my painful experience as a noob.

Now dependency libraries get downloaded behind the scenes.

You mean ASDF takes care of dependencies for you?

It's just that I wrongly thought you had referred to yourself as a female in an earlier post.

For example, a couple of weeks back, there was an article about a python-based tool on HN (I forget which). There was a lot of opinion, however was generally about BeautifulSoup vs lxml.

Coming to CL, I dont even know where to begin for XML parsing (http://www.cliki.net/XML). Which is why, it seems like black magic when people make amazing software (quantz, postabon) .

I just get too intimidated on where to begin... it is similar to the javascript library fights that keep erupting on comp.lang.js : you ask about one and are made to feel like you should have chosen another.

I really don't get all the complaints in this thread about the lack of a central library repository. How hard is it to use Google? Libraries aren't suddenly bad because they're not from Lib Grand Central.

In other languages, Perl specifically, I've tried libraries from CPAN that were total shit and then I googled around and grabbed a better one from someone's homepage.

CPAN's structure enforces good practices: (e.g., tests, docs, bug tracking).

CPAN provides not one but two excellent search pages. It also contains many reviews, and makes it trivial to see the source of any library or app before you download it.

CPAN helps enable sprawling, group-built libraries (Catalyst, Moose, DateTime).

CPAN has a whole mini-network of related sites that provide secondary help (installation testing and reports, annotation for docs from users, etc.).

I really don't get what you don't get. It's obvious to me why a good centralized library repository is a win for any language.

The very argument that choice > standardization is something I dont get - even in Rails, you have the choice of not using the default templating engine, JavaScript framework, etc. But it doesnt mean that they dont package it in anyway. This accelerates adoption, since it gets out of your way - and later when you mature as a developer, you can of course customize it wildly.

It may or may not also have the happy side-effect that the quality of the packaged libraries increase, because of a much larger user-base. I'd much rather that people fork mature libraries than hack the one-millionth version of an XML library that just does 2 things.

    An open-sourced Common Lisp implementation for LinuxPPC.

I half jokingly fail to see why running on Win32 would be considered an improvement...

(Burn, karma, burn!)

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.

this is exactly how I feel about Ruby...

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

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

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

Yep, still noise.

Jeff Ruby asks OJ to leave business

Ruby on Rails 2.0 Released

JFK Documents Include Reported Ruby, Oswald Conversation

23-foot python found basking in sun

Former Olympic champion Ruby dies in climbing fall

Monty Python reunite

Only one of those is related to programming.

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

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

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

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

[~] 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.

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.

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

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.

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.

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.

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

Forms and validations don't depend on ActiveRecord at all in edge rails.

Just reposted the same content on Posterous.

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

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.

That's what the nonlocal keyword is for.

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.