This is a bit of “stream of consciousness”, so… maybe it’ll make sense, maybe you’ll tell me to lay off the caffeine. 😉
A while back I watched a Clojure discussion in an interview with Stu Halloway. Stu obviously loves Clojure and it might be his hammer with which every problem is looking like a nail, but I’m gonna give him more credit than that.
In the presentation, he said something about “maybe we got it wrong” with how we manage state in applications that resonated and got me thinking… did we? Maybe there’s something to the functional programming idea.
In most web applications today, the idea is to remain as stateless as possible. In most of my applications, we grab a bunch of data from the database, munge it into a object model, then turn around a munge it back into text for display on a web page (or into XML). The biggest benefit I get from the object model is ease of relationship navigation and potentially calculated values via derived properties.
Its a similar story when trying to save data. In this case I’m taking a bunch of text values mapping them into an object (or possibly a graph of objects), doing some calculations, workflow, validations and the mapping it back to the database. There is potentially more value on the “save” side of things, but still in most applications, I’m not sure I get a lot from this. The graph “lives” for only a very brief moment and much of the CPU time is just doing the mapping. In Rails when posting data, if you follow the conventions your parameters map through objects directly into the database by virtue of using the same name. In the basic case, the object is serving as a map of values for an update statement.
There just isn’t much interesting real object behavior going on.
If you think about the interface between the browser and the application server, it is essentially a complex, functional interface. Furthermore, the interaction with the database or downstream services are, again, functional.
Maybe we’re pretending in most cases to have state in 3 places – browser, application, and database, when in fact its actually only relevant in 2 – browser & database. Perhaps we’d be better off using a functional language for solving those problems? Is this where the value lies? Maybe the domain model is really only relevant where state is needed, where the objects (data) comes to rest – I’m thinking the browser in particular. Personally, I got the most benefit from a object model back in the old days of “fat client” programming where the application managed it’s state and I bound my objects directly to the UI elements.
I’m not saying that decomposing data into “objects” is a problem. I’m just beginning to wonder if Object-Oriented languages are the proper tool for the job of “stateless application development”. Is it possible that I’ve been seeing OOP as the hammer by which every problem is a nail?
It might be time to explore Clojure…