01
Aug 10

Why I stand before you


As some of you already know by now, I have nominated myself for the 2010 Australian Federal Election as a candidate for the Commonwealth Electoral Division of Sydney, endorsed by the Secular Party of Australia. It is both an honour and a privilege simply to be able to stand for such office. It is truly a remarkable thing to participate in a society that conducts its affairs in this manner.

Continue reading →


11
Jan 10

The Happy Toggler

I’ve been writing a lot of UI code lately, and one of the bread-and-butter operations in UI code is toggling boolean state, usually in response to a button press. Now, what does toggling code look like?

Say I have an object that likes to transition solely between happy states every time a certain event occurs. Here’s how I might handle it:

 theObject.happy = !theObject.happy;

There. Simple huh? Something you probably learn how to do in an introductory programming course. It might be surprising to you, but someone asked a question on how to do this on Stack Overflow. The other alternative provided in the answer is the somewhat more cerebral:

theObject.happy ^= true;

Thanks Spock. Of course if your language doesn’t have an assigning XOR operator this option is ruled out. If you value clarity of code, or you simply don’t want less brainy maintainers pestering you about what your code is doing, you rule this option out as well.

So I’ve been writing a lot of code recently of the first form, and it’s been making me sad. There’s a strong feeling of non object oriented-ness about it. I mean, to toggle the state of an object I have to:

  1. ask it what its current state is;
  2. flip that state locally;
  3. and then tell the object to take on this new state.

Bleh! Why the hell should I care what state it currently is in? I just want to toggle it! Shouldn’t I just be able to ask the object to toggle it’s own state; perhaps of even multiple properties in a batch sequence?

Naturally, nobody wants to write a toggling method for every writable boolean property of their objects. So either there needs to be automatic support in the platform or some ability to provide a general toggling abstraction.

One such example of a crude toggling abstraction would be a Ruby module defined like the following.

module Toggler
 
  class ToggleHelper
 
    def initialize(target)
      @target = target
    end
 
    def method_missing(sym)
      @target.toggle(sym)
    end
 
    def toggle; end
 
  end
 
  def toggle(*sym)
    return ToggleHelper.new(self) if sym.empty?
 
    sym.each { |s| self.send("#{s}=", !self.send(s)) }
  end
 
end

Such a module could be mixed-in at the appropriate levels of an inheritance hierarchy, or maybe even at the root level if you’re game.

With the mix-in mixed-in, toggling code would be more concise and less repetitious:

the_object.toggle.happy
the_object.toggle(:happy)
the_object.toggle(:wanted, :happy, :virtuous)

Doesn’t a declarative syntax such as this feel much more happy?


15
Oct 09

Stories what I wrote when I was ten

I present to you a youthful and somewhat insensitive re-telling of a classic fairy tale.

Please note—The following story is not meant to imply that the residents of Chernobyl were:

  • tax evaders; or
  • incompetent home builders; or
  • mean spirited; or
  • comparable to swine; or
  • given to formulaic naming of their children.

Any resemblance to any person, living or dead, is purely (and tragically) coincidental.

The Three Little Taxpayers

by C. D. Owen. (Age 10)

Once upon a time, there were three little taxpayers and they lived in a Russian town called Chernobyl. Two lived in the outskirts of the town and they had made their homes of poor building material. One whose name was Yuri had made his house of straw. The other, whose name was Yori, had made his house of sticks and branches. Everyone in the town made fun of the them. The other taxpayer lived in the upper-crust of the city and he was very well-off. His name was Yari and he lived in a magnificent sky-scraper and he made fun of Yuri and Yari as well.

One day, the big bad tax-collector came along and his name was Yiri. He came to Yuri’s house and knocked on the woven door.

“Little tax-payer, little tax-payer, let me in!”
“Not by the vinyl of my skinny wallet!”
“Then I’ll have to demolish your house!”

So the big bad tax-collector went away and then came back with a bull-dozer. He then knocked over Yuri’s residence. He then went and on and came to Yori’s house of sticks.

“Little money bag, little money bag, let me in!”
“Not by the leatherette of my medium filled wallet!” came the reply.
“Then I’ll have to demolish your house!”

And again he went away and this time brought back a demolishing ball. He then knocked down Yori’s house. Then he continued along collecting debts. He then came to the sky-scraper belonging to Yari.

“Little dollar-sign, little dollar-sign, let me in!”
And Yari replied, “Not by the one hundred percent leather of my fat wallet!”

And so away went the big, bad tax-collector yet another time. He then came back with a demolishing squad but they couldn’t destroy the sky-scraper because they didn’t have a permit to destroy large buildings.

As you have probably known, the big bad tax-collector was very greedy and he just had to have Yari’s wallet. So the big bad tax collector went to the Chernobyl nuclear power plant and he shut off the reactor’s cooling systems and then the power plant blew up causing Yari’s building to glow and melt.

The next day the big bad tax-collector came back in his protective clothing and he searched the rubble for Yari’s wallet, which he never found but he was glad he gained his revenge.

The moral to this story is: pay your debts or you’ll be sorry!


26
Aug 09

Java developers have 99 problems…

… but this ain’t one.

Today Yahuda Katz posted his 10 favourite things about the ruby language. His list certainly reflects most of the things I find very appealing about the language. The sixth item highlights Ruby’s excellent support for blocks and lambdas and an argument is mounted that when performing file operations in languages without them, programmers are forced to use an inline “ensure” block every in the same lexical scope that they originally opened the file in, to ensure that the resource is closed. As is often the case the comparison is made to Java, but as any seasoned Java developer will tell you (and this point has probably be made many, many times) it just isn’t true. Java supports a safer and comparable idiom via the anonymous inner class.

The example given is a very succinct Ruby method to print out the lines of a text file. Ruby’s File.open ensures the file is properly closed after the block has completed, normally or otherwise:

def run(input)
  File.open(input, "r") do |f|
    f.each_line {|line| puts line }
  end
end

The Java version listed does the same but, predictably, is far more verbose and laborious:

static void run(String in) 
throws FileNotFoundException {
  File input = new File(in);
  String line; Scanner reader = null;
  try {
    reader = new Scanner(input);
    while(reader.hasNextLine()) {
      System.out.println(reader.nextLine());
    }
  } finally { reader.close(); }
}

However no Java developer that values their sanity is ever going to sprinkle this pattern through their code base any time they want to use a File and ensure that it is closed properly. Here’s what they are going to use instead:

public interface Processor<T> {
  void process(T target);
}
import java.io.*;
import java.util.Scanner;
 
public class FileSlurper {
 
  public static void slurp(String fileName, Processor<Scanner> processor) 
    throws FileNotFoundException {
 
    File input = new File(fileName);
    Scanner reader = null;
    try {
      reader = new Scanner(input);
      processor.process(reader);
    }
    finally {
      reader.close();
    }
  }
 
}

Once that infrastructure is in place, the Java implementation of the example becomes:

FileSlurper.slurp(input, new Processor<Scanner>() {
  public void process(Scanner reader) {
    while(reader.hasNextLine())
      System.out.println(reader.nextLine());
  }
});

No one can argue that this is as pretty or convenient as the Ruby version, but it does ensure that file opening and closing is handled correctly without any effort from the client code. The code in the anonymous inner class can even access variables in the current lexical context, as with the Ruby block, with the caveat that they must be declared final (not quite a lexical closure!). This pattern, in conjunction with the Processor interface may be used any time there is a need for similar resource acquisition and clean–up procedures, as might be the case for locks or database connections.

Lambdas and blocks are very useful constructs, and the anonymous inner class can act as an acceptable, if far from ideal, analogue. What an anonymous inner class can’t do is act as a co–routine; this is a truly powerful feature of Ruby’s blocks and associated method invocation features that Java can’t directly compete with.

One thing’s for certain: the Ruby community won’t win over Java developers by giving examples of deficiencies where none exist.


23
Aug 09

Insoporia

And the sleep won’t come,
the time ticks a pattern in my head,
a memory of you enters and fades,
a lost time, more potent than the time I’m losing now.

If I could choose, if I truly had free will,
I’d run, I’d break out, I’d be unbonded, free.
but while I’m here in this state, a listless nowhere,
I can’t, I won’t, I’ll never be.

and even now, when I feel almost alive, I’ll falter
search for words that won’t come, that will never say what I want to say
I’ll think that at the very least, I’ve created something
but for what purpose? In the end, I’ll hate them, hate it, loathe it all the same.

And the sleep still won’t come, but maybe I always am.