Jon, I think you're on the right (or at least an interesting) track here, one that I have been thinking about a bit myself. For me these thoughts came after w

Jon, I think you're on the right (or at least an interesting) track here, one that I have been thinking about a bit myself. For me these thoughts came after working for a few years on a clean room reimplementation project for a software component with a large set of automated tests (thousands). Slowly I got the feeling that each of those tests could be seen as an image of an unknown object, and that my job was to construct that object. Looking at just a few pictures it might be easy to find an object that could be projected onto planes to create those images, but looking at thousands of images it can be a very intellectually challenging task to find a single object that matches all of them. It's also a problem that has far more dimensions than the 3D world we live in. In agile programming you may call those images "user stories". Agile basically says "there is no way to know all the images beforehand (because that depends e.g. on a market response), so just start with the most important images and build the simplest possible object that fits with them". Each time you add in a new image there's a risk that you have to make major changes to the object (to make it fit with the new image while remaining "compatible" with the previous images). That's what's called refactoring. The really irritating thing with programming is that the effort of building a program does not scale linearly with the number of images (at least not in most cases). There is really no limit to how much work you may have to do to make the object fit with one or several new images, while remaining compatible with all the previous ones. That's because imperative code is a description of the object and not a description of the images. What a programmer does is really solving the global optimization problem of constructing a minimal object that fits a number of images, and then writing that down in code. The better the programmer the more images they can handle, the more beautifully the images will match the object and the simpler the object will be. It must be possible for a machine to do this. Don't get me wrong; it's a formidable optimization problem - and there are certainly sets of images for which no (reasonable) object can be constructed - but in principle it must be possible. In fact there is a machine that does this for simple x-ray images and physical 3D objects: a Computerized Axial Tomography machine, or CAT scan as they call them in hospitals. Basically, what these machines do is take a series of x-ray images of an unknown object and then compute "backwards" what that object must be like on the inside in order to have created those x-ray images. I bet a really good programmer would be great at manual tomography, and that when you have implemented your new programming paradigm it will be a sort of CAT scan for software. :) I'd love to talk more about this on occasion!