Why I am so excited about Clojure and why I think its going to explode.
I am by no mean an expert on this matter, but I recently went to a company job interview which dealt with Clojure, so in doing my preparation I knocked up a lot of stuff which I wanted to write about.
It’s kind of funny because it never easy to identify emerging technologies but it is possible to predict by looking at a variety of changes and how these changes come together.
There is very little doubt that big data is going to take off. Why wouldn’t the National Health Service want to know what conditions effect the likely hood of cancer or high blood presurse or, an advertising company distinguishing which advertising campaign are most successful. The meaningful information we can retrieve is endless and it just makes sense.
In addition we need to look at our current hardware, companies such as Intel and AMD are finding it harder and harder to develop processors that are faster the exponential development was saw int he 90s is over, it is just not possible to develop CPU switches that move any faster. So instead we are living in an era, and will continue to, of multi-core processors. We can see this with quad cores and even dual processors in phones. Don’t be surprised to see 1000 cores in your computer on day. In addition to this Google server developer strategy is horizontal, not vertical, meaning they are expanding by creating more server farms that they use to distribute the work load of their processing. Their not buying in more powerful servers, but instead have the challenge of dealing with computer across different network.
Over the past 20 years or so OO has dominated the landscape and rightly so. It provides structure and a simplified way of organising your code. OO design patterns such as MVC are going nowhere. But today with live in a world with events, mobile phones trigger events, more intricate interaction with UIs and apps all trigger a vast amount of events and traditional OO doesn’t embrace this style of interaction as well. Instead functional programming copes better. http://www.ibm.com/developerworks/library/j-ft20/.The ability to add a load of functions that are triggered on events and then call another function which returns a function that can then be use as an argument for another function, allows for more dynamic, flexible programming. I am not saying this is the end of OO by any means, but rather functional programming is seems to be a better fit for many programming challenges.
Now you ask how does this all fit in to Clojure.
Clojure has an amazing ability to deal with data, since in essence everything in Clojure is data it become very easy to handle and manipulate data. For example a set of functions used to manipulate data structures work the same on all data structures, so you can transform data from one structure to another and still apply the same functions. This is essence is perfect for Big Data as the data mined by companies can come is all sort of formats and structures. Most instances they may be totally unstructured.
Traditional languages use mutable data, meaning you change the state of data in objects. Clojure uses immutable data structures, meaning you create a copy of the object and then make the change to the spefic data leaving the rest of the object the same. For example if you had an object Person which had data name you would, with mutable data structures, setName and the object state would now be changed. In Clojure you would make a “copy” of the object and then change the data in the new object leaving any other attribute the same. Of course now you would have a problem since you have two copies of the object Person which takes up a lot of memory if you were to create thousands of changes, so Clojure deals with this using a GitHub version control style system for tracking changes. So it’s not that the Person object is copied when changes are made but rather a track of the changes are made which can be accessed as a object.
Clojure has a strong infrastructure for multi threaded programming. Like I said before the world we live in is strongly moving to distributed processing and multi-core processors. Clojure provides a perfect way in handling this not only in its multi threaded programming but also with the immutable data structures we talked about above. The problems arises with tracking data that is changed when streamed across different threads. If the object Person is accessed across 12 different threads and is changed the handling of that change can become very difficult when multiple threads are trying to access/set the same data. With immutable data types a tracked copy is made which can be accessed without the problem of collisions through accessing or setting data at the same time. Think of it much like a group of people modifying an excel spreadsheet at the same time.
Clojure is a functional language which provides many fun advantages to coding namely the dynamic, expressive nature of writing code. Yet Clojure has is that it still access to the full Java library because Clojure runs on the JVM. This means Clojure has the best of both worlds being fun, expressive syntax with the solid backing of a language like Java.
I probably haven’t covered all the advantages of this new language and I certainly haven’t covered the know dis-advantages but I have explained some of the pro’s that considering where things are going, are hard to argue against.
Technology mixed with a little Zen 
I find the benefits for multi-core and multi-machine processing still too hypothetical. I can’t just deploy my clojure program on a big cluster to make it run faster.
Machiel is that because it’s just not widely possible in Clojure or because the language is still new and in later updates the problem should be fixed?
You can use libraries like Storm (https://github.com/nathanmarz/storm/wiki/Clojure-DSL) if you want to deploy Clojure computations to big multi-machine clusters. People have been doing stuff like this with Clojure for years. In general, *no* application can be deployed transparently to a big cluster without architecting it appropriately (typically using some framework like Storm, or restricting yourself to a language that is designed for distribution like Erlang).
As for the multi-core stuff, the Clojure code is already IMHO very solid thanks to the STM model, the concurrency features and immutable data structures. But that’s a very different story – distributed applications simply have different semantics from single-machine applications.
Clojure-the-language is really designed for multi-core processing, it relies on libraries for the distributed stuff.
There are already few implementation of actor model in clojure. I think immutability + end = solid ground for actor model implementation.
There is no language that can be deployed to multi-machine cluster without any additional efforts. Even erlang.
I think that was his point. The whole idea is still relatively impractical.
Machiel, the benefits of multi-core are very real and present-day benefits. As far as automatically running an application as a multi-node paralelized application, that is kind of an odd requirement seeing as it’s no more difficult or easy to do using any other language or framework. Or maybe you are implying Erlang is your language of choice and you can live with its various downsides for your particular use cases?
Hey Vish. Nice meeting you yesterday. It’s great to see you so excited about the possibilities of Clojure and functional programming. If you have some time, I advise you to also have a look at other members of the Lisp family, it give you a good perspective of what’s truly a Clojure advantage, and what can be found in other languages. Maybe touch a bit of Common Lisp (There are fun books! The Land of Lisp by Barski, http://landoflisp.com/ — maybe Bruce has it and can lend it to you :P), a bit of Scheme (http://racket-lang.org, easy to install), maybe Shen (http://www.shenlanguage.org/). Then, to gain even more perspective on the power of Lisp, you may want to try out other FP languages: Haskell (http://www.haskell.org/haskellwiki/Haskell), a member of the ML family, like Objective Caml.
In the same way as switching from Ruby to Clojure gave you a good perspective on the power and limitations of Ruby, trying other functional languages will let you discover more about Clojure from the outside.
Thanks Alex!
It was great meeting you too. The Dojo was great last night I really enjoyed it. I will certainly look at those recommendations and I will be going to the next Dojo too. Hopefully I’ll see you there or we can meet for some code and coffee.
I’m not based in London, but next time I’m around, I’ll see you at the Dojo 😉
When I last looked at Clojure, it seemed like a better Java in the sense that most of the useful bits were lifted from Java and associated libraries. To put it differently, the Clojure code I saw was difficult to read–since I am not a Java expert. This is in contrast to Scala, the other big JVM startup language. Scala doesn’t seem to require that a programmer know Java to get real work done. Clojure code lifted from Java all over, which is fine if you already know Java, but double the work if you don’t. Is this a false impression, or have things changed? If I were in the market to learn a new language at the moment (I wish I had the time), I’d probably try Go.
I was working with Clojure a little over a year ago for my thesis project and definitely felt similar excitement. The multi-cpu utilization was amazing. Functional programming was definitely a challenge to learn though.