SmallTalk @ FP

I’ve just had a group introduction to Smalltalk. Piers was visiting Brighton and decided to teach us all about the roots of OO programming. In lieu of the usual 5-minute-on-keyboard sessions, Piers gave us a walk through of developing kata 4 in smalltalk.

This was a superb way to learn the language. There was more heckling than usual, but that was an important and necessary part of the process in this case. Watching smalltalk in action is absolutely necessary—it’s just such a visual experience (compared to regular programming languages, anyway). I now completely understand the smalltalk credo I’d read about: just type in what you want to happen, hit “run test” and when it breaks, write the code in the debugger window that pops up.

Just before half time, Piers started pairing properly. That was when the language differences really started to hit home. Smalltalk is so not an algol-influenced language. In particular, I adore the cascade:

  fromRow: aString
    ^ self basicNew;
      setRow: aString;

That semicolon is calling methods (sorry, passing messages) to the same object after each semicolon. The statement is only terminated with a period. Conceptually, it feels similar to Perl’s $_ (or “it”).

As usual, we didn’t get particularly far in the task, but we did learn a huge amount. A big thanks to Piers for visiting us and also to Devi for cat-herding in Joh’s absence (and doing an excellent job of keeping us on-topic).

Now, I’m off to download Squeak


Coding Dojo Tonight

Tonight was the latest Coding Dojo. We were picking up the mantle from the previous time. This evening was peculiarly intense, thanks to Piers dropping in.

Despite not completing the task (as per usual!), I learned an enourmous amount from the interaction this evening. It felt really humbling to be amongst people who knew so clearly what they were trying to achieve. Chatting to Piers afterwards made me realise how I tend to be very focussed on solving the problem at hand rather than stepping back and trying to create something beautiful. I need to go back and read TDD and Refactoring

On another note, I’m really looking forward to the festival dojo. It’s the 10th of May. Come and join us.


Coding Dojo 9

I’m just back from Dojo#9. We attempted Kata 4 again, but in Ruby this time. Even though I was the only one with much Ruby experience behind me, it still wasn’t much of a problem in practise. I did some cheat sheets, but they didn’t seem to be used much.

Exactly the same as the last time, we only completed the first part of the kata. I started the session by writing a small amount of code. In a very non-object oriented fashion. However, I honestly believe that for this problem an OO solution was utter overkill. The testing was probably useful, but to be quite frank a program this short can be visually inspected so easily, I hardly feel it’s worth it. Heresy, I know.

This is what I was aiming towards.

  day = nil
  min_spread = nil
  File.foreach(ARGV[0]) do |line|
    if line =~ /^s*(d+)s+(d+)s+(d+)/
      spread = $2.to_i - $3.to_i
      if !min_spread || spread < min_spread
        min_spread = spread
        day = $1
  puts day

I’m pleased about using regexes though. They make the problem simpler (and more robust) than the previous Java solution using substring().

Now, when it came to refactoring the program to get to the third part of the kata, an OO solution would have been more appropriate. Because you need to carry some state around, and you can obviously use inheritance to model the differences. And by that point, you’ve got two working programs you can extract a sensible design from.

Ah well. An entertaining evening. Big thanks to Joh for organising and FP for hosting. Sorry for disturbing the late workers…


Dojo IX

Last night was the latest Coding Dojo. It was an astonishing success. Not only did we all manage to enjoy ourselves, we actually produced some working code! We were attempting Kata Four (data munging), which is split into three parts. Admittedly, we only finished the first part, but it still felt like a real achievement.

The task itself was interesting. It’s the kind of task that you’d whip up in a few lines of Perl or Ruby in a few minutes. Yet with Java, it all gets much more complicated. For starters, you get exposed to the morass of Java I/O classes, which confound and bemuse me every single time.

Then there’s the text processing aspect. This actually turned out to be easier in Java, because we were dealing with a fixed width format and the natural instinct is to reach for substring().

What was nice was that with half an hour to go, we decided that we wouldn’t try to start the second part of the Kata. Instead, we focussed on cleaning up the code we had written—a pleqsant experience.

I hope we pick this one up next time. It’ll be interesting to carry on with the rest of the task.



Last night was the 8th Coding Dojo. Joh kindly allowed myself and Jay to try out one based on Ruby instead of the usual Java. Sadly, Jay was ill and couldn’t make it. Get well soon, Jay.

We started late because I was installing all the necessary bits (ruby + eclipse) on Joh’s laptop…

Having done that, I gave a quick presentation comparing Ruby to Java. I had been under the impression that most people there would be familiar with Java (based on previous experiences). Unfortunately, because it was Ruby it attracted a very different crowd. Thankfully, nobody seemed to mind too much.

After that, we started on the task: write a Sudoku solver. This was the point where I realised that whilst I’d brought along code for a board, I hadn’t actually brought a puzzle to solve. Ooops. So we hopped over to Wikipedia to grab a sample puzzle. And we then realized I needed an importer… So we knocked one up fairly quickly. Whilst I did feel quite embarrassed about lacking such a crucial part of the problem (bad prep! no cookie!), it turned out to be an interesting example of coding something simple. The fact that I was with Andy, who I know well helped a lot.

Unfortunately, as the evening progressed, it became rapidly clear that none of us had much clue about how to solve a Sudoku puzzle algorithmically. So most of the time ended up being spent discussing the problem as opposed to coding. Afterwards, it was suggested that a “time out” be taken so we could discuss the strategy as a group—that might have helped quite a bit.

Finally, the last pair on the keyboard started making real headway. Andy and James came up with an algorithm for listing the “opportunities” for a given cell and were in the middle of implementing it when the final whistle blew.

So we didn’t get very far at all towards a solver. But as usual the journey was interesting and entertaining.