In summary, I’m talking about a Step 3 world of programming that people have been talking about for some time.

Jaron Lanier introduces the concept of “phenotropics” in his essay, Why Gordian Software Has Convinced Me To Believe In The Reality Of Cats And Apples, and he continues in other presentations and essays to be found on his website (at the bottom). This is the protein-binding argument, but he makes a compelling case for pattern matching in general.

See also Charles Simonyi and Intentional Programming.

What these have in common is that they’re all about the programmer, what the code is trying to do, and apaptability and evolvability of the code. [Of course there are links to Adaptive Design here, but I think it’s productive to keep on looking at just the practice of writing code, itself.]

In a way, we forget about the difference between code and behaviour, because the two have always been intertwingled. Instead, we try to make transformations between different representations of data, and setting up these transformations explicitly means that we can make automated transformations between more tenuously connected objects. These automated chains will be lossy, but they’ll work—roughly. We’ll have to give up the predictability of guaranteed, so-called lossless transformations, because they don’t exist. That’s what network programming has been teaching us for a while… and if you transform between different mailbox formats, to weblog comments, to mailing list archives, you’ll know all already about lossy transformations, how they can be improved, and how to live in this kind of world.

Abstraction layers aren’t absolute. They exist at all resolutions: they’re course if you don’t care about an object that much, and fine-grained if you do.

And whatever we talk about, what happens is that this Step 3 programming is a world of evolvable, reusable, growable code, but that places limits on us. It means that code becomes an even more social enterprise, and interaction between code is governed more by how much you know and hear about, and less about standards institutes and top-down governance. Of course, the bottom-up nature of code has always been there, but this step of programming should acknowledge it.

[Before we get too carried away, there’s a quote from Dancers at the End of Time by Michael Moorcock I like a the moment: “The universe is one vast tautology, brother, yet no one thing is the same as another.” [p585] It’s fruitful to think about how that is true.]

So, a few ideas about where to go from here and what to look at:

These are all something that I’ve taken to calling shape and bind. Instead of asking for a string, you’d say what methods you want to perform on it, and you’d get a list of possible classes back. Better: you say what methods you’d call and with what parameters, and what you’d expect to get back. Everything that matches this behaviour is given as an option. It’s basically like running a unit test against all classes to see what sticks. You’d make a call to a constellation of methods simultaneously. Some you couldn’t call together (analagous to that niche being filled), but some you could. eg: $ob->doDatabaseOperation($x, $y) with $ob->dbHole($db).

Let’s play.

[I wish I could capture the conversation that followed. I was lucky enough to have a room full of programmers, and the suggestions and languages they came up with – and discussed – were eye-opening. I just wish we could play as easily with creating new classes of language as we can with glue code. These ideas beg to be made real, as a method of discourse, instead of hand-wavingly presented.]

Matt Webb, posted 2005-09-02 (talk on 2005-06-11)