Tuesday, 29 May 2007


These were taken in January, after we picked up the keys but before our stuff had been moved in. By now I figure that those of you who can make it here to see our new home have, so these photos are for the rest of you.

The building is a converted warehouse from the late 1890's. Until (I think) 1994 it was used as a warehouse. For most of that time as the headquarters, offices and printing rooms of the Sunday Times, Sydney's third Sunday paper. From the 1840's to the 1890's there were smaller buildings on the site, and before that, the area was market gardens.

The envelope of the building (the external brick walls) is original, and a lot of the original materials have been reused in the reconstruction. There's an old wooden pillar by the front door, for example, and some of the floor joists are original, though the floors themselves have been moved. Moving the floors has given us the 6m ceiling I've mentioned before, and the bedrooms have been tucked into a mezzanine that hangs over and opens out into the living area. The black rectangle in the photo is one of those openings.

They don't mention the joys of living in a converted 1890's warehouse in the trendy New York novels: our wall leaks. That's right: wall. Ahh, well. I call it character.

Monday, 28 May 2007

Embrace Your Inner Geek

Why bother reading long posts about esoteric language features that your language doesn't provide, or even if it does, it's not a good idea to use too often?

Two and a half reasons really.

Understanding your language is important. This is not magic we're doing here. It's engineering, one of the purest and most mathematically oriented branches of engineering you're likely to earn money engaged in. When it's magic you're not supposed to know what's going on, that's why it's magic. You are supposed to understand engineering though. Languages are the most complex pieces of computer software. You understand complex things by exploring the boundaries. What do they do well? Why don't some things work at all? How could they be better? All professional programmers should be able to name several critical failings of the language they are currently working in; if they don't hate it all together.

Related to that, when programming it's not enough to memorise the class and function names from the whopping great big framework of the week. You'll generally have inferred something about how the framework works underneath. You'll know that before calling function A, you had to instantiate class B first, unless you called function C first, because that happens to create a B for you. Blah. Languages are the same. Why does a variable declared inside a while loop disappear outside? This isn't voodoo. The goblins don't eat it. There's a reason. The language is implemented in a certain way by the compiler and runtime combination that causes these things to happen. You should understand that relationship. Every thing we write is built on some similar layer of abstraction. You need to understand (at least theoretically) how to implement the layer immediately beneath you or you'll end up wandering off into some abyss you didn't even know was there.

And finally, we're professionals, dammit. Where's the intellectual curiosity? Where's the 'Hey, that's cool. Now, how do I break it?' Or, 'I wonder what will happen if I do this...' Or, 'How does that work?' And most basically of all, 'Why?' Geeks are supposed to be into that sort of thing. We got beaten up in high school because we were enthusiastic about things it wasn't cool to be enthusiastic about. Now there's a lot of money to be had out of that enthusiasm. Let it out, embrace your inner geek. Enjoy this amazing, complex, unique, ever-changing world around us. Explore those things you've always felt a connection to. If you're in computing, there's a good chance that's something mathematical. Most things in computing are... For me it was languages. What's it for you?

Oh, and last week at the pub we had a big discussion about category theory, higher-order functions, contination passing web servers and finishing up with the difference between a program that generates a program and writing a custom compiler and interpreter. Geeky you may say. Well, today I noticed a colleague reading up on continuations on Wikipedia. That's what I'm talking about.

Sunday, 27 May 2007

The Sandman, Vol. 1: Preludes & Nocturnes

The Sandman, Vol. 1: Preludes & Nocturnes
Neil Gaiman

Is that how you credit authorship of comics? I don't quite know. There are artists involved, and I'll leave it at that for now. But yes, that means I'm reading comics now.

I've never been a comics reader. Sure I read some comics as a kid. Asterix and Obelix and Footrot Flats were both pretty important to me. I'm pretty sure I've read them all. I also read the occasional Tintin, and there was one dark single issue comic Where the Wind Blows that I discovered in high school that was pretty damn good. But I never read seriously the Marvel and DC comics involving Spiderman, Batman, etc, etc.

Sure I'd get hold of a comic here and there. But it would usually be issue 23 out of 148, then several months later I would read 92, then 5, then the grand finale. Overall, the story didn't make a whole lot of sense...

I have always been a big fantasy reader, and for the last five years of so I'd been hearing a lot about Neil Gaiman. Very popular, very well regarded. But when I looked into him I found he'd only written a couple of novels and a collection of short stories. Strange. It usually takes a long line of novels and an epic series or two to build this kind of cult following. Looking closer he was always credited as 'gaining his following through the cult 1990's comic series The Sandman.' Interesting...

After talking to friends, reading blogs and then reading Pynchon's Gravity's Rainbow, my interest in comics, especially the more modern darker ones was lifted. For example, I thought the V for Vendetta movie was pretty damn good, and apparently the comic was significantly better.

So, on finding Kings Comics on Pitt St, here in Sydney I decided to start with The Sandman. This is the first volume and so far I'm impressed enough to go back for the next. It's a dark, kind of gothic horror fantasy story. I can't review this as any sort of expert comic reader, but I enjoyed the stories and the artwork. Most importantly for me, the character of the Sandman was one that interested me. He is not clear cut. Not a hero, not a villain and not always someone you appear able to trust.

For me so far, comics are looking good. I want to read more Sandman, V for Vendetta, and as Damana also bought volume one of The League of Extraordinary Gentleman, I'll be checking that out as well. Any other recommendations?

Stupid Software Tricks

Or, My Computer Was Possessed!

Last night I was following some blogs, and I found a link to a kind of rubbish photo sharing site. I won't mention the name here, for reasons that shall become clear. It's been around for a few years and has gone through some major rounds of publicity and then failed. It's now into it's third beta in a row. In short, going nowhere real fast.

Anyway, I was curious about their site, so I went to read their news page. When I'm using a computer I tend to leave what I was last doing open on screen. On coming back I can then pick up where I left off. There's always a browser open, usually with four or five tabs I want to read.

I open the photo sharing news page in a tab and then wander off. Our apartment is a loft-style space in a converted 1890's warehouse. The entire apartment is basically open-plan with the upstairs bedrooms opening out near the six metre ceiling of the living room. My computer is in a study that opens into the living room, downstairs.

At 4am this morning the entire apartment was awakened by the these bizarre screams, crazy distortion and static. What the hell is going on? Is this something from the pub next door? Have our neighbours turned some movie on? Has one of our cats stood on the TV remote again?

I stuck my head out into the living room to try to work out where the noise was coming from. The weirdest thing was that I couldn't understand the noise. I could hear voices that seemed to speaking English, and I could pick out words, but I could not understand what was actually being said.

Coming downstairs to investigate closer, the noise was coming from my computer. And it really was strange screams, distortion and static. Being closer made it no better. I started closing tabs in Firefox, as that was all that was open. Eventually I closed the photo sharing news page and it shut up.

I've never seen anything like it. The news page had a bunch of embedded videos from all over the web, and it was like Firefox and Flash had buffered the videos, and then after several hours of boredom started to explore what interesting sounds could be made by sampling and looping the soundtracks.


And with apologies to Yasmin, who was visiting us this weekend and was very rudely awakened.

And I haven't linked to the site because they really don't deserve even the feeble publicity a link here would grant. I found them through the Blagosphere, and I don't post vias.

Wednesday, 23 May 2007

A Conspiracy

I don't believe in the Internet. It's a conspiracy of network engineers... with a lot of pigeons.

Friday, 18 May 2007

Continuing on Closures

This is the (long awaited) second part of my tutorial on closures. This part describes how your language's runtime might provide closures. I've assumed that you understand what a closure is, if not, read the first part of this tutorial first.

So by now we know that we can think of a closure as an object: an instance of an automatically generated class. This class has just one method: apply() that executes the body of the closure. The class has one member variable for each variable in the active scope at the time the closure object was constructed.

But local variables are only available to the function that defines them and even then only for the lifetime of that particular function call. How then is it possible for a closure to access these values? To explain that I'm going to briefly go over how functions work, bear with me if this all seems a bit basic.

Sometime back in the 1950's, during the design of ALGOL the concept of the call stack and stack frames were discovered. The call stack is just a list of called functions, implemented as a stack so that as functions return they can be popped off the call stack, leaving the calling function on top. A stack frame is the object that is pushed onto the stack to describe a function. A stack frame contains the line of code to return to when the function returns, the parameters to the functions and the local variables of the function.

Every invocation of a function causes a new stack frame to be created and pushed onto the call stack. Among other things, this makes recursion possible. Early versions of FORTRAN don't support recursion: no call stack.

Your program executes; functions are called; stack frames are constructed; values are calculated; frames are updated; and return values are returned. But every time a function returns its stack frame is destroyed, and the very next function called will completely overwrite the memory where the last stack frame was. So how can a closure always be guaranteed to still be able to access a local variable?

Earlier I referred to a stack frame as an object. In languages like C and Java a stack frame is not an object at all; it's just some conventions for how certain pieces of data are stored. All of which are calculated and laid out ahead of time by the compiler.

But what if the stack frame was an actual object stored with other objects on the heap? What if, instead of a stack, a linked list was used to connect the frames? Hmmm... interesting... The linked list would represent the call stack. Every new stack frame would be constructed with a pointer to the frame of the current function. Like all other objects, these frame objects would be subject to the garbage collector. This prevents a frame from being destroyed until it, and all functions it called, have returned.

Once the runtime provides this implementation of frames and the 'call stack,' a closure can include a pointer to the current frame. When the closure needs access to anything in its containing scope it can now just use this pointer. And as the frame contains a pointer to its calling function, the closure can now work its way back through any scopes it's interested in.

Extra Credit: The ability to work backwards through the scopes of all the functions in the call stack is known as dynamic scope. It's pretty uncommon now, as it's virtually impossible for a human to understand in any kind of complex program. As a result languages that support closures generally provide lexical scoping. In lexical scope the structuring of the program text defines the scopes available to a function; and therefore a closure can only use the local variables of the frame immediately referred to by the closure. But enough on scoping; for more compare early versions of Lisp to Scheme.
Frames as a linked list would not make any difference to your program as the act of reading the data stored in a frame is still hidden by the compiler and runtime.

And that's really all there is to it. Closures can now access local variables that seemed to only exist at the time the function was defined. The reference by a closure to a frame behaves like any other reference: the frame will not be destroyed until the closure is destroyed.

Hmmm... didn't I mention earlier that a frame also contains a line of code to return to? Doesn't that mean that any frame can be safely returned from? Yes, it does. Now, if we move our current line variable into the frame itself we have what's called a continuation. That is, a single frame object describes the current values of all local variables for a function, the next line of code to execute in the function and which function to return to. And that function in turn also has all the same information preserved.

If the language then allowed it, you could pick up that underlying frame object, store it away somewhere and then use it to later on continue execution where it was previously left off. Hence the name: continuation. To pull this off the language needs to provide two features.

Firstly, the ability to get a reference to the frame object for the currently executing function, at the same time halting execution. Secondly, the ability to call that frame object at some later point and have execution pick up exactly where it left off, as if there was no pause.

Continuations as a concept are regarded as 'difficult.' As a result, even though most languages that provide closures could also provide continuations the programmer is not given direct control over them. Some languages do provide this control: Scheme (noticing a patten here?), Ruby and Smalltalk, amongst others.

So what are these good for? Before getting into an example of how continuations can be used, I want to say one thing: powerful language features are always useful. If you're not used to having a feature in a language, the first time someone shows it to you the immediate reaction will be: 'Sounds cool; but what use is something like that?' A fairly normal reaction and simply the result of not having the feature available. Once you've used a language with an 'advanced' feature you'll find all sorts of uses, until eventually you won't be able to imagine coding without it.

Anyway, onto an example. When writing web applications a big problem is the enormous gap between the page displayed in the user's browser and where the server thinks the user is up to. Continuations can make this almost completely disappear. Once the application on the server has prepared a page, instead of winding up the call stack and then returning the page to the user a continuation could be captured. This continuation is stored on the server and a key is sent to the browser to be returned with the other data on the page. Using the key, the continuation is invoked, and execution of the function picks up where it left off.

The code running on the server to handle screens in the application could then look something like the below. The statement yield causes the continuation capturing to occur. And remember, all of this code executes on the server, there is no AJAX or anything like that.
function checkout()
  // The following three functions add UI elements to the
  // current page. These are rendered as HTML. 
  addButton(new NextButton());
  addButton(new PrevButton());

  yield; // Continuation is captured, and the page so far
         // is sent down to the user

  // The user has sent a response back to the server
  // The functions payment() and home are similar to
  // this function: they create specific pages.
  if (Page.SelectedButton == Button::NextId)
    payment(); // Display a page to collect payment
    home(); // The user wants to continue shopping

As well as this simple server side logic, the user can then explore multiple paths through the application concurrently, with multiple windows and using the 'Back' button with abandon. You, as a programmer and a program, will never become confused. Pretty nice, huh? There is a web server already out there that gives you this: seaside.st

And any language can make these powerful features available simply by implementing the call stack as a garbage-collected, linked list of simple frame objects, instead of a one-dimensional stack of data. Pretty powerful, and remarkably simple. Makes you wonder what other abstractions are lurking behind small implementation decisions.

Monday, 14 May 2007

Worst Example...Evar!

Way back in my first year of university, as part of a first year discrete maths unit we were taught introductory formal logic. After introducing propositional logic and covering ANDs, ORs and truth tables, we moved on to implications. For this particular lecture we had a fill-in lecturer. I can't remember why.

In explaining implication to us this lecturer used an example that has stuck with me ever since. This isn't because it was one of those glorious examples that are like a light being turned on; suddenly it is all clear and new vistas of understanding open up. Oh no, this example was the other kind.

One of those examples that distracts with its own internal errors and inconsistencies; that steers you in completely the wrong direction; and, best of all, pollutes your mind enough that you may never understand the original point.

The bad example:
An implication would be when your mother says to you: 'If you clean your room, then you can go to the movies.' So after you clean your room, your mother lets you go to the movies and the statement is true. But if you don't clean your room and go to the movies anyway, the statement is also true.


Logically, yes, that's correct. Single implication works like that. But the world doesn't, and it's pretty hard to ignore that little detail.

Bonus points if you can work out who the lecturer was.