Initially I taught myself Clojure because it is a lot of fun. That lead me to using it for prototyping a currency trading application and since it worked well we just kept using Clojure for that. Some customers don't care about the technology as long as the app is earning them money.
I also looked for some other ways to demonstrate its value: I got Clojure into some other projects simply by building tools the projects needed very quickly (part of this is now open-source in the form of a spreadsheet library: http://github.com/ative/docjure). One example of this was munging data into Excel sheets for editing by customers and re-importing the edited data into the source format done in very little code. Clojure is like LINQ on steroids: even skeptics find it hard to argue against succinct code like (->> (load-workbook "spreadsheet.xlsx") (select-sheet "Price List") (select-columns {:A :name, :B :price})) ; Output > [{:name "Foo Widget", :price 100}, {:name "Bar Widget", :price 200}] Step by step things like this build up Clojure's credibility. We are a .NET shop so I am currently looking into using Clojure reader- macros with gen-class as a DSL to generate some of the code that goes into our Domain-Driven Design applications as DLLs so it can still be used from the existing VB.NET/C# code and with IntelliSense support in Visual Studio. This has a clear immediate benefit (less code, less work) and provides a long-term option for gradually expanding the use of Clojure in our enterprise .NET applications. It is also an extremely safe way to do it, since we can use the existing test suite on the new version with class-gen'd code replacements so it does not impose any risk (which is good in financial applications). Some other advice: * Ignore Everybody (hat tip to Hugh Maccleod) - remember that there are still people who have not tried Rails yet even if it was already very convincing 5-6 years ago. Don't waste your time on them. In 5-10 years time they will come around and try Clojure. * Get some experience with it as support for the projects - for example as tooling. You gain the experience, you can demonstrate that it works and you avoid endless discussions about "untested" technology going into the heart of enterprise apps until you have some good cases on hand. * Ease it in gradually by mixing Clojure components into existing applications. * Be patient - Clojure is still small so you will have a huge advantage over the mainstream the next many years by starting now. * Don't be too patient - if you are in one of these industrial-age organisations that favour easily replaceable labour and prohibit learning new things that are not yet known to every other programmer on the planet maybe it's time to move on. Finally, look for sweet spots for functional programming - using a parser combinator such as FnParse makes it very easy to write a parser or create an external DSL, or you could use macros to create an internal DSL very easily that would be difficult to do in other languages. This would provide a good show-case. The best selling point, however, is probably that Clojure mixes well with the existing languages you may already use in your company (.NET or JVM) so you can adopt it gradually. You don't have to retrain everybody for everything in one big-bang event. Much as I love Emacs, if only we could have Visual Studio integration and ReSharper support for Clojure refactorings we could really have a breakthrough in acceptance :-) Cheers, Martin www.ative.dk github.com/ative github.com/mjul -- 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
