Clojure with Uncle Bob

Written by Jorrit Friday, 24 September 2010 07:16

Last week I attended a dojo with Robert Martin. Martin re-asserted that Moore’s law has had its day, which is something Moore himself agrees with.

‘Forty years after the publication of his law, which states that transistor density on integrated circuits doubles about every two years, Moore said this morning: “It can't continue forever.  The nature of exponentials is that you push them out and eventually disaster happens.”’ (Dubash, 2005)

An alternative to relying on better hardware - to relying on Moore’s law - for better performance is to utilise multiple processors.  To take advantage of multiple chips, solutions have to be expressed properly.  This is why, Martin says, we should use functional programming languages.  

A very clunky example of using more than one chip is the way in which a web-server directs HTTP requests to different machines (session state, to allow for this parallelism, is often captured in the HTTP session that bounces back and forth).  At a finer level, parallelism can be achieved, for example in Java, by using its concurrency libraries.  However, you have to use them and you have to make sure that the results are correct.  That’s to say, you need to design the parallel algorithm with joins, barriers, mutual exclusion and you have to do all of that with what Java offers; a sequential algorithm cannot be magically parallelized.  (Libraries like OpenMP, to some extent, allow the parallelization of sequential code.)

public class ForExample implements Runnable {

 public void run() {
   int[] numbers = new int[] { 1, 2, 3, 4, 5 };
   for (int i = 0; i < 5; i++) {
    System.out.println(numbers[i]);
    sleep(1);
   }
  }

  public static void main(String args[]) {
   new Thread(new ForExample()).start();
   new Thread(new ForExample()).start();
   new Thread(new ForExample()).start();
 }
}

I run this program three times and get these results:

111234223344555
111234234523455
111234234523545

The results are unpredictable.  (Try it yourself, don’t forget to implement sleep, which is necessary on performant machines to add some randomness.)

In short, what I understood from the talk, because functional languages don’t have side effects, and this is guaranteed, their runtimes can enable the algorithms to be expressed concurrently.  That’s to say, programming error, in terms of concurrency, is not possible.  Just as Java - but not C# - protects the programmer, to a degree, from destroying memory, functional programming languages protects him from the overhead of designing performance in (of course, some algorithms, and data structures, are better than others, the choice of which will still be in the hands of the programmer).  But, as John Shalf, I think wryly, points out, this is only ever a strategy for parallelism ‘if and only if you are willing to express your algorithm using a functional language’.

Clojure, in case you didn’t guess by now, is a functional language.  After devouring a few slices of pizza, everybody settled down for Martin’s presentation.  After a brief introduction to Clojure, Martin fired up the REPL (read-evaluate-print-loop) and we were ready to take our first steps into the language.

(+ 1 2 3)

This reads 1+2+3 and indeed it returns 6.  The Clojure syntax for a list containing elements a, b and c is:

(a b c)

In the first example, we created a list with four items: +, 1, 2, and 3.  This worked, returning 6, because Clojure is a homoiconic language, that’s to say that ‘program code is represented as the language’s fundamental data type’. Confused?  I was.  Sort of.  The computer scientist in me - there isn’t one - might have got it.  However, the mathematician in me did understand functions and therefore their lack of side-effects.  

We continued.  Martin’s flamboyant - but very clear - presenting style made it easy to digest the walkthrough of the basic features of the language.  Martin went on to demonstrate Clojure’s integration with the JVM. This allows hassle free use of all your favourite Java libraries. To demonstrate the power of the combination, Martin showed us a gravity simulator built in Closure using Swing packages for the graphical representation.  Super cool.

In summary:

• No matter how you look at it, the modern financial engineer, the one who does well, will have to get to grips with computer-sciency things.  This, as each year passes, becomes more and more futile to deny.
• As we tend towards more sophisticated problems, their solutions will have to evolve with them.  For high performant systems, this could mean creating hybrid solutions - solutions that integrate imperative and functional programming - with coherent engineering management.
• This stuff is hard.
• And exciting.

It was a fun get-together, and thanks again to Agile Holland.  Martin’s introduction to Clojure was enough to get me thinking about how I could use it in my daily work... but, I am not ready to give up my objects.  Not yet, anyway.

Further Reading/Next Steps
For those brave enough, you can download Clojure and get cracking straight away.  For the .Net platform, there is F#, which combines functional and object-oriented paradigms.  John Shaf gave a great interview recently, which is useful for understanding different strategies for parallel programming.

References
Moore, Gordon E. (1965). ‘Cramming more components onto integrated circuits’ Electronics Magazine. pp. 4. Retrieved 2006-11-11.

Dubash, M (2005), ‘Moore’s Law is Dead’, IDG 2010.

International Science Grid, ‘Q & A - John Shaf talks parellel programming languages’.