Chas Emerick wrote:Chapter 19 in the book is officially titled 'Introducing Clojure to your workplace', but its secondary title is 'Sneaking Clojure Past the Boss'. I think I'll see about putting that up as a blog post or something, as questions about how to effectively bring Clojure into one's organization is a very common question.
I think this topic is worth a thread all of its own. I'll post my thoughts when I get back from lunch but figured it was worth having a placeholder for folks to voice concerns and suggestions.
A key aspect of Clojure is its interoperability with Java. You can write Clojure that exposes a traditional Java class API and you can package Clojure in a JAR file and use it in your Java world, just like any other library. Clojure itself is packaged as such a JAR file - Clojure 1.4.0's JAR file is about 3.4MB - and pretty much all pure Clojure libraries are tiny (just a few KB) because they're mostly distributed as source (and compiled to bytecode on first use in an application). This means you can use Clojure for any subcomponent of your system, design a class API for that and implement it entirely in Clojure, then package and distribute it to your colleagues, without them even needing to know it's not "Java Inside".
Similarly Clojure can interact with any existing Java libraries you already have so you don't need to reinvent any wheels - Clojure fits in on top of everything you already have, as well as being able to fit in underneath your existing Java infrastructure.
Perhaps one of Clojure's most powerful features is the ability to develop interactively in the REPL, allowing you to quickly build scripts and manipulate existing Java libraries and infrastructure in ways that simply are not possible in Java. Imagine demoing a Swing-based GUI to business stakeholders and being able to interactively modify it in real time, accepting their feedback, while the app is running? At that point they'll know it's not Java but they'll be impressed enough to want this new technology anyway.
I've actually volunteered for a collateral project to explore the benefits of the "up and coming JVM languages." It was meant to be just an academic paper that I would post on the company confluence site for everyone to ignore, but I've actually started to enjoy Clojure so it will probably end up being more. From all the papers I've read, videos I've watched, and the chapter from the book (thanks to the Book Promo contest I won), I've found quite a lot of selling points for Clojure. Not only just in and of itself, but also compared to any other technology that we could adopt.
There are some hurdles to overcome like a paradigm shift from over-used OOP to FP and the fact that it does have totally different syntax that seems a bit daunting at first. Still, if I can prove out all of the good points that I've seen I'll have a great case.
I saw Paul deGrandis's talk on Clojure-powered startups and he said that Clojure manages risk better than any other technology. That's definitely an underlying theme that would be good to have.
It will be interesting to see how my strategy works. I know "sneaking Clojure past the boss" is just tongue-in-cheek, but I'd like to think my boss is more open to good ideas so i can take a more head-on tactic.
When all you have is a hammer, everything looks like a thumb.
I've run into a few delays while trying to do this side project since I had to prepare for my java certification exam (which I passed) and do a lot of other non-programming tasks. So after four months I'm just now getting back into it. I've learned quite a bit of Clojure in the mean time and I've started thinking in more of a functional way.
I'm really leaning toward using a database example for my presentation. Some of the pain points with databases are messy queries, verbose prepared statements, and object-relational impedance mismatch.
On my github account I've started a Clojure project that uses clojure.java.jdbc and sqlKorma . I'll be adding to it over the course of next week. Since I'm using an Oracle database I'll post the tkprof output to show the performance.
If you run into any problems with java.jdbc and Oracle, let me know. I don't have an instance to run tests against so Oracle is "supported" only by virtue of testers in the field reporting bugs back to http://dev.clojure.org/jira/browse/JDBC and then me trying to fix the Oracle issues without breaking support for any other databases!
I'll be interested to hear what you think of Korma.