Uncovering similarities of Clojure’s data structures with other solutions

It’s just crossed my mind while I was reviewing the course material for WD507 REST Service Development with Java. I didn’t give much thought to it, but just realized that the View layer in the Model-View-Controller design pattern is basically to “isolate “domain logic” (the application logic for the user) from the user interface (input and presentation)” and is very similar to Clojure’s seqs and maps to build a model. Isn’t it what Clojure and, I think other functional programming languages, do with their data structures with many functions and/or macros dealing with them via a unified interface (in Clojure it’d be seq)?

In functional programming (I’m getting a handle of with Clojure’s glasses on) data structures are often unified with a kind of clojure.lang.ISeq or just the seq interface. It makes working with them easier and allows separating functions (verbs, actions) from data structures (resources, objects) they operate on. It’s about separation of concerns and, guess, Clojure does this quite well. It’s so similar to the concept of JSON as a (data) structure which, because of its rather loose structure even thought it’s structured in some way – a map, a record or how you’d call it – makes communication between JavaScript in browsers easy (easier?) with JAX-RS server-side resources.

It thus reminds me the course material for WB711 Developing Applications for IBM WebSphere Process Server V7 – I in which a canonical data model for business processes that communicate with disparate external systems was so heavily emphasized. There you should also strive for a unified data structure, which in the case of IBM WebSphere Process Server is Service Data Objects (SDO) with Business Objects as its (default) implementation (with a possible replacement with the new fix pack V7.0.0.2 for IBM WebSphere Process Server).

I’m an IBMer who, amongst the other tasks I’m paid for, teaches IBM courses, and learning Clojure helps me to draw such conclusions.

All in all, pulling it all together makes me think about Alan J. Perlis’ “It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures.”.

I was discussing it the other day with my colleague after a presentation of mine about Clojure, and I could hardly find a reason to have maps as an alternative for classes with their own internal (encapsulated) data manipulation methods. He kept saying it’s such an uncontrolled structure that no one will know what it ends up like ultimately. He was simply scared to have such “unstable” data structure to hold business data. I was scared, too, trying to cope with his worries and couldn’t address them.

I’m still building up understanding of the concept and hope to find a reasonable explanation before the presentation of mine during the conference 33rd Degree in Krakow. With this and the other conferences I’m speaking at – DevCrowd in Szczecin, 4Developers and GeeCON in Poznan – I’m going to solicit feedback about my current understanding of how I see things work in Clojure. I do hope I won’t spoil the other people’s goal to reach a final and moreover proper conclusion.

Be Sociable, Share!
This entry was posted in Languages, WebSphere.

One Response to Uncovering similarities of Clojure’s data structures with other solutions

  1. Konrad Garus says:

    Did you see Rich Hickey’s “Simple Made Easy” (http://www.infoq.com/presentations/Simple-Made-Easy)? It’s interesting for learning some principles behind clojure and functional programming (*nix pipes anyone?), and also entertaining for bashing popular tools like TDD or agile.

    The conclusion is: Everything that matters is data (aka information). Everything programs are supposed to do is store, manipulate and present data. Do not overcomplicate, just focus on data processing. That’s what views in MVCs try to achieve: After doing some very complex stuff on the data, pack it up in a simpler structure for future processing or presentation.

Leave a Reply

%d bloggers like this: