One of the questions I get asked, quite rightly, by the sales and business development people in our company is why bother with learning Clojure, or even Scala, as none of our clients will use it?
So, I could explain how:
- Functional programming tends to result in a smaller code base that’s easier to test.
- Programming with immutable data structures makes reasoning about the impact of multiple threads easier.
- Concurrent programming support like Akka, atoms, software transactional memory and agents mean modern massively concurrent applications are easier to construct.
- Clojure encourages developing applications by composing small lightweight libraries rather than large heavyweight frameworks which makes swapping out implementations that don’t support future requirements or adding new functionality much easier.
- Developing with tools like a REPL (Clojure) shortens the feedback loop to seconds making developing quicker and safer.
- Functions are composable to make for better reuse at different levels.
- Meta programming using structures like traits or macros makes developing Domain Specific Languages that express the problem space easier and hence focus on the actual business problem.
However, none of this matters to sales, business development people or most of our clients. They will argue getting large numbers of developers with experience in these languages is hard to impossible.
So why bother?
- Because these languages generally self select good developers.
- Because developing in these languages means solving algorithmic problems which develops good problem solving skills.
- Because developers who have more than one programming language tend to learn other more quickly and are more versatile.
- Because developing in these languages is fun and that promotes better staff retention.
- Because techniques beyond OO expand a developers armoury to tackle real world problems.
- Because developers exposed to smaller, functional code bases tend towards writing cleaner, easier to maintain code and this reduces the overall ‘cost of ownership’.
But if you don’t want any of this, sure don’t bother to learn anything. Go back to writing COBOL, or assembler. Nothing wrong with those languages of course but things move on.
[Update Jan 2016]
Since writing this in Sept 2014 I’ve moved on from the organisation concerned and they’ve adopted Scala. However, the driver to do so was purely client demand, they had clients who wanted to use it and therefore saw a demand that needed fulfilling. I suppose I should be glad the clients have foresight but I feel a consultancy should lead the way.
I am currently starting a fairly simple Java CRUD web application for work and at the same time I’ve been playing with developing a simple web application in Clojure.
In order to develop the app for work I wanted something I could use to drive out a prototype quickly but then enhance and augment further. So I took a quick look at Spring Roo.
I found I could generate the basics of a CRUD app in hours, including security, etc. Great…or was it?
I found myself unsettled by a number of things in Roo.
- Automatically generated integration tests work well in Roo but I found it hard to find good examples of simple extensions to the generated integration tests. For example, how to test a constraint like @DecimalMax on a JPA entity field.
- I always run my integration tests against a different database in the ‘test’ phase of the build than the database configured for the ‘package’ phase. Usually this is to allow tests to run against an in memory database so they can run fast, clean and without a database server running. This is not something Roo helps you with, and although I’ve done this in Spring and could use the same Spring configuration for the Roo project it’s not obvious or easy how to do this. I just expected it to be something the Roo would support out of the box.
- I am a TDD addict…Roo does not support TDD at all well. It’s possible but not natural.
- Although Roo generates nice clean classes with little boilerplate code as it’s still Java it felt unnerving like magic…I didn’t trust it. I kept having to look at the generated AspectJ to check.
- I always set up my continuous integration server (Jenkins) and maven builds to run code coverage and static code analysis tools (I’m using Sonar this time). As the Java code generated by Roo is minimal, with the aspects adding the bulk of the methods you get a lot of static analysis rules failing (due to rules like, “Unused private field”).
- You also get low branch coverage messages that don’t equate to any code in source files. I suspect that this is referencing code that has been aspected onto the class.
- It still felt verbose and heavy weight compared with Clojure code…just look at the number of jars a simple Roo project requires!
Maybe I’m being spoiled by Clojure but it all felt a bit clunky and too much wasn’t apparent or transparent enough. Having said that, Spring Roo cuts out a lot of set up time. Especially for getting a simple CRUD type web application up fast. If, like me, you have to live in the Java world due to skill sets in your organisation/client then it’s a good start.
You can always push the generated Aspect code back into your Java source if the ‘stuff happens by magic’ feeling keeps unnerving you. I did get used to this within a few days though.
So, overall I’m going to use Roo for prototyping and simple CRUD type applications but really I feel that Groovy/Grails, Scala or Clojure give you more, more transparently. You just need to ‘invest’ in learning them.
In my travel’s around clients I frequently see organisations trying to introduce agile or lean approaches. Sometimes this is driven by a real understanding of the issues and limitations of their current approach, sometimes it’s ‘new shiny toy syndrome’ (new? – this stuff has it’s roots in late 80’s or earlier). Sometimes it’s ‘keeping up with the Jones (or Howe-Jones!)’
Frequently these agile transformations struggle or fail for a variety of reasons. the most common is ‘politics’. Organisations, regardless of size, are full of people, and some people are inherently out for there own interests.
I frequently see Scrum teams behaving cooperatively and transparently but their message to other stakeholders gets filter and distorted by political animals who are living in their own culture of ‘fear and incompetence’.
How do these teams cope with these political influence? Make sure your metrics are in place, burn down charts, definition of done, test coverage, team velocity, etc. then PUBLISH THEM TO EVERYONE!
If the reality of the teams progress and actions is exposed to every stakeholder for them to see for themselves it’s not possible for the organisational politicians to distort the message.
Be open and transparent.
Over the last three months I’ve been trying to learn Clojure on evenings and weekend. I started this roller coaster ride of joy and frustration on the recommendation of my close friend and Clojurian @otfrom.
The start of this emotional experience is rooted in a conversation with @otfrom over a glass of wine at the Open Data Institute. The glass of wine may have been a major contributor to my decision to take the plunge into Lisp for the JVM. The conversation went something like this:
- Me: I’m keen to learn functional programming as I think it has advantages over Object Orientation, especially in the brave new world of ‘big data’ and the increasing emphasis on massively concurrent processing. I’ve started reading a book on Scala because as a Java developer I thought it would be a good place to start.
- @otfrom: Sounds like a good idea. Scala is a good language if you want to dip your toe in the world of functional programming.
- Me: Yeah, I thought as it’s like Java I could encourage our other Java developers to start learning and using it.
- @otfrom: OK. Only thing is, do you think that if they’re struggling to learn they might just abandon the functional style and just start writing Java without semi colons?
- Me: ..Oh sh*t, you’re right. The whole point of this is to learn functional programming not write OO in a different language.