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

Reply via email to