You say "an employer" without saying "our employer." Without a doubt, a *team* must be convinced of Clojure first.
Assuming your team is convinced, then my argument is this: You will attract better, smarter people by shifting your company toward Clojure. Avoiding it is comfortable, but ignoring it will set you back on talent. That's the strongest argument IMO. It's not just about the benefits of using Clojure; it's the cost of not choosing it when good developers are in short supply. Anecdote: I attend a fair number of user groups in my area, and one thing is for certain: I'd sign off on hiring, with rare exception, the men and women I've met at Clojure user groups. I can't currently say the same for most other communities I'm involved with. They're a hungry, open-minded, and talented bunch. Cliche: Wasting developer time is expensive, but wasting developer passion is unforgivable. Pragmatism: Anyway, don't ask for permission. If your team is on board with Clojure and your team does good work in it, then skip the approval process and get to programming. If everyone leaves the company tomorrow, your employer will be better off hiring Clojure programmers than they will be hiring .NET programmers. Passionate people make the world go 'round. Cheers, -- '(Devin Walters) On Monday, January 7, 2013 at 5:02 PM, 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 > (mailto: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 > (mailto:clojure+unsubscr...@googlegroups.com) > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- 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
