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:

• Function decorators are going to change the world a lot. You’ll be able to annotate the functions, provide more information about what they do. How will we use this metadata? Maybe we’ll have criteria to select functions dynamically, or use the result of the whole application running to influence Bayesian selectors that alter how the application runs next time around.
• Maybe we don’t need small, tight code. maybe we want string classes that are megabytes in size, with a mix of very general and very specific code. Pile it all in! The statistical selectors will take care of selecting the most specific paths.
• Maybe a better way of coding would be reverse unit testing. Instead of calling a function to see what happens with your data, state what you expect to happen with some data that you already know the result for. Run that test across all available classes and see which match. Continue this for the entire application, and only run it fully if there’s a working path across the entire thing, like cogs and gears having to mesh to turn, or a lightning strike. You’d be able to drop in new functions that work faster and extend the application, and it’d grow. Maybe all function calls should dispatch in all directions simultaneously, and the answers and consequences compete for run-time.
• Perhaps we should give up on calling functions one at a time. With binding we can call more. Let’s say we have an object. We could call it with the data storage abstraction and the instructions at the same time… but why hand in these two things into the same method, when another method will be accepting the same storage abstraction? Have two binding methods: one to accept the storage, another to accept the instructions. call them simultaneously. Yes, it’s semantic – you could give it instance data at instantiation time – but at the same time it’s a little shift that could have big consequences.

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)