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!

Keep It Simple, Stupid!

One of the more memorable things I learnt while at school was the number one rule of design: Keep It Simple Stupid!

It's another way of saying that complexity is inherently dangerous, and should therefore be avoided. But the key realisation that I want to draw out in this blog post is just how widely this edict should be applied.

ALL code is evil. Every time you serialise a thought into language, you are encoding it. Thus you create complexity. And the danger? You may be misunderstood. You may mislead. You may even offend. Hence the need to practice simplicity in the design of your sentences. Keep it simple.

One of the nicer features of Microsoft Word was when the style checker prompted you to use shorter sentences. Occasionally it was wrong, and the idea was best expressed at length. (And it was often wrong about the grammar.) But almost always the sentence in question could be simplified, shortened or just broken into two discrete sentences. One for each idea.

A recent cartoon from the most excellent XKCD series is an exercise in simplicity. By limiting oneself to simple language it is easy to be understood. It may sound a little like you are talking to children but if your intention is to convey meaning then simplicity is the best way to achieve it.

If conversely your desire to appear erudite and confound your audience, while obfuscating the content of your communication, exceeds your desire to enlighten then perhaps long sentences and an archaic multitude of polysyllabic words are preferable.

Compare and contrast...

So I finally finished my Enigma machine!

There turned out to be a bug in my understanding of the requirements, which took a little fixing. Luckily Mike Koss (whose instructions I was following, having been introduced to them at SC2012) also provides a Javascript implementation against which to test my efforts. A bit of debugging later and I now have two working implementations; one in Clojure and one in Java.

The Java implementation was an order of magnitude quicker to write, entirely due to my greater experience with Java. And while I undoubtedly learnt more writing the Clojure machine, I made an unexpected discovery about the Java language. Its nice to know that even when you feel like you have a good grasp of a language, there is always more to learn. So what did I discover? You can't just use short-circuit boolean operators for conditional evaluation - you have to do something with the return value. For example, the following will not compile as a complete statement:

 obj1.action() && obj2.conditionalAction();

Whereas these all compile fine:

 obj1.action();

 obj2.conditionalAction();

 if (obj1.action() && obj2.conditionalAction()) { /* no-op */ }

 boolean unused = obj1.action() && obj2.conditionalAction();

 if (obj1.action) {
  obj2.conditionalAction();
 }

The last three of those give the required behaviour. Of those, the third and final excerpt is my preferred in terms of clarity of intent. However, as I was planning to use this pattern for rotor rotation in my three rotor Enigma machine, it would need to be extended to a third method call with an additional level of indentation. It seems a shame that my original idea does not compile. It also seems faintly perverse that it was not the functional language that prevented me from easily evaluating an expression for its side effects!

In fact it was academic, as my final understanding of the Enigma machine did not require this logic.

The code is on Git Hub and some statistics are below. While the bracket count is higher for the Clojure implementation (a common complaint leveled at lisp-like languages), it does however surpass the Java version in other measures. (Remember, All Code Is Evil, so less is more!)

Statistics	Clojure	Java
Characters	1914	2959
Lines	40	107
Functions/Methods	11	12
Parentheses "(" & ")"	77	51
Square Brackets "[" & "]"	21	4
Moustaches "{" & "}"	4	18
Total Brackets	102	73

Still slowly learning Dvorak

I've been learning Dvorak very slowly over the course of this blog.

One often repeated idea about Dvorak (or any key layout) is that you can't learn it half-heartedly. For me this simply isn't true. For this is exactly what I've done. I've been writing all my blog posts in it, and doing occasional other tasks as well. I'm still faster in qwerty, but at times I'm sure I'm improving. They say (citation needed) that its confusing to switch between layouts, but again this is not what I have found. I can still type just as fast in qwerty and my brain doesn't struggle with the context switching at all. Just as polyglots rarely speak in the wrong language by mistake, so to do I rarely suffer mental interference between my typing knowledge.

On the downside, I have semi-conceded defeat. As a programmer I spend most of my keystrokes writing code. And unfortunately the world of code expects qwerty. Numerous keyboard shortcuts only make sense when the keys are physically where the UX designer thinks that they are. Try using 'Ctrl'+'X', 'C' or 'V' in Dvorak and you quickly realise that the letters aren't even near the left-hand 'Ctrl' key, let alone next to each other. Bearing in mind the number of shortcuts available in the average editor this is a big hurdle.

For typing, Dvorak seems from experience to be better by a clear mile. For shortcuts, not so much. I will carry on down this path. As I haven't suffered any great cognitive dissonance from learning both I will use Dvorak for English and qwerty for coding.

Learning Clojure: Part 12

Two weeks ago today my wonderful wife gave birth to a lovely boy called George.

I couldn't be more proud if I tried.

While this has given me a great excuse to take some time off work, and get back into 'Programming Clojure', it has also used up a great deal of time. And energy. And sleep.

I have managed to read the section on concurrency, and I am looking eagerly ahead to learning about macros. However, I'm going to force myself back to the REPL to play with the example from the chapter before ploughing on with the book. It ought to be fun as its a snake game.

Aside: I've always thought it a little funny that having started programming aged 10 in order to write games, I've ended up preferring the programming to the games themselves.

While the chapter on concurrency was good (I particularly liked the way the information was presented), I was slightly taken aback to discover the power of 'def' and 'defn'. That these are in fact a part of a system for thread-local dynamic re-binding is interesting. Five years ago I would have thought it cool. Now I mostly think its scary. At least this way its a core part of the language and the bindings will be in the source code, rather than being woven in by AOP. Disclosure: I have come to dislike AOP.