The other thing I think is worth considering in a move to Clojure is how different functional thinking is. I mean, if you're used to moving between C and Perl and Python and PHP and Java and Javascript and so on, you're used to language transitions within more or less the same paradigm. It feels like a categorically different problem to try to transition a team from one of those to a functional language.<p>I'm thinking in particular of this section from O'Reilly's Clojure book: <a href="http://books.google.com/books?id=I8KdEKceCHAC&ots=wNiLN6Tce5&pg=PA138" rel="nofollow">http://books.google.com/books?id=I8KdEKceCHAC&ots=wNiLN6...</a><p>They lay out a couple of algorithms in an imperative style, and then gradually morph them into a functional style. It's pretty wild: you go from a story, "do this, then do this, then do this" to a math problem: "your answer is a list composed of f() of g() of h() of another list". (Unfortunately you only get snippets from that link -- it's worth the money to get the whole thing if you're interested.)<p>Anyway, having followed through their examples and done some of my own Clojure programming, I ended up not so convinced that people who are good at solving story-style imperative problems will necessarily be good at solving math-style functional problems. It felt like a different part of my brain.<p>This is not <i>at all</i> a reason not to dabble with functional languages, just a potential pitfall to be aware of if you're thinking of bringing a whole team over. And maybe I'm overstating it? I haven't dabbled too much myself.
This example is missing the corresponding Clojure code, which is important for Java interop:<p><pre><code> object.method(arg) // Java
(.method object arg) ; Clojure
</code></pre>
I'm not sure if focusing on syntax and succinctness is such a great approach though. When I've discussed Clojure with colleagues familiar with Java, they've been more interested in the concurrency support via immutable data structures and reference types, which really sets Clojure apart from other Lisps. I think it's a much more compelling sell that way, since Java programmers seem to be attached to Java's syntax and static typing, but are aware of how difficult it is to write correct concurrent code. YMMV of course.
I made a similar presentation a year ago to a bunch of fellow quants at the bank. I chose Scala, and my presentation was mostly code. Quant Finance tends to be one of those areas where Scala really excels. For example, a time series is just a running fold. So instead of having an imperative for block with various indices & guards, you can write a 1-line prefix scan to price a 5 year CDS. My examples also included bond pricing, vanilla calls and puts, binomial trees, monte carlo generators, portfolio optimization, risk calculations ( VaR & CVaR ) and a few graphics. My manager was very open-minded when it came to technology choice, and my fellow quants were somewhat tough on the 2 hour presentation, but the end result was what I believe is called a win-win. We've since pushed a bunch of apps coded in Scala into production, and the group has embraced the language quite enthusiastically.
If I was manager wanting to decide on a substantial technology change like Clojure with a presentation like that I'd have to answer "no". It doesn't answer some of the most important questions:<p>1) What level of support is there for the Clojure toolchain? Is this likely to be around in 5 years from now?<p>2) We are going to need to hire programmers in the future. Are there people with Clojure skills (or those that we can cross-train) around? In our geographic region? At the price point we can afford? In 5 years from now is it likely that this is going to be a marginalized technology that we have trouble finding skills for?<p>These are the more important questions, not how succinct the language is. I've had first-hand experience of how technology choices affect companies and it can be very painful down the road.<p>(Note: this isn't intended as a dig at Clojure, you could replace it with Scala, or any other up-and-coming language choice.)
To the OP: If you have to take a cheap shot at Perl in order to demonstrate the benefits of Clojure, then you have failed.<p>For the record, I am not implying that Perl is above criticism. But, showing a single arbitrary perl code segment, and touting that Clojure doesn't look like it is not fair comparison.
Andrew mentioned <i>The Joy of Clojure</i> (<a href="http://www.amazon.com/The-Joy-Clojure-Thinking-Way/dp/1935182641" rel="nofollow">http://www.amazon.com/The-Joy-Clojure-Thinking-Way/dp/193518...</a>) and <i>Clojure Programming</i> (<a href="http://www.amazon.com/Clojure-Programming-Chas-Emerick/dp/1449394701/" rel="nofollow">http://www.amazon.com/Clojure-Programming-Chas-Emerick/dp/14...</a>). Both books are good, and each has its strong points.<p><i>The Joy of Clojure</i> goes into to Clojure philosophy and explains the "Why?" of Clojure. <i>Clojure Programming</i> is divided into five parts, and parts III and IV provide a good overview of how to set up your environment and structure projects.<p>But the best book for learning the language is <i>Programming Clojure</i> (<a href="http://www.amazon.com/Programming-Clojure-Stuart-Halloway/dp/1934356867/" rel="nofollow">http://www.amazon.com/Programming-Clojure-Stuart-Halloway/dp...</a>) by Stu Halloway. Stu works alongside Rich and understands Clojure at a deep level, but he's still in tune to the beginner's mind and is able to clearly explain concepts and provide the context you need for the ideas to resonate.
-slightly off topic-<p>I really like some of these languages. Clojure is something I've worked with but haven't built a complete product from, but I'd like to make something standalone.<p>I just wish there was a single website devoted to re-creating the terribly boring "Employee Directory Website" app in each language of choice.<p>It would be even better if the creators of said language would go through the time to make the example site so I could see how they imagine a CRUD layer working, or sessions, or REST/XML data, or the sql connection.<p>For every "new" language it seems I can find a hundred examples of fibonacci sequencing (or more recently everyone seems to enjoy creating 'twitter in 5 lines of code!') but almost no real "boring web stack" examples.
Many of these presentations come across as proselytizing. It's an immediate turn-off to some developers and most all managers. The proselytizer claims to know or be able to understand things that others on the team cannot. It's condescending. You wouldn't say to a co-worker... "I understand why we should use X, you do not, so I'm going to enlighten you and explain this to you in a way that you can understand and see the benefits of."<p>The best way to gain traction and to get others to use your favorite tools is to write code and implement projects on time and under budget that are reliable and easy to maintain. If you do that, then the tools that you use will be in demand. Others will <i>want</i> to use them and they will speak for themselves.
Pretty nice intro / advocacy piece for Clojure. I have high hopes that once we're flooded with more example code people will start to see the simplicity of Clojure. Right now the reference is somewhat terse, but you can dig around GitHub quite a bit which is nice. Also, it seems that the combination of people working with contemporary problems and small and succinct generics that you wind up making in Lisps, there could be a lot of great reusable code for this language out there soon. I'm also curious about <a href="http://www.collaj.net/" rel="nofollow">http://www.collaj.net/</a> ... the Redfoot project for RDF / Python seems to remind me of this... that we're not paying enough attention to the "Google / Paste / Execute" loop.
This may seem superficial, but Clojure's usability is a problem. The source-code itself is hurt by the same thing that makes it strong: homogeneity. Even at a superficial level, skimming with the eye, closure code looks strange. It is exactly the same problem that markup that is all divs has when compared to markup that uses common top-level markup. It's hard for the eye to pick out what's important, and what's going on. In addition, indentation rules are not agreed upon and it's a bit stutter stop. (I actually think this is a worse problem then the "inside out" problem).<p>Aha! I just had a really good idea! Let's call it "Clojure folding". It's like code-folding only instead of hiding lines, you pull up all the code into one line. Some of the internals may be elided - and revealed with a tooltip.<p>I also like the idea of coloring the entire content of the parens, so that you can embed a large item and then clearly see that you are now back in the containing list. Indentation doesn't do a good enough job, nor do rainbow parens. Further, you'd get a good intuitive sense of place in the code if you have a consistent series of colors. Emotionally, you'd know that if you're typing read you're like 6 layers deep - and that's really deep, in the danger zone, and you probably want to pull some stuff out into definitions.<p>Chris Granger, feel free to include these ideas in Light Table.
Clojure keeps looking more and more interesting. Noir, in particular, has caught my eye. Anyone have a link to a high-quality Noir tutorial? (high-quality in the sense of straightforward yet useful)<p>Nice article, BTW. Good intro for those not familiar with Clojure yet.
Interesting article, but its only skin deep... The larger issues are down the road, it's where the engineers and the sophomore programmers are separated.
I really like Clojure as a language, but the JVM implementation takes over a second to start. This lack of responsiveness makes it a poor choice for many small scripts that should run quickly. If not for this issue, I would probably use Clojure on a regular basis.
I do consulting for small businesses around where I live (Mexico). And since like 3 months ago I switched to clojure and I couldn't be happier. I used ruby then python before. Now there is one minisupermarket doing billing and inventories and backups and charging customers with clojure in Mexico and that number is looking to grow!