On Identity

There's lots of examples...

There's lots of examples in everyday speech of people breaking the rules of English grammar. For example the subject of a sentence should agree with the verb in terms of number. If the subject is "she" the verb could be "is" but could not be "are". And in the sentence above starting "There's lots of examples...", "There's" is a contraction of "There is", using the third-person singular form of the verb "to be". Which is incorrect, because the "examples" are plural. It is however a linguistic convenience (with fewer syllables) to say "There's" rather than "There are".

But does it sound incorrect? It is easy to accept as normal things that other people say. Especially if they say them a lot. Indeed, if they say them a lot then they become normal - not by changing themselves, but by redefining what normal is.

We are arbiters

I hate the word 'consumer'. Its a normal, everyday word, but I don't think it should be.

When I walk into a shop and buy a sandwich, two thing happen. Firstly, I acquire a sandwich, which I likely then consume. So far, so good. And the word 'consumer' is an accurate descriptor. But the second thing that happens is that the shop acquires my money, which they then spend on ingredients and staff to make more sandwiches. In other words, every pound spent in a shop goes towards keeping that shop in business. By buying a sandwich I vote with my money for which shop should survive in a free market.

I am not simply a consumer - I am an arbiter.

Towards a functional notion of identity

When we think of identity, we tend to think of what people are.

This notion of identity is exemplified in Shakespeare's 'Romeo & Juliet'. Two households define the dominant sense of identity throughout the play. Those who identify themselves as Montagues are in conflict with those who identify themselves as Capulets. One character however is as hard to pin down as his name might suggest. Though he fights with the Montagues, Mercutio renounces the play's system of identity as he dies; "A plague o' both your houses!". Mercutio seems to represent the impulsive, mercurial element in us that will not be tied to any particular identity.

Systems of identity can easily tie us down. They can act as codes that bind us to patterns of behaviour. While in most people's lives the body count from identity-based conflict is unlikely to be as high as in Romeo & Juliet, it can still be liberating to reconsider the words we use to describe ourselves. I am a 'programmer', or a 'coder' or an 'engineer'. But perhaps I am merely 'someone who sometimes writes code'. In another context I could be a farmer. Is the writing of code something that I am, or merely something that I do. It is a very simple linguistic convenience to use a noun ('coder') instead of a full phrase describing an action ('someone who codes'). But it is less constraining to consider identity in terms of things that one does, rather than things that one is.

Love, and do what thou wilt

Do you work in a company that has good process? Are there clear written procedures for every task? I used to work in such a company, and ironically it was quite liberating. It certainly makes it easier to tell someone else that they aren't doing their job properly. But it always struck me as odd to be working on Object Oriented code, but in a Procedural manner.

Objects (responsible objects in a well designed system) take responsibility for their own concerns. They encapsulate approaches to problems and do not entangle their collaborators in the complexities of their own workings. Yet they are happy to rely on others when a problem arises that is more properly the concern of another object. When exceptional circumstances arise they escalate the problem directly upwards with a transparent description of the problem.

I've also worked in a company without clear written procedures for every task. It is more Object Oriented. Developer responsibility is highly valued. But of course with Freedom, Responsibility is not just available, but necessary.

Naturally I prefer the latter. All Code is Evil. Not just that written in Processing or Haskell, not just that written in Company Procedures, but also those behaviours that we follow without thinking, the code of society. Societies have undoubtedly been codifying their own behaviour since before they began recording it. So ask yourself: "How do I approach a codebase that is several thousand years old?"

Any system of that age - and I mean the kind of age that changes things - must surely have accumulated a lot of cruft. Dead code that should have been removed from the repository long ago, but which (either through being complected with valuable ideas, or simply by misunderstanding or oversight) has remained in play. Code that was once valuable, but whose time has passed. Code that was always just a crazy experiment, but was never validated and somehow survived.

Any system of that age must also be successful. On these timescales only the fit survive. When things get difficult it is reassuring to have clear Procedures to turn to. Perhaps it is only in times of relative comfort and success that we can afford the luxury of individual freedom and responsibility. But a system that can survive through thick and thin must surely have something to offer. A core of good ideas. Some real functional value. Or else a historical accident would have wiped it out by now. Its very tempting when dealing with an old codebase to throw the baby out with the bathwater. To declare: "I can do better!" Tempting. But sometimes misguided.

One such gem, of which I was recently reminded was this saying by St. Augustine, a 5th century bishop: "Love, and do what thou wilt." Which is to say, as long as your intentions are correct, your exact course of action need not be prescribed. He seems to be advocating individual responsibility over blind obedience. A more Object Oriented approach over a Procedural one.

A Language for All Seasons

I've been slowly learning Clojure for a while now, so I decided to try it out on a real project.

A year or so ago I wrote a system to compile a static website. It's completely tailored to the website I use it for. Its a mix of XML, XSLT and Java. It seemed like a good candidate as it is a non-trivial use-case, but also because if it doesn't work I can fall back on the Java solution, and if it does I can write a nice 'compare and contrast' for my blog. ;-)

Early signs look good.

The declarative nature of Clojure, and the 'Code Is Data' approach of LISP, made the data part of the system trivial. Where once was XML, now all is Clojure. And its a surprisingly good fit. Its already less verbose than XML, and I've hardly polished it at all (I haven't written any macros yet).

In addition, by declaring the data directly with function calls, the transformation previously handled by XSLT is also trivial. Just change the function implementations and the output changes. Its a bit like XSLT (being a functional language), but the syntax is... ...well, it isn't XML. Which is nice.

And when I want to do fiddly little bits of file manipulation (copying resources around, for example) and plumb the whole thing together to turn input into output I can do everything I did in Java in Clojure.

But Clojure hasn't just turned out to be a better XML, XSLT and Java than XML, XSLT and Java respectively. I get the additional benefit of no impedence mismatch at the boundary between them. Is this bit of transformation appropriate for XSLT? Is it better suited to Java? Or should I restructure the data in XML? I still need to make decisions, but its so much easier to change my mind and move bits around, because the whole system is in one language.

I'm still a little way off finishing the job. But I will definitely see it through. If nothing else, I'm having too much fun!