I just opt for parens every time. I really think they shouldn't ever be optional if in some cases they are mandatory. That this is a matter of personal style is somewhat frustrating.
What do you think is modern about the language? Try Aristophanes.
That said, this is a cool collection. I think it would benefit from more interesting presentation, in terms of web design. Also, a more modern / freer translation technique might suit the content better than the stilted rendition offered here.
> (I think I’ve probably lost a good number of people in this post already, so if you’re still reading this, I assume you’re familiar with Eigenvectors).
Actually, no! I was kind of hoping that by reading this section, I might find out about them. Why write a blog post section specifically targeted at those readers for whom it holds no new information? The responsible thing to do here, if you really didn't feel like explaining some key component of your discussion, would have been to provide a reference to someone else's explanation. Now it feels like you were wasting my time -- 'oh, hey kid, wasn't talking to you!'
Also, as others above have mentioned, the generalized introduction (a way to make 2 losing games into a winner!) does not lead intuitively into the extremely case-specific exposition.
I think Clojure makes a lot of sense for the web, emphasis on immutability etc. I also am a sucker for lisps, and I think the Hiccup templating system is nice. Noir seems to do middleware well. Plus, real nerds get on that ClojureScript.
Then again, I kind of also believe that the back-end really shouldn't do much more than process CRUD commands, and that most of your serious application logic should happen on the client. So it doesn't really matter. Pick something with a DB adapter you're comfortable with and get to javascripting.
I can't wait. I've been working with a bunch of XML files (TEI corpora, actually), and using document stores to build out indexes. One of the things that I've found is that what I want to do with reduce functions (build complex dictionaries, for instance with the key being a word stem and value being another dict with key=word form and value=list of locations or related words or whatever) is not the kind of thing Mongo/Couch DB reduce functions are designed for (i.e. scalars).
I learned what a 'reduce' is from learning Clojure (which was my intro to functional programming), not from databases. And so I got really used to the idea of reducing into nested dictionaries, because Clojure is good at that. Which meant that when I came to using MapReduce in DB environments (particularly CouchDB, but also a lil' Hadoop), I was a little disappointed.
Which is to say that a solid Clojuric abstraction layer that emphasizes a bucket approach on top of a variety of different stores sounds like my dream library.