Problems with languages

22nd April, 2011

Over the years, I've had many conversations about programming languages. Looking back on them now, they were mostly pointless. However, I think there are a few areas ripe for improvement.


To date, compilers, editors and code management have all been seen as separate. This places bounds on improvements because parts taken and improved in isolation either aren't effective or have a detrimental effect on the system as a whole.


Almost all programming languages and editors read and write plain text files. This means that what the engineer edits, what the compiler sees and what is stored on disk are forced to be the same at all times. This has the following effects:

  1. it prohibits real out of band information, eg comments and inline documentation.
  2. storage can't be optimised for anything other than editing, eg use of a tree structure to aid language agnostic comparison tools.
  3. style can't be separated from content - where do you like to put your curly brackets? The compiler doesn't care so it should be an editor thing.

Code blocks

Code blocks are currently special in popular languages. This can be evidenced by trying to replicate if within the language using code blocks. For example, in Java, one would have to use multiple classes adhering to an interface or reflection to get the same thing. This is a problem when you're passing code blocks to other parts of the system to be run.

Chopping it all up

The code you write is rarely an island. Your product is not your code; your product is the sum of your code and many other components you didn't write. The management of your code within the context of the multitude of components making up your product is critical. This includes taking account of dependancies across versions and multiple versions of the same component within a system.

Forced optmisation

Here are two examples of creating a mutable hash table:

Functionally, they're are almost identical. However they are slightly different in that in the the Java example the engineer chooses the performance, and in the Cocoa example, the engineer leaves that up to the underlying API.

Neither is strictly wrong, but neither is quite right either. Java should not force the engineer into premature optimisation, but it's difficult to see how Cocoa can always get it right at run time. There are many examples of this kind of thing in most major languages, especially in the type system.


I suspect that a full versioned bundle that exists both on disk and within the version control system as an atomic object would be a good start. This would contain both source code and compiler output, along with dependancies and version preferences.

As for what the language itself would be like, I think it should at least:

  1. natively support multi-threading and the throwing around of code blocks.
  2. not contain anything the compiler can work out for itself. Anything not critical to program flow should be in a side channel.
  3. not present false dilemmas with regards to optimisation. This could be by allowing the engineer to state a preference in a side channel, or performance metrics from test systems to update the preference for specific platforms.
  4. put anything the compiler doesn't need but the engineer would like in a side channel (eg comments) or in editor preferences (eg style information).

On the UI of links

19th February, 2011

Here are three sentences - identical text, but with different linking styles:

All quite different. The final line shows the current Wikipedia style: a compromise between the extremes of the first two. It's pretty much the same for every other web page out there: a compromise between readability of the textual content verses the findability of the hyperlinks.

I propose that this is a false dilemma; possibly coming from an implicit belief that the page is static when viewing lots of text.

I think there are three states a user (and thus the page) should be in:

  1. Reading content, not interested in links at all.
  2. Looking for links.
  3. Checking the link is the right one.

Each transition between the user's state should be accompanied by a change in visuals. For example, the text below decorates links with underlines when the mouse hovers over the link (states 2 ↔ 3).

In addition, all the other links on this website should also change visuals between states 1 ↔ 2. If the user moves, the links appear. If the user stays still for three seconds, the links fade away. Interestingly, even though the fade is fast, the visuals just look wrong if it's not there.

For reference, I've implemented the 1 ↔ 2 state change as a small javascipt files called links.js.

2010 Calendar

15th December, 2009

I created my first calendar for 2008, a better one for 2009 and once again it's that time of year.

However, I'm still not quite content with the results of the 2009 calendar. Specifically, I don't like the month names down the left side as one has to constantly reference the left side of the page even when looking at a date on the right. This is even worse than the similar problem of week day names as the calendar is wider than it is tall meaning the text is even farther from where it is needed.

After many iterations and suggestions from friends I've come up with what I think is a reasonable solution. Each Monday box has an additional value - a three letter month value:

Monday labels

This solution means that month names are never more than three squares away but do not interrupt the user too much by being on every square.

So, here's the first version of the 2010 calendar.

2009 Calendar

15th January, 2009

In the dying months of 2008 I wrote of my efforts to design a better calendar.

I'm grateful to all the comments I've received. In response, I've made a few improvements:

Without further ado, here's the first version of the 2009 calendar.

Oatmeal and Raisin Cookies

7th December, 2008

Here's a recipe for making oatmeal and raisin cookies. The ingredients are the same as I was given but the method has been simplified somewhat.


175g butter
1/4 tsp salt (if butter unsalted)
160g light brown sugar
130g caster sugar
1 large egg
1 tsp vanilla extract
3/4 tsp baking soda (known to work without)
3/4 tsp baking powder
160g plain flour

170g rolled oats
200g raisins


  1. Using one bowl, add everything up to and including the plain flour.
  2. Mix the contents together.
  3. Add the oats and the raisins
  4. Mix the contents together.
  5. Drop dough on to an ungreased baking sheet with a 5cm gap between blobs.
  6. Bake at 190°C for 10 minutes (in a fan assisted oven)
  7. Leave to cool