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.

Clojure: Accessible Code

While writing up my Clojure Enigma machine I was struck by a habitual fear. A fear honed by experience. The fear that my code was too exposed.

Years of Java development have taught me that encapsulation is important. Yet I was just casually throwing functions into my namespace for all the world to use. I was troubled. Especially since one of my key early learnings in Javascript had been about how to use closures to create modules that limit scope.

I had a think. I talked to some other Clojurians. I decided that maybe I was worrying without cause. Access levels are useful in Java, but I often feel like I'm trying to protect my classes' state, but I want to re-use other classes' functionality. But this conflict simply didn't exist in my Clojure program. It was functional! It had no state!

Learning Clojure: Part 11

Having Fun

I just wanted to make a quick post to say that I'm having fun writing in Clojure. Here's another rendering:

I've also just finished coding the Enigma Machine, as per the session at Bletchley Park (See part 9 of this series). It's up on Git Hub at https://github.com/peterwestmacott. I was quite pleased to write it in only 50 lines of code, but more on that another time. ;-)

Learning Clojure: Part 10

Just generated this:

Source available on GitHub
Now settling down to watch a great video by Rich Hickey, creator of Clojure.

Learning Clojure: Part 9

This week I attended Software Craftsmanship 2012 at Bletchley Park.

I had a fantastic time! Its a completely hands on event and I spent both the morning and afternoon sessions pairing in Clojure.

There was a pathfinding algorithm contest in which we picked up most of our points by not making illegal moves, and I'm sure I learnt more about Clojure than I did about pathfinding. The session was built on Matt Wynne's Robot Tournament from Software Craftsmanship 2010. Although the upload mechanism limited the robots to no more than about a megabyte (less than the size of the Clojure jar needed by our robot), my pairing partner managed to persuade the organisers to add the jar to their server.

In the afternoon I attended a session on the Enigma Machine. It is an interesting machine to model and seems to lend itself well to Clojure. Although the end of the session arrived while our machine had but a single rotor, I intend(!) to finish off the solution.

Overall the day was brilliant. Plenty of diverse people (including a good number of Clojurians), fun sessions with lots to sink one's metaphorical teeth into, a tasty hog roast and an auction to round off the day. Thanks to Jason Gorman and all the people at Bletchley Park!

Learning Clojure: Part 8

Its been a while, but I've found time to go back to Clojure.

Where was I? Oh, yes! I plotted a rather low res. fractal. Now to spice it up a little... First we need some COLOUR!

To do this I've changed the output from characters (so last millenium!) to a fancy 'png' file using Java interop. Calling Java from Clojure turns out to be as easy as promised in 'Programming Clojure'. Indeed, easier than calling it from Java. The new output allows for much higher resolution fractals, and of course the highly addictive element of colour:

All in all a much better fractal I think you'll agree. Even the code looks better. I've even pushed the code to Git Hub.

The Dvorak has alas deteriorated through neglect, although moments of fluidity occur, often associated with a sense of the keys being in a sensible place. I will either have to blog more frequently, or take to performing more tasks in Dvorak.

Agile Bakery

I made a cake! A Victoria Sponge no less:

• 2x Butter
• 2x Sugar
• 3x Eggs
• 2x Flour

Where the numbers represent an arbitrary but consistent measure of weight and the procedure is as follows:

1. While there are more ingredients: add the next ingredient and beat until smooth.
2. Cook until cooked.

The key is to properly integrate each ingredient before adding the next. Thus you avoid accumulating the Technical Debt of Lumps.

Making the mixture for the first layer, I added all the eggs at once and then beat it for a long time to make it smooth.

Making the mixture for the second layer, I iterated towards an eggier mixture one egg at a time. This significantly reduced the integration effort required, and resulted in a smoother mixture.

Now learning Javascript...

I've been rather busy of late. My month off from work ended and I started a new job. It's much better than the old job. We have a bar football table and everything.

So I picked up one of many copies of "Javascript; the good parts" that were lying around the office and started reading. While the author's style is appealing in its absolutism, he does move quickly. More worrying than his self-belief though is his determination to enforce encapsulation of code through various means, including the use of closures. (I can still type 'closure' with an 's', even in Dvorak.)

Now isn't that great - I hear you thinking - he's using closures to limit the scope of the code, and we all know how Evil code is, so limiting it's ability to confuse and be-muddle us must be a good thing, right? Well only up to a point. The amount of code required, and its complexity, left me unsure about the value of such techniques. ALL code is Evil. Even the fancy code you just wrote that makes everything wonderful and bakes you scones at tea time. Especially the fancy code. The more you like it, the less objective you will be when the time comes to re-factor it.

I haven't even nearly finished the book yet. But the two differing opinions I have are both strong. I am starting to see why.