Agile Development - Whats' in a language?

Since my last entry things for me have changed. In my current contract I am performing the role of "Agile Coach". Interesting in itself (I take my hat off to people like Racheal Davies, coaching is not easy), I won't be blogging about it today. No what I want to blog about is programming languages, and languages that support agile development.

For a while I have been hearing people in the Agile camp say things like: "dynamic languages are the way to go". Untyped (risky) and Interpreted (slow) both bad things right? Well in my coaching role I've been taking a closer look at test driven development - and of course having to practice what I preach, I have been doing a fair amount of TDD recently. For TDD there are two things you definately need - a good test framework (JUnit) and a good refactoring IDE (Eclipse).

The more refactoring I have been doing, the more I have taken the refactorings available in Eclipse for granted and the more refactoring facilities I want. Surely there should be a button to do this or that refactor, and if not why?

Both of the tools I rely on for TDD have a common heritage: JUnit descends from sUnit, Eclipse refactorying is inspired by The Smalltalk Refactoring Browser. In search of a better environment to support TDD I dug up my old copy of the purple book and went on a quest on the internet to find The Smaltalk Refactoring Browser.

The first thing I noticed was that the Smalltalk community is still alive allthough a bit muted. The impact of Java has definately taken its' toll though. A quick search on jobserve for Smalltalk vacancies identified only 10 or so and they appeared to be for maintance work. It looks like the remaining Smalltalkers are using Smalltalk just out of interest or just for fun in their spare time. With the exception of one or two German Consultancies, most of the Smalltalk related websites were either academic, or open source related - very few businesses.

The second thing I noticed is that you can get commercial quality smalltalk for free. I remember the days when a VW Smalltalk license ran well over a thousand pounds. Finally I found Squeak. A free implementation of Smalltalk by the founder Alan Kay.

The first thing that happend when I started using Smalltalk again was that I immediately fell back in love with the syntax. I first taught my self Smalltalk back in the early nineties as a way of learning OO programming. Learning OO and learning C++ at the same time was proving too difficult, so I decided to learn OO without C++. It worked a treat. OO expressions are built on sending messages to objects. The Smalltalk syntax mimicks natural language: An object is a "subject" and a message is a "verb", parameters are "complements" and expressions end in a full stop.
For example:

bunny moveForward: 5.

Tells the bunny object to move forward 5 pixels.

The reflectiveness of Smalltalk and the focus on late binding opens up tremendous possibilities for tooling. Where Eclipse struggles to make Java self aware, Smalltalk positively encourages tools to inspect this, or discover that or refactor this or rewrite whatever...

So where are the Smalltalk tools? Well the old Smalltalk favorites are still there - Browser, Inspector etc. Interestingly these 30 year old tools compete pretty well with their modern counterparts like Eclipse. Eclipse is ahead in some areas (e.g code completion) , but the Smalltalk tools are just so much more accesible and easy to use. I also found some newer tools, for example GLORP is a Object Relational Mapping framework for Smalltalk. If you are familiar with Hibernate you should take a look at GLORP, OR mapping without xdoclet, XML or bite code manipulation. The power of making everytning an object (including classes) is that adding new object types and extending behavour is easy. For example GLORP has a class for a TableMapping, a OneToManyMapping etc and ofcourse overloading 'new' and extending its behavour is a synch. Object queries using GLORP look remarkably like SQL, yet they are standard Smalltalk expressions. No need for a special query language like HQL.

By this stage I was pretty smitten with Smalltalk. For Agile development this has got to be the way to go. The slogan of XP is "Embrace Change". Thinking about the recent changes to Java: dynamic proxies, annotations, generics etc all of these have required changes to the core language (JVM and compiler). All these features either allready existed in the orginal Smalltalk-80 or have been added without the need to change the language at all. Thinking about changes (refactorings) to exisiting apps, Smalltalk tools like the Refactoring Browser and the code rewriter have yet to be surpassed in the Java world (and probably will never be surpassed without further fundamental changes to the Java language).

But Smalltalk is untyped? With test driven development who cares? A compiler can only ensure the type assertions made by the programmer. What does that mean? Well it could mean that your program is self-consistently wrong. Besides you have to type in all that type info so that your compiler can do the checks (what a chore). With TDD you make assertions about the correctness of your code with respect to its' use. These tests are enforced each time you build. So if you've got unit tests who needs type safety?

Alan Kay, the inventor of Smalltalk allways envisioned that computers would become easier to program. So easy in fact children could do it. In this view of the world, the interface to a computer is its' programming language. So a graphical user interface becomes a programming language for end users.

I got to put this idea to the test the other day. Whilst playing with Squeak, my girlfriend decided to pop herself on my knee and took a look at what I was doing. I was playing with the Alice framework port (Alice.org). Alice is a3D graphical framework which allows you to create a 3D world populated by Actors. On the screen was a pink bunny rabbit wearing dark glasses and carrying a drum and a mallet. I entered a few Smalltalk expressions asking the system to 'do-it' each time, and watched my girlfriends expression as the bunny respond to my every command. She soon caught on, and started entering commands of her own: "bunny head turn." Getting bored I was about to issue "bunny destroy" when she stopped me. "No you can't do that to such a cute bunny, make it beat the drum instead". At this point she grabbed the keyboard an typed "bunny beatDrum", but the system responed with: " bunny didNotUnderStand".

Within 5 minutes with no instruction from myself, my girl friend was coding in Smalltalk. Maybe Alan Kay was right! The didNotUnderstand message was a bit of a bummer though. What would she need to do to make the rabbit beat the drum? Well the following expression may work: "bunny mallet beat" or there could be another sequences of messages that would work. If not she would have to define and implement a message her self. This is were things would become difficult. How do you make a bit mapped representation of a mallet move in 3D on a 2D surface? You would have to calculate the position and colour of a lot of bits. This would require a lot of maths. Perhaps there is an intermediate abstraction that could help, like the Morphic framework. Even so you would still need to know a lot to use it effectively. So much for simplicity and end user programming.

I've recently read an interview on the web by Alan Kay, where he was somewhat despondent on the direction computer languages have taken over the last couple of decades. His feeling is that good enough short termism has allways won out over good sound engineering principles. He is right, but I do think he missed something. Computers do very simple things very quicky. To do something meaningful (like beat a drum) the computer needs to perform a very large number of very simple operations in a pre-determined sequence. Here in lies the complexity. Abstracting can hide the complexity some what. For example, the bunny responds to a small number of simple messages, pretty simple, but when the appropriate abstraction does not exist, complexity raises its' head once more.

Because of this complexity the world cares very little for programming. Its' too hard and requires far too much skill. Instead people hire other people to do their programming for them. All they care about is whether the solution is performant, functional and affordable. It is the programmers problem to "talk" to the computer. For the programmer his main concern is that he can get work (using a language that he knows and is popular) and that the solution is "good enough". Untill users are aware of the long term costs of "good enough" solutions nothing will change. So there we have it. Looks like I'll be using Java for some time to come then (Is there anyone out there with a lot of money who fancies marketing Smalltalk? No? I didn't think so).