Let’s step back a moment, before I summarise.

With code, what is the thing-which-is-invisible, like gravity is in physical space? What is this thing that makes some languages good, and some bad?

We’ll call it the shape of the code. It’s some combination of how changable the data structures are over time, how easily developers slip between the abstraction layers and edit the data without editing the behaviour code, how a development team learns the codebase, the social aspects of the code, how readable it is, how evolvable we want the code to be, how we want to sell it. It’s the human use of code, and the code use of humans. It’s the organic ghost.

We’ve always been trying to accomodate the shape of code, and every so often we get distracted by the single quality our current model promotes particularly well: OOP tells us good code is about isolating bugs and making code portable and sellable. Well yes, kind of, that’s part of the shape of code. But only part of it. Some languages tell us that good code is all about short, easily understandable scripts. That’s true too, but again, that’s only part of the story.

We have to look at what the nature of our code, our new objects, really is, regarding the thing-which-is-invisible and not whatever quality our language of the day says is the important thing.

Like proteins, which are irreducibly complex yet offer an abstracted surface which means they can pretend to be one another, our objects float in a data soup that they may bind to. We need ways of binding objects on a coarse level, and forms of introspection to look more closely. We need duck typing and precision checking in a single language. We have to operate by binding, which acknowledges these levels of matching, instead of quality and property, which doesn’t.

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