Secret origins of my programming career

Both Ivan and JD have been after me with one of these periodic personal trivia thingies.  Normally I can get away with pretending ignorance ("Blogs, you say?  The Internet, you say?") but when it's your boss and he makes a point of reminding you...  Fortunately, Sir John of Kearney has shown me the way...

How old were you when you started programming?

8.  Until then, of course, I was engaged in honest work -- up the chimneys, picking pockets, negotiating gruel quotas, etc.

How did you get started in programming?

As a poor Victorian youth, Mr Babbage (bless 'im) used me and my fellow urchins to demonstrate the principles of the Analytical Engine to the nobs.  "You pretend to be wheel number six," he'd say.  "When young Pip next to you carries the ten, you adds one to yourself, and when you gets up to ten, you lets Randolph here know about it.  Orright?  And don't let me catch you pinching the cupcakes again, my lad, or you'll feel the back of my hand."  Later he employed me in his workhouse: four burly workmen would rub my moustache against his brass pistons as what he claimed was an essential part of the milling process.  Thus was born my lifelong love affair with computers.

What was your first language?

Cockney.  Not Rhyming Cockney, of course, and certainly not your modern Visual Cockney or Jockney, the amusingly named port to the JVM.  We ran on the bare cobbles in my day, guvnor.

What was the first real program you wrote?

A map colouring algorithm.  It was actually relatively simple, because it just coloured the entire Far East pink, but in those days of the Empire, it was close enough.

What languages have you used since you started programming?

Punched cards... toggle switches... 6502 assembler...  Visual Basic 1.0...

What was your first professional programming gig?

The Kaiserbot 2000.  It was considered the gold standard implementation of a European statesman right through until the early 20th century, until we accidentally shipped a nightly build to Prussia where we had forgotten to #undef BELLICOSE.  After that we were forced to refocus our business around artillery targeting systems.

The bit that I wrote was the moustache control subsystem, which was basically about making sure that it twirled up at the ends at the correct angle.  I was proud that it was modular enough to be reusable with only configuration changes in the Kitchener-o-Matic several years later.

If you knew then what you know now, would you have started programming?

No.  If I knew then what I know now, then obviously I would have bet my shirt on Montrose for the Jubilee Cup in 1906, invested my winnings in Kodak stock, and retired to Cannes for the rest of my natural life.  Damn fool question.

If there is one thing you learned along the way that you would tell new developers, what would it be?

With today's roomy chimneys and modern extensible brush technology, a sweeping career can be for life, not just until puberty.

What's the most fun you've ever had... programming?

Writing vital customer demos in C, and checking them in under somebody else's name.

Here comes the flood

Measured further down the valley from me, so the flow numbers are moot, but look how steep the spike is.

The rainfall page for the same measuring station says that today has had the highest single day fall so far this year, so hardly surprising, but still dramatic.

MONIAC: adventures in analogue computing

Thanks to the wily Kirk Jackson and the, er, New Zealand Association of Economists, I had the pleasure this afternoon of seeing an unusual piece of computing history in action.  MONIAC, the Monetary National Income Analogue Computer, also known as the Phillips Machine, was an analogue computer invented by Bill Phillips (he of curve fame) to model and simulate the relationships between various economic factors.  Nothing unusual about that, except that it was invented in the 1940s... and instead of processing 0s and 1s, it processed water.  The Reserve Bank of New Zealand has one of the few Phillips Machines still around and in working order, and as part of a lunchtime session for the NZAE conference they had cranked it up and were demonstrating it.

The machine works by circulating water around a network of tanks, taps, pumps and pipes.  Values are represented by the levels of water in various tanks, parameters by opening and closing taps or moving valves up and down, and the key readouts of income and interest rates are recorded by pens moving against graph paper.  Water, of course, represents money, though demonstrator Geoff Bertram was careful to refer to it at all times as "the circulating medium."  I have to be a bit vague about what sort of things the various tanks and taps and throttles represented: explanations of the various bits in terms of private sector liquidity requirements and endogenous money supply undoubtedly made sense to the mainly economist audience but I'm afraid I struggled. Still, I gathered it was a pretty accurate simulation of the economic theories of the 1940s and 1950s; according to the demonstrator it effectively shut down a major debate of the time by convincing both sides that their arguments were actually compatible.

Of course, not being programmable, MONIAC can't be updated to reflect new factors and new economic conditions (such as globalisation).  The demonstrator did, however, relate how one lecturer used to set up two MONIACs, one representing the US economy and one representing the UK, hook up the relevant bits of piping between the two machines, and challenge two sets of students to do the best for "their" economy, so within the constraints of the model there was a certain amount of flexibility.

On the other hand, MONIAC's analogue approach still rivals the digital approach in some ways.  "It's solving nine simultaneous differential equations," noted the demonstrator.  Given the sophistication of modern numerical techniques, and the effort that has undoubtedly been poured into economic simulation and prediction, it's no surprise that the Phillips Machine has been superseded, but I suspect that ultimately the digital equivalents are just badly simulating water flow, only more flexibly and a lot faster.  One member of the audience, noting that the Phillips Machines had been used largely for educational purposes, asked Dr Bertram how he would present the same ideas now.  "I'd draw a hydraulic diagram," he replied.

This being a computer demo, of course, things did not go quite to plan; but this being an analogue computer demo, they went not to plan not through the usual syntax errors and unhandled exceptions, but instead because the bit of plastic representing the level of imports had fallen off and had to be stuck back on with blu-tack, and the export doohickey had become stuck against its housing.  Kernel fans will also be pleased to know that the Phillips Machine's ultimate failure mode is also described as "dumping," except in this case you end up with wet shoes and a massive carpet cleaning bill instead of just a nice convenient file.  "Now it sits in this bath here, and we've fitted a drain through to the outside," noted Dr Bertram ruefully.

(Incidentally, Bill Phillips was a New Zealander: connoisseurs of Kiwiana will therefore note that the use of blu-tack to hold the level of imports steady counts as Kiwi ingenuity, while the failure mode of spewing the "circulating medium," i.e. the national economy, all over the floor represents classic Kiwi ingenuity, or possibly Rogernomics.)

This highlights another interesting feature of the analogue approach: its unpredictability.  When the demonstrator was showing us "fiscal shocks" and "monetary shocks," he commented on how long the simulated economy took to react to stimuli such as suddenly injecting government investment or restricting lending.  "Sometimes they take 30 seconds, sometimes they take five minutes," depending on the mood of the machine.  Given the unpredictability of real economies, this in some ways seems like an attraction of the analogue approach. The downside? "Sometimes you'll be standing there talking about how things eventually come back to equilibrium, and everything's crashing and burning behind you."  At least when my demos tank they don't take national economies with them.

Due to short notice, I don't have any pictures, but Wikipedia does (as does NZIER at the link above), and if you're in Australia or the UK, I gather there are also kinda-maybe-working machines at Melbourne University and at the Science Museum.  There is also apparently one lost in Guatemalan jungle, so any budding Indiana Joneses of computing, now's your chance.

Another sf prediction lets us down

BBC News: "Martian soil appears to contain sufficient nutrients to support life - or, at least, asparagus."

In all the mass of science fiction dealing with the terraforming and colonisation of Mars, I don't think anyone has ever depicted a market garden economy based on asparagus.  Reality-shaping drugs?  Sure.  Angels?  Absolutely.  Elvis?  Everywhere.  Paul McAuley even placed a side bet on yaks.  But nobody ever anticipated this, did they?

Wellington .NET User Group - Introduction to DSL Tools

Thanks to everyone who came to this evening's session on the Visual Studio DSL Tools. Here are the slides and a reference version of the demo, plus (sketchy) notes on how to build up the demo starting from the beginning.

Slides

Demo solution

Notes on how to build up the demo solution

If you're not familiar with the motivating domain modelling/ORM example used in the demo, check out LightSpeed here. If you want to see how the sketchy demo builds up into a real working designer, you can download LightSpeed free.

And you can download the DSL Tools themselves as part of the Visual Studio SDK.

I'll try to write up some more notes on some of the aspects I glossed over, particularly how to generate code from the DSL at compile time and the joys of building and deploying custom tools.

Why the Silverlight VisualStateManager is wrong

Silverlight has a control templating system similar to that of Windows Presentation Foundation.  However, Silverlight and WPF take different approaches to updating the user interface as the user interacts with it.  WPF uses triggers: the creator of a template specifies changes to the template to be applied under certain conditions.  Silverlight instead has the Visual State Manager: the creator of the control puts it into different visual states, and the creator of the template applies UI effects according to the visual state.

The difference is clearer with an example.  Consider how we would make a button become highlighted the mouse is over the button.  For example, the Windows XP Start button glows when the mouse is over it; normal dialog buttons display a yellow border.  In WPF, we would achieve this effect in the button template with a Trigger on the IsMouseOver property.  In Silverlight, we would handle the MouseEnter event in the control code by setting the button's visual state to "Hot", and then in our template by including a VisualStateManager segment specifying how to handle the "Hot" state.  (I'm simplifying a bit here. Ian Griffiths has a great explanation.)

There's been some thoughtful back and forth about these different approaches, and the rumour is that WPF will be incorporating the Silverlight approach.  Let's hope not.  Although the Silverlight approach has some attractive features, it fundamentally breaks the lookless model of WPF.  It forces a control to have brittle knowledge of its user interface.  It takes the so-called "parts and states pattern," which is not so much a pattern as an admission of failure, and makes it the only game in town.

That's not to say that the Silverlight approach doesn't have its good points.  The ability to orthogonally decompose visual state into its components, and to encode once and for all when a button should be hot and when it shouldn't, is attractive.  At present, a WPF template author needs to consider all the possible conditions that should cause a button to display as hot.  For a more complex control with a more complex visual model, that invites bugs.  The "parts and states" model adopted by Silverlight, it is argued, makes the control's visual contract more explicit.  Here is a list of the visual parts and the visual states, says the control: you decide how you want them represented, and I will look after the rest.

The problem with the Silverlight approach is that it requires the control author to anticipate the possible user interfaces that designers might come up with.  Let us suppose, for example, that the author of the Button code, being a developer, hadn't really noticed that user interaction had moved on since Windows 3.x, and declared only two visual states, "Normal" and "Pressed."  A Silverlight designer who wanted their buttons to respond like XP or Vista buttons would be out of luck.  There is no way for the Silverlight template to represent "hotness," because the concept doesn't even exist.  By contrast, a WPF designer could create their own visual states as they saw fit.

This is not just about the subtleties of graphic design, or the joys of a full-on developer-designer workflow.  The ability to trigger off any property is fundamental to visualising data with WPF.  Consider a custom text box for editing numeric values: the sort of thing you'd be using in a line of business application, a "GUI green screen" with none of your beret-wearing designers involved.  You might need to display negative values in bold, red text so your users can easily identify deadbeats and go remonstrate with them.  No problem: add a trigger for the Value property.  (You'll need a value converter to translate a value into a sign, but you can still create that without having to modify the underlying control.)  In Silverlight, you'd have to petition the control author (who might be a third-party vendor) to add a "NegativeValue" visual state.  And then next day you'd find that you also needed a "getting low" state so your users could ring people up and advise them to top up their account quick...

The Silverlight VisualStateManager model, quite simply, cuts off the ability to create even the most rudimentary adaptive data visualisations.  As in the Windows Forms era, every view option requires support in the control itself.  Users of a control can no longer choose their own criteria for changing the display.

What about the control contract argument?  A WPF control can easily expose a suggested contract if the developer has one in mind.  Again, consider the button example.  If the Button developer wants to give the template author a shortcut, he can create an ActivationStatus property of enum type with possible values Normal and Pressed.  A designer who is building a Windows 3.x retro theme can stick to using those properties.  A designer who wants pulsing glows and mellow floating clouds, and finds that the ActivationStatus property doesn't meet his needs, can ignore it and go straight for the mouse events.  (The Mindscape NumericTextBox does something like this, by offering a NegativeStyle property for the common case, and a triggerable Value property for custom cases.  Not quite the same, but you get the idea.)  The Silverlight VisualStateManager does have the advantage that controls are required to declare their visual states through attributes, which makes it easier for tools such as Blend to tell designers what states they need to handle; but this could easily be added to WPF by defining a property-level attribute.  For example, our Button developer could place a hypothetical [VisualState("Activation")] attribute on the ActivationStatus property.

It has to be said that, given the constraints of Silverlight, the parts and states model, and therefore the Visual State Manager, does make some sense.  Silverlight's data binding is much weaker than WPF's; therefore Silverlight control developers are much more dependent on writing procedural code and calling setters on their template elements.  (In WPF you would normally prefer a TemplateBinding; that is, the template element reflects information of interest from the control's lookless model, rather than the control code pushing that information to distinguished elements known to it at design time.)  In order to call a setter, you need to know what your template elements are and have a way to locate them, and that drives you towards the parts model.  The parts model drives you towards assumptions about how your control's UI will be made up.  And if you are making assumptions about how your control's UI will be made up, then you can probably make some corresponding assumptions about how your control's UI will behave.  In which case you might as well code up those assumptions and spare the template author the hassle of writing <Trigger Property="IsMouseOver" Value="True"> for the eight millionth time.  It is indeed an exercise in the art of subsetting.

However, it's important to realise that the ultimate justification for the VisualStateManager lies in covering for present weaknesses of Silverlight.  In the WPF environment, where we already have template triggers and powerful data binding, VisualStateManager would be a misguided step towards a closer coupling of controls and templates.  The effort required to add VisualStateManager to WPF would be better placed adding triggers and data binding to Silverlight, and I hope that's what Microsoft does.

Palmerston North .NET User Group - Introduction to WPF

I took the "Introduction to Windows Presentation Foundation" talk to Palmerston North tonight and had a great time.  Thanks for your hospitality!  I'm constantly amazed at how active the so-called regional user groups are.  Thanks in particular to the chap (sorry, didn't get your name) who came all the way from Wanganui -- I hope it was worth the journey.

The slides and demos are at http://hestia.typepad.com/flatlander/2007/11/wpf-user-group.html.  Most of the demos include readme.txt files highlighting what the demo is trying to show and/or explaining how it works.

Also, there's a more step-by-step walkthrough of the list box earthquake map demo at Five steps to WPF data visualisation.

China Mieville, Iron Council

Iron Council is the third book set in the world of New Crobuzon, an ancient, bloated, fantasy-industrial city with more than a hint of the Gothic and the grotesque.  It tells the convergent stories of a democratic revolution within the city and a band of striking railway workers turned legends and nomads outside it.

The law of diminishing returns has hit the New Crobuzon series faster and harder than almost any other recent fantasy.  The first book, Perdido Street Station, was a fine romp.  The second, The Scar, tried to extend the franchise outside the gloriously mad setting of the city, but somehow the magic didn't travel.  Iron Council revisits territory from both of the previous books; but the ground is barren, mined out, and the book's attempts to deflect attention from the lack of substance with heavy-handed style and shocking imagery actually have the opposite effect.  With Iron Council, the series has reached the point of self-parody.

Mieville has a Clive Barker-like aptitude for gross, biological horror, with a sense of whimsy that makes it more horrible still.  Ideas like the Remade, the magics and weapons of war, and so on were dramatic and imaginative when he first used them.  Lacking new ideas, however, Iron Council tries to renew the old ones by making them even more extreme and unexpected.  The effect, unfortunately, is alternately tedious and ludicrous.  For an example of the latter, we encounter one war victim, "his skin erupted and splitting from beneath with dental wedges" because he was hit by a "toothbomb."  A toothbomb?  Sure, it's memorable, but for all the wrong reasons.

For an example of the former, whereas Perdido Street Station used character death to create emotion and sympathy, Iron Council uses death the way most books use semicolons.  The book is a cavalcade of mutilation and slaughter, a procession of meaningless, grotesque deaths.  One feels that the author is trying hard to shock, but the cumulative effect is just boredom.  Consider the description of the "cacotopic zone."  This is trailed as a hideous inruption of unreality whose mere name is enough to strike fear into the heart, and when our heroes cross its periphery they do indeed get horribly killed by grotesque monsters, turned into strange biological horrors and sucked into alien dimensions.  Admittedly that may sound bad, but in Mieville's world there's a fair chance of getting horribly killed, turned into a horror or sucked into alien dimensions just opening your breakfast marmalade.  Mieville's world has become so routinely full of grotesquerie and violence that, when he needs to pull out something special, he has nowhere left to go.

The writing style has also moved on to the point of self-parody.  Always grandiose and dramatic, Mieville now drowns almost every sentence in a rich, eggy ambergris of minatory descriptiveness.  "[The sun]'s vividness seemed to green slowly as it sank, as if it were verdigrising."  (Verdigris is a verb now?)  "The snow on its top was a colour snow should not be and was not snow but something alive and tenebrotropic."  "Mussed by that ineffable bad energy, the explosion of shaping, a terrible fecundity.  Vistas."  (Even sentence structure is not immune from the "mussing" effects of Torque.)  A landscape is "liminal... merciless... insinuatory, and fervent, and full of presences, animalised rock that hunted as granite must of course hunt."  (All of the above taken from just one two-page spread, chosen at random, and by no means the best: I can't resist mentioning the despondent chap who "could not map the alterity he felt."  Cheer up mate, at least you haven't had your nadgers Remade into a decorative fountain of the Emperor Napoleon.)  At least this clears up the mystery of who got Stephen Donaldson's dictionary when he decided to go straight.

Finally, the plot.  As with the previous books in the series, the plot is pretty much desultory.  (In fact, there are several plots, all of them desultory.)  This didn't matter in Perdido Street Station because the verve of the telling and the novelty of the setting made up for it, but Iron Council lacks those fig-leaves and at over 600+ pages the story drags.  Even the author seems uninterested: when the main plot looks about to reach a conclusion, he just... stops.  Some authors -- M John Harrison springs to mind -- excel at these "refusal of closure" endings, but Mieville's writing is too in-your-face, lacking Harrison's distancing style and fractured substance, for such an ending to feel appropriate or satisfying.

Fortunately, it looks like Mieville is taking a break from New Crobuzon after Iron Council.  His latest book is a children's book which looks rather jolly and whose market will presumably force him to temper his Barker-Donaldson tendencies.  Perhaps when he comes back to New Crobuzon he will feel reinvigorated; certainly there's a lot of potential left in the setting.  This, on the other hand, is a weary flogging of a dead horse.

Michael Swanwick, The Dragons of Babel

Michael Swanwick's The Iron Dragon's Daughter is one of the classics of recent fantasy, combining a compelling storyline with a rich, imaginative, genre-redefining setting.  Given that, it's understandable that Swanwick has written a sequel, and it's laudable that he held out for 14 years before doing so.  It's also inevitable that the sequel falls short of the original.

The Dragons of Babel follows a half-mortal village boy who becomes caught up in a war, escapes into the underworld of a great city, bluffs his way into high society and eventually achieves -- and escapes -- his birthright.  The story is conventional enough and its primary purpose is to join together the episodes in which Swanwick shows off his weird and wonderful world.

And those episodes are pretty good.  Sometimes they're industrial-era vignettes translated into the vocabulary of Swanwick's Faerie, but even these work pretty well.  The segment in the prison camp, for example, is well told, and garnished with just enough eeriness to give it an aura of the fantastic without destroying its impact.  Other times they are heroic fantasy tales transposed into a decadent, modernistic context.  The segment with the rebels in the underground, riding to battle on horses and motorbikes, provides not only a fun image but ultimately also a telling insight into Swanwick's world.

The problem with The Dragons of Babel is that it is content to live within that world, to take it as a fact and explore it as one would any other fantasy world, from Middle-Earth to New Crobuzon.  The Iron Dragon's Daughter, in contrast, teetered constantly on the brink of doubt: its echoes of and references to the real world created a vertiginous sense of ambiguity.  Much of the thrill of the earlier novel came from the tension between the fantastic and the real.  In The Dragons of Babel that tension is fatally missing.  There are some desultory references -- Swanwick reuses the trick of turning quotes that are well-known to the reader into gnomic prophecies -- but ultimately Swanwick's world has become just another fantasyland.

Admittedly, Swanwick had to do something different this time around: he couldn't just trot out the same threads that drove The Iron Dragon's Daughter and change the name of the hero.  But instead of trying to find some other way to create the sense of wonder that the earlier novel did, to add another level to the setting, The Dragons of Babel settles for revisiting the surface fantasyland without worrying about what might or might not lie beneath.

Still, as fantasylands go, Swanwick's merits this modest tour far more than most of those that get a three-volume epic.  There's no lack of fun to be had here, with clever vixens, ribald centaurs, ennui-stricken lords, clerks by day who are sexy thieves by night, confidence tricksters who are more than they seem, and so on and so on.  It's a pleasant enough read, but one which sadly misses the point of what made The Iron Dragon's Daughter so extraordinary.

When thesauri attack

My little weather gadget is currently offering the following predictions:

Monday: Mostly sunny and nice

Tuesday: Mostly sunny and pleasant

Wednesday: Partly sunny and delightful

Delightful!  How often do you ever see the weather described as delightful?

I live in hope that Thursday will be 'somewhat cloudy but spiffing.'