software development for the
existentially challenged
Older | Newer Older | Newer
clojure at javaOne got me thinking about functional programming
comment share
I am in love with the new dynamic languages being written on top of the JVM. I've been using groovy for a couple of years now, and still get warm tingly feelings about it. I went to a talk at JavaOne 2009 on Clojure, by Rich Hickey, the language's creator.
"Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs."
Because I'm ignorant and have had a lousy (i.e. non-existant) formal CS education, I've never actually worked with any functional languages, including Lisp. After years of working with Java web apps and dealing with concurrency and objects, I really appreciated what Rich had to say about not working mutable types (except under tight control) at all.

At one point in the talk, he talked about the flaws in the OO model. Essentially (from my notes) he said:
why not OO?
OO encourages mutable state
mutable stateful objects are spaghetti
hard to reason about
disaster for concurrency
encapsulation != concurrency semantics
Since dealing with concurrency in Java is a matter of manual effort, thread safety built into the language semantics is really appealing. You just can't screw up any longer by forgetting exactly what you need to synchronize on, or what bottlenecks you'll create by synchronizing. The functional programming model protects you from a whole class of errors.

Java Concurrency In Practice (an awesome, awesome book) tells us to make as classes immutable as possible. Besides fixing thread safety, once you start cutting out mutable objects wherever possible, a lot of other coding errors just go away. Your design gets increasingly rational.

On the other hand, mutable state is a major feature of OO: to capture, maintain, and transfer stateful data structures. In fact, to not use OO that way is considered poor design. Think of using only primitives, or immutable classes like java.lang.String and passing them from one function to another. That is the kind of horrible proceeduralism that books on OO design and refactor try to get us away from. I've done it plenty of times and it sucks sucks sucks. Good OO code is vastly maintainable than proceedural spaghetti.

The transaction semantics in clojure seemed really neat, and during the talk, I thought I could see how clojure might be useful for just about anything -- except I still don't understand how you create a traditional domain model with it or any other functional language. I don't yet know how to think about solving problems that I would normally use objects to deal with.

How can you construct a model of something without objects? I know there's an answer to that, but I don't yet understand it. I have trouble thinking having mutablilty at all. I'm really attached to my stateful objects. I also understand, stateful objects can be a recipe for concurrency disaster.

I could see using clojure for highly concurrent parts of a system, and intermingling that with Java or Groovy for less touchy, and more model-y aspects of a system. Since I don't know enough yet, I'm not sure how that would work.

I want to really get my head around functional programming. I installed SLIME using MacPorts and have been reading through Practical Common Lisp. (a good tutorial).
Thus far Lisp has been good, clean family fun. All super basic steps, but I'm hoping it makes my object programming smarter.


Post a Comment

What is this site?!

t (a professional software developer for a big company) writes about software development and stuff. Unix, Java, Groovy, OS X, and lots of open source libraries and tools.