Generics Considered Harmful

Ken Arnold posted about the problems with generics, namely that they substantially increase code complexity without providing commensurate benefits.

He's spot on - generics are the programming language feature that never should have happened, and I speak as someone who, when I was a heavy user of C++, loved generics. Even now I yearn for the elegant consistency of the Standard Template Library. But the points Ken makes from a Java perspective apply equally well to C++, and C# as well. That generics increase both the semantic and syntactic complexity of code is undeniable. Their benefit as a runtime type-checking mechanism does prevent - or at least help diagnose - certain classes of bug. But these bugs are not generally especially common, nor difficult to diagnose or fix in the first place. This can be seen quite clearly when considering that dynamic languages, which enforce no type checking at all, do not suffer in development effort nor code maintainability as a result - if anything, they demonstrate the converse.

One benefit that Ken doesn't mention is the use of generics to signal a programmer's intent - to make a collection homogeneous is, to a limited extent, to make it self-documenting. Again though, this benefit is small compared to the complexity costs.

When I started typing I thought I had more of a point. Ho hum.

Configuration vs Customisation

I loved a recent post by GIS luminary Peter Batty about forthcoming developments in the GIS industry. However, I was struck by his allusions to a future release of Smallworld which would dispense of the problems caused by the common practice of individual clients writing custom software to tailor the system to their specific needs, by allowing sufficient data-driven customisation out of the box. I wrote a response which I think I'm going to post here as well. Suck it up.

My interest and excitement was tinged with a frisson of trepidation, at the description of the configurable GIS behaviour. I know there's a whole phalanx of very smart engineers at GE, who are no doubt immeasurably more cognisant of the following issues than myself. But, as is my wont, I'm not going to let that get in the way of an opportunity for a jolly good rant, so here goes.

Obviously data driven behaviour is brilliant. However, it's only good up to a point. Once the behaviour in question becomes complex enough (and a GIS definitely qualifies), there's a real risk of the Inner Platform effect: In an effort to achieve the same levels of flexibility as the programming languages that it is designed to replace, the configuration system ends up replicating all their features - badly.

Such an endeavour is caught between two stools. If it is insufficiently ambitious, the configuration will not be flexible enough to meet clients' needs. If it does manages to capture the power of the programming languages it replaces, then it is Turing complete, and all you have done is convert customisation using a standard, proven, well-known programming language into configuration using a ghastly proprietary language that is embedded within your configuration schema.

In addition, creating such a configuration actually ends up being much harder for clients. It requires deep proprietary skills, as opposed to common skills like C#, and it cannot lean on any of the supportive ecosystem of tools and knowledge that an established language has built up over the years. Perhaps worst of all, it will *still* require software engineering skills to perform the configuration, and all the good software engineers will have run a mile.

Like I say, no doubt there are smart people at GE who have been figuring out solutions to all this for years by now, but I'd have to hear what those solutions were before I'd trust such a system.

To my way of thinking, the best solution to the problem is to acknowledge that the best way of specifying behaviour is to use a programming language - that is exactly what they were designed for. Trying to sidestep that is simply swimming against the current, and you need to embrace it. You want a domain specific language (DSL), so that it is concise and intuitive for clients, but you don't want it to be a proprietary language - that way lies madness. So what you need is to provide is a library that extends an existing, established language, making it into your GIS DSL. Creating DSLs from Python or Ruby is all the rage these days, and I believe the above chain of reasoning is why.

Façade

by Procedural Arts (PC, 2006)

http://www.interactivestory.net/

Façade is an art and research project which aims to extend the remit of gaming, making a bold raid deep into rarely-explored territory. It opens with a voicemail, inviting you to visit old friends, and then presents the player with a first-person view from outside your caller's apartment door.

spoilers

Stepping up briskly, I was just getting to grips with the mouse cursor's context-sensitive prompt to knock on the door, when I began to discern the muffled but unmistakable sounds of an argument going on inside. The familiar sinking feeling invoked as you screw up your courage, overcome your hesitation, and knock regardless, is possibly a gaming first.

Awkward social situations are nothing new in other media, but the complicity engendered by interactivity and first-person immersion enhances the effect. It's a rich vein, and the ensuing interactive drama mines it deeply - starting with the knock, upon which a voice fiercely whispers "He's here already? I thought you said 8 o'clock?"

Your hosts Trip and Grace do their best to welcome you gracefully, but there's clearly tension in the air. You can speak to them at any point just by typing on the keyboard, and navigate the apartment, or mess with its fixtures, using the mouse. The story that unfolds is highly dependant on your behaviour, as Trip and Grace respond to you and to each other, using a social AI system developed specifically for this project. Consequentially, the storyline and its outcome varies massively from one replay to the next - although similar themes are often brought out somewhere along the way: the Italian holiday that no-one wants to talk about; the 'experimental' decor - a symptom of Grace's frustration with her uncreative graphic design job.

There are no goals, no score. No explicit measures of success. Judging by my few replays, the evening can end in one of a small number of ways, some of them are sad or embarrassing, others, perhaps the more elusive ones, are happy or hopeful. If the player chooses to adopt the attainment of a particular story-ending as a self-assigned goal, then that's up to them - and surely that's the very essence of what interactivity is all about.

Façade isn't without its flaws. The graphics are perfunctory - which is arguably a positive, since it's Southpark visual style steers well clear of the Valley, but will doubtless repel the superficiality of the mainstream. Similarly, the AI has a limited repertoire - it only knows how to converse around particular topics, using the words and phrases that have been recorded by voice actors. Again though, this has an upside, as the confines of the two-room apartment, its three occupants, and the prominence of their relationship problems all serve to reinforce the intensity of the situation. More pertinently though, even within these constraints the AI isn't perfect - this is a research project after all. The inevitable failure to recognise your typed input is often handled relatively gracefully, by a confused look from Trip or Grace, or an abrupt subject change, passed off as a deliberate avoidance of the topic you were broaching - a tactic that sometimes actually becomes more effective and engaging the more insistent your attempts become.

It's often-cited in the game development world that the industry is still not mature enough to know how to write a game that can make the player cry. The current state-of-the art is comparable to the crude motion-pictures of the late 19th century. Who would have believed, watching the grainy, silent flickering of Fred Ott's Sneeze, the narrative and emotional finesse to which that medium would one day soar? For all its faults, it's in increments such as Façade that gaming moves in the same direction.

Rating: 9/10. Lets. Push. Things. Forward.

Webfaction hosting

WebFaction - hosting for an agile web.

If you can see this post, then tartley.com successfully switched to WebFaction for our hosting, thanks to the resounding recommendations of Michael, and the genial-but-highly-competent aura emanating from the big cheese, Remi Delon. Shell access, Linux environment, open-source friendly, Wordpress directly catered for. I'm a happy bunny. Thanks all round. Maybe now I can finally get around to putting that photo gallery up?

Music 101¾

Writing music out by hand is incredibly laborious. Or at least, it is for me. This is my first attempt to pen some notes by plonking around on the keyboard until it sounds right. Doubtless errors of all kinds abound, which I'd be much obliged if anyone pointed out to me, tar very much.

Spiderman 3

spiderman3.jpg: Power corrupts

| The battle within. | Director: Sam Raimi | Writers: Sam Raimi, Ivan Raimi | Starring: Tobey Maguire, Kirsten Dunst.

That review again in full: Pants.

Rating: 3/10 for the special effects. I want my 2 hours back.

DirectX in IronPython

pyopengl-screen01.jpg

I've always preferred the open standards and cross-platform philosophy of OpenGL over DirectX. In recent years though, development of OpenGL has seemed to stall somewhat, while DirectX has continually put out new iterations that seem to significantly enhance functionality while improving useability. We use a lot of IronPython at Resolver, the dotNET dialect of Python, so the last couple of nights I thought I'd throw my principles and good taste to the wind, and work through the IronPython samples to see how well it works with the .Net interface of DirectX. The verdict: It works just fine. Albeit with colossal dependancies, for something that simply thows a dozen vertices around the screen. And only on one operating system. Gah.

12 Books That Changed The World

12 Books That Changed The World

by Melvyn Bragg (2006)

A brilliant assembly of potted snippets of history, ideal for someone like myself with scarcely a glimmer of an education. By cunning omission of the definite article, Bragg gets to talk not just about 12 important books, but is able to manipulate the list such that it is all about 12 British books, a move I heartily approve of. Apparently written to accompany some television series, I neither knew nor cared. For the record, his selection is below:


  • Principia Mathematica by Isaac Newton, 1687. "Will always have a pre-eminance above all the other works of human genius."
  • Married Love by Marie Stopes, 1918. Transformed the married lives of a whole generation, furthering the rights of women, and making it possible to broach subjects that had been entirely taboo.
  • Magna Carta by Members of the English ruling classes, 1215. The fundamental origins of the English constitution, setting up a balance of powers which forms the basis and language for many others since, including America and India.
  • The Rule Book of Association Football by a group of former English public school men. Codifying the most popular game on the planet.
  • On the Origin of Species by Charles Darwin, 1859. The greatest and most far-reaching scientific theory yet produced.
  • On the Abolition of the Slave Trade an oration by William Wilberforce in Parliament, 1789. This was published immediately after his oration in parliament, forming a cornerstone of the anti-slave trade movement, and eventually leading to the abolition of the slave trade just days before Wilberforce's death, a move that, in subsequent decades, was emulated by nations all over the world.
  • A Vindication of the Rights of Women by Mary Wollsenstonecraft, 1792. The first great feminine thesis, coming at a time when the world sorely needed it.
  • Experimental Researches in Electricity by Michael Faraday, 1839-55. A study in dedication and impartial perseverance, resulting in an astonishing number of discoveries which now affect the everyday lives of billions.
  • Patent Specification for Arkwright's Spinning Machine by Richard Arkwright, 1769. Trailblazer for a commerce-fuelled industrial revolution that shows no signs of slowing down in its transformation of the world.
  • The King James Bible by fifty-four scholars appointed by the King, 1611. A beautiful construction that has contributed more phrases and expressions to the English language than any other source.
  • An Inquiry into the Nature and Causes of the Wealth of Nations by Adam Smith, 1776. Transformed views of how wealth was to be measured and generated, practically inventing capitalism along the way.
  • The First Folio by William Shakespeare, 1623. No other work of fiction, religious texts aside, can match the cultural influence and endearing effect on our language that this body of work has had.

Rating:

9/10 if you know nothing, like what I do.

5/10 if you've already read all the entries in his list, like I haven't.

Daniel Kitson

regentsparkopenairtheatre.jpgkitson.jpg

Daniel's usual brand of heartfelt, bittersweet, dorky, whimsically playful stand-up, in the delightful environs of Regent's Park Open Air Theatre, with the Junior Penns & co, and Hallie visiting from Minnesota. More cynical souls were untouched, but Hallie and I loved it.

Music 101½

It's been said before by others, but I hadn't realised how insidious it is: When musicians talk about 'theory', they actually mean 'notation'. With reference to my previous whinging about music notation, I notice that the Music Notation Modernization Association are suggesting a number of revisions to make notation more useful and consistent. One of the more prominent suggestions is a change to the use of staves to make them compatible with the octave-offset principle I mentioned earlier, thus making the appearance of notes consistent across all staves, and making the use of clefs of any kind redundant.

The above idea especially comes into its own when combined with their other proposals:

Chromatic staves to indicate intervals in a proportional manner (rather than the current bonkers '♯' and '♭' notation)

chromatic-intervals.gif

Twinline staves, which only require two horizontal lines, rather than the conventional five, provides a significant increase in readability, in keeping with Tufte's principle of maximising data-ink ratio.

twinline.gif

Note color or shape used to discriminate pitch, rather than the current quirky use of partially indicating note length. This is perhaps my favourite, as it massively increases the ease of rapidly identifying notes on sight. Since note colour is currently used to distinguish between a minim and a crotchet, then some other way of making them distinct would have to be found. A unique flag on the note stem would seem to suffice, and would be more in keeping with the other note duration symbology.

note-color.gif

After what looks like years of painstaking brainstorming, research, focus testing and refinement, the only thing left for the MNMA to do is to decide on one single notation that unambiguously combines all the above ideas, and promote its use with the aim of gradually supplanting conventional notation. Unfortunately, this seems to be something they have singularly failed to do. By failing to adopt and recommend a single notation, they seem to be ensuring that none of their ideas will ever gain any traction.