I would ask "what problem would Clojure solve that the current technology X doesn't"? There are no invalid answers to this, but it is important to understand *why* you want to move to Clojure.
Perfectly valid answers might be: - our domain is best solved with functional programming and we want to stay on the JVM - problem X is best solved using macros - I am bored with writing Java - our apps are trivial and there is far too high a signal to noise ratio when using hibernate, spring etc. - our domain involves highly concurrent mutation of state and needs to scale vertically I would also identify the risks as well. Ultimately you need to be able to articulate why, both to yourself and your bosses. Just to throw the cat into the pidgeons I went through this very same process and concluded that Scala was a better choice for me - I just can't give up that strong typing/API boundary contract enforcement and I just couldn't make the leap to functional programming fast enough principles. I have to say for me, OO was working fine as well but that is another story :). In my experience, any change of technology *and paradigm* will cost more than you expect, so if you do make the leap cover your back and make it explicit, which will ultimately involve justifying it. Col P.S. I still thing Clojure is absolutely fantastic, and I am still craving to try it Clojure, but I need to take a longer path than my usual install it, build things and then learn about it :). Is there a "Functional programming with Clojure" coursera course? On Monday, 7 January 2013 23:02:37 UTC, David Jacobs wrote: > > Hey guys, > > As someone who's written Clojure for a couple of years now, I would love > to convince my new company to build our platform using Clojure from the > start. Clojure is certainly a possibility for our small team, but a few > questions will have to be answered before I can convince everyone that > Clojure is worth using: > > 1. Would it be harder to hire if we built our apps with Clojure? More > specifically: Hiring for people who know about or already love Clojure/FP > is certainly a nice filter for talent, but is it too stringent of a filter? > What percentage of the Clojure community wants to code Clojure > professionally but isn't right now? Do we have metrics on that? > > 2. What are good examples of complex domains that have been tackled with > Clojure web apps and API layers? > > 3. What major road blocks have teams discovered at the edges of Clojure > (keeping in mind that perhaps several of these problems could be solved > using native Java calls)? > > What other tips do you have for convincing an employer that Clojure makes > good business sense? (Of course I've already told them about > domain-tailored abstractions, containing complexity, the ease of data > manipulation with a functional language, etc.) > > Best, > David > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en