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.
Remembering to call a function differently depending on whether it has arguments or not has been a common source of errors for me.
It's also much easier for me to parse the difference between "foo(bar(baz))" and "foo(bar, baz)" than it is for me to parse the difference between "foo bar baz" and "foo bar, baz"
I've been on the private beta and working on that article for over a month in conjunction with Addy and Paul from the Yeoman team. I contributed numerous tickets and issues to the repository and assisted in testing countless times. Just so you don't think I whipped it out really quickly.
Did you actually read the article? It is more in depth then the QS on the yeoman.io site. At the end of the day, introductions are going to cover similar material, but I think this version is a bit friendlier than what is up on the main site now.
I actually thought it to be a good write up. When yeoman was first announced, I was "meh" about it. Now that I've read the article, I actually want to kick the tires on yeoman.
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'm inclined to agree for a few reasons other than the usual things people cite about Clojure. These are the first to come to mind:
* The property list pattern and inheritance-like behavior are very natural and convenient with maps and records. I think that sort of thing is very helpful with large applications.
* Clojure has the ability to abstract the database (I'm thinking of Korma here) in a way that preserves and works with the relational model more directly than ORM.
Clojure's ability to leverage Java libraries also means you're unlikely to ever get stuck implementing common functionality from scratch[0] when another language would have a library.
[0] I did, however once write a CSV library for Clojure because it seemed easier than using an existing Java library for the subset of functionality I needed or writing a wrapper.
I totally agree that Clojure and Noir are a great choice. In dev mode with automatic code reloading, you have a fluid setup.
I am starting to rebel a bit against really fat JavaScript/CoffeeScript/ClojureScript clients as the default implementation strategy. For many apps, using old fashioned forms, render on the server, and after you have functionality convert bits to AJAX as needed to make the web app nicer to use. It is an economic decision: is the cost of a slick fat client justified for a given project?
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.
