Some Thoughts About Clojure

The new Web 2.0 languages are trying to solve what is an old problem: making the most out of processor and RAM scarcity.  Except, this time, instead of having actual scarcity, we have manufactured scarcity in the form of cloud computing: lashing hundreds of tiny slices of computers together to make one whole.  Back in the day, when scarcity was real, and building networked and highly threaded applications was the way to go, and before servers got fat and bloated and lazy, functional programming was a theoretical way to make the most of resources.

Functional programming is designed for highly threaded apps in a scarce resource world.

Procedural programming is designed for event-driven applications in a universe of processor abundance.  

That leads us to the Erlang/Scala/Clojure trifecta and to Stuart Halloway's book, Programming Clojure 2nd Edition.  Which, in a change from anything resembling normality, I sat and read instead of randomly skimming the two chapters introducing the language and then ripping right into "how fast can I stand up a web application with this?"

And now with the bullet points, cuz I love bullet points.

  • Clojure, or at least Programming Clojure, is a much kinder, gentler introduction to FP than Erlang or Scala.  Erlang is a bit like being repeatedly punched in the face by someone holding a mathematical treatise on tail call optimization and screaming and how do you like them nuggets huh huh huh?*  Scala is just that guy in the corner with the neckbeard who has no patience for you not getting it.  Clojure, because it will blow its stack if it goes all in with TCO, has a much nicer model for easing into the FP paradigms.  The lengthy chapter on Functional Programming in the book with specific examples and pitfalls helps immensely.  
  • Ruby developers should feel at home immediately with the ISeq object and the sequence macros.  Much of it looks and acts exactly like ruby's FP and metaprogramming paradigms.  If a developer likes to iterate over sets of data from database calls using .map() then they will be comfortable here.  Clojure is a clear on-ramp from ruby.
  • The ability to easily include Java libraries and just use the calls is ridiculously powerful.  You can just pull in java.io.File and use all of the file manipulation calls directly from Clojure without any sort of weird jury rigging.  The integration is smooth.
  • Anonymous functions are not confusing like they are in Scala. 
  • After a few hours of reading it, Clojure's version of LISP reads more like English than anything else.  But that's LISP bringing its crazy hot mojo to the table more than anything Clojure does.
  • Like any other language running on the JVM like Scala and Processing, Clojure actually can do anything Java can do -- except in LISP.   
  • Database connectivity is just through JDBC and works pretty much like calling a database through JDBC.  As long as you have a JDBC adapter, you're good to rock and roll.

I cannot comment directly on the threading model yet.  

If you're a ruby programmer and looking to get a 10x speedup on a tiny box out of the same sort of code, I feel like Clojure is the clear next step in evolution.  The line from ruby... Clojure simply isn't that long.  Two weeks of working with it, maybe, and getting used to the templating libraries and ring/compojure and should be able to rock and roll.  With a prolific ruby programmer who uses ruby's list comprehension library to its fullest, the change should be smooth.

I'm not sure Clojure is the next step for Python and Java programmers.  That still feels more like Scala still to me.  Python does have list comprehension but it's not used the same way ruby's is so it's a higher cliff to climb.  But it's to be seen. 

Anyway, the book is good.  The language feels sane.  I also found Quil, a Clojure wrapper on the Java Processing libraries for drawing and animation, so that's a new toy.

* I desperately love Erlang.  Don't get me wrong.  But it's not for beginners.  Or intermediate.  Or advanced.  Or really anyone.