On Aug 21, 2014, at 1:48 AM, Arthur Boyer <arthur.bo...@gmail.com> wrote: > One idea that's come up several times is the notion that if we push Clojure > then any problems we have will get blamed on Clojure, and unfortunately this > rings true to me. At the same time, my boss is keen on choosing one language > and sticking with it, something I disagree with, and if we do that it is > unlikely that we'll get another chance to use Clojure in the foreseeable > future.
It's a shame your boss - who won't be coding and clearly has fairly limited experience with modern programming tools - seems so intent on dictating technology to the rest of you. > The boss isn't going to be writing any code, but is very opinionated about > what we should be using, at this point he strongly favours Groovy. At least > it's not Java. At least he's bought into the JVM so you're on the right path. If he's concerned about performance you may find Groovy too slow for certain things (depending on what exactly your company does) and that may be a way to sneak in small libraries that you write in Clojure to replace slow pieces of Groovy. Where I work - World Singles - they had historically been a Windows / ColdFusion shop. When I joined as a part-time contractor five years ago, they were just starting on a complete rewrite of the dating platform. They were still happy with ColdFusion but early on in the project, the new contractors they'd hired pressed for a move to Linux and to Railo (a JBoss community project that provides a FOSS implementation of CFML with a smaller footprint and better performance). One aspect of the platform had always been problematic: the email generator. It really needed to run 24x7 as a background process and CFML is only a web language so they'd tried a few other technologies. Once I was onboard, I suggested a rewrite in Scala (to leverage actors) and got a reasonable version working (in about 1,000 lines of code). It was back in the 2.7/2.8 days so the Actor library had known memory leaks (and the tool chain was a PITA as new versions of Scala broke everything). I was exposed to Clojure in early 2010 - I attended a local "bootcamp" run by Amit Rathore (Clojure in Action) - and thought that might be a promising alternative to Scala for the email generator with parallel map, agents, futures and so on. I wrote a proof of concept (in about 300 lines) and demonstrated it. It didn't suffer from the memory leaks of the Scala version so it was: a) much more stable b) much simpler code (being one third the size of the Scala version) c) slower than the Scala version That initial version was capable of about a quarter of a million HTML emails a day (running lots of database queries and lots of calls to a search engine we use - Discovery by Transparensee). It was enough to get it accepted as our production version. A few, relatively small, tweaks to the code boosted performance to three quarters of a million HTML emails a day and subsequent tweaks boosted it to about one and a quarter million. We added two more instances of the process, configured for different searches, and the search engine became the bottleneck. We've just completed an upgrade and reorganization of the server infrastructure and now we're ticking along at three million HTML emails a day. Once I'd shown Clojure was viable for us (back in 2011), we started rewriting a lot of low-level parts of our CFML code base in Clojure and gradually started adding other processes fully written in Clojure. Our real time chat service is all Clojure on the back end. Nearly all of our scheduled tasks are pure Clojure and all of our "24x7" processes are pure Clojure. We have 21,000 lines of Clojure at this point. We're slowing moving toward a time in which CFML will remain only for Views and Controllers and our entire dating platform Model will be Clojure. Eventually I hope we'll replace CFML with Clojure even for the Views and Controllers. We're also building an internal app entirely in Clojure(Script) using Om and Sente (core.async over Web Sockets). Based on my experience at World Singles, here's my recommendation: go with his choice of Groovy to start with (and Grails, I assume?). Look for small pieces to write in Clojure and sneak them in where they improve performance or dramatically improve maintainability. Don't go overboard - do it only where you can show a clear improvement over the Groovy solution you've already created. Don't push to cross-train other developers. Don't push to write all new code in Clojure. Slowly, over time, you'll just find you're using more and more Clojure and having fewer bugs and being able to adapt to changing requirements faster. As long as you don't make a big deal of it - and you're careful to make sure each new piece of Clojure is a success - better than the Groovy equivalent - your team will slowly make the change. I was the only Clojure developer at World Singles for quite a while, then another developer switched (she had experience outside of CFML). Now a third developer is coming up to speed. We're at a point where "all new code is Clojure" is the official position even when it isn't quite the reality - after three years of slowly introducing Clojure where it made sense and expanding those islands into a continent. Oh, and just last week, our database systems guy, whose been doing a huge amount of data migration via Java said he was just starting to learn Clojure and was looking forward to getting away from objects and Java's verbosity and fussiness! Good luck! Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880)
signature.asc
Description: Message signed with OpenPGP using GPGMail
