Fixed Point Madness!

I recall a while ago there was a bit of argy-bargy at work as regards some bit of code that my pair and I (in Singapore) couldn't make head nor tail of. We needed to make a change in the functionality that it seemed to be responsible for today, but it had been written by a pair in the UK whom we took to be at home, probably in bed given the time it was. It was this horrible while loop with a very complicated predicate and all sort of state changed around in the loop body. What I sometimes to call "Dijkstra" code. There was maybe even some state mutated inside the predicate. Shudder.

During a discussion of a different episode on the team wiki I described how working on complicated imperative loops like that gives me the same feeling as I get when from time to time I have to run a motorcycle engine with a cover removed: there are all these hard, sharp, choppy, crushy bits whizzing around at high speed just ready to hurt me badly (and destroy the engine) if I go fiddle with them in even slightly the wrong way. And flinging off droplets of hot toxic fluid while they go.

Well anyway, after scrutinising the rather unclear tests for the method containing this mystery loop I realised that what is was actually doing was finding the particular fixed point of a function (implemented as a dynamically built Chain of Responsibility of Strategy objects) in who's basin of attraction a given initial value lay. You are almost certainly better off not knowing quite how the presentation layer of a web application came to have such a thing in it...

So my pair and I wrote a FunctionObject class and fitted it out with a fixedPoint() method, rewrote the original code in terms of it (the nasty looping method became almost a one-liner) and made our change (now very simple to do). And went home thinking of a job well done — code base simpler, change easier to make, tests easier to understand, concerns separated, value added, Once and Only Once, broken window fixed, blah blah blah. And got in the next morning to find the UK developers furious that they had "wasted" a day trying to understand this incomprehensible "fixed point" madness. Which indeed they had rolled back out of the codebase. Not that they had to do any work on that method, or anything, they saw it as a curious incoming change.

I now understand that mainly this was all about Us (the UK developers) and Them (me an my pal in SG), and some surprising results about just whom had what ego invested in the code, and so on. But at the time that was all sublimated into some technical chat about how before they had just had to understand this complicated loop, but now they had to understand this alien fixed point concept and simultaneously understand how it was used to get the job done. This was presented as meaning that this part of the codebase was now hard squared.

My position was that on the contrary, one could now understand the fixed point concept on its own, then having internalised (or at least got comfortable with) it, then understand how it was being used in the website navigation separately: the square root of hard.

And there are some deep cultural differences here, and not between Singapore and the UK: I probably have the most mathematical education of anyone working as a developer and that played a part in my design idea. And the most exposure to functional programming. And so to the, yes, Romance (thank you for this thought, Michael) of making that refactoring.

I hadn't thought particularly deeply about attractors and such since studying dynamical systems as an undergraduate more than a decade previously. It was interesting to see the idea expressed in very different terms while autodidacting functional programming, but that was in past too. And now back with the wading through thigh-high mud that is J2EE corporate IT. But then here was this glorious opportunity to do something like the real programming that I dimly remember I used to make a living by, and with some real maths in it to boot! How. Cool. Is. That? Caused havoc.

Back to Dijkstra. There's a past generation of programming book that's nigh-unreadable these days. And not just because of drifts in technology. Of course, most contemporary programming books are unreadable, too. But for other reasons. I'm thinking of things like http://bookshelved.org/cgi-bin/wiki.pl">A Discipline of Programming. Now there's an example of Modern Programming if ever there was one — a manifesto for a Grand Narrative. Lucky escape for the rest of us that the industry went another way.

But those guys were doing something different from what most of us working programmers do today. Let's say that in po-mo stylee we decide to download and use a binary search function rather than write one. Better be careful. Famously, according to Knuth there was a gap of many years between the first publication of a binary search at all and the publication of a correct binary search. But of course, we wouldn't download anything as fine grained as a search function. But when it comes to actually writing code we'd use the one bundled with the language in question. Has it ever occurred to you to test the binary search in your favourite language to see if it really, really works correctly? If not, why not?

And maybe these days we live in a time of practical, workaday, mundane plodding is what pays the bills (there's nothing much more plodding and mundane that rendering SQL results sets into HTML, which is what "programming" seems to mostly mean these days) when a sniff of Romance, that sweet reminder of times past, becomes all the more desirable. But maybe, at the same time, that Romance is ill placed in the business context of rending the next result set. This thing we're calling post-modern programming maybe then is a way to avoid the horns of the dilemma — get the corporate IT drone work out of the way ASAP but avoid the trap of the programmer's instinctive moves to make the work more interesting: retreat to foundationalism, recreational cleverness, making the easy hard for the fun of it.