(please ignore the atrocious speling mistax in my previous post - not enough sleep)
On Tuesday, 8 January 2013 12:05:11 UTC, Colin Yates wrote: > > 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
