The statement merely promotes a logical basis for software that can ensure robustness based on some compatibility with the (virtual, artificial, imaginary) world in which it must live. Software could be more like an appliance, you turn the key and it works. Things like cars handle continuous improvement and upgrades, without creating an environment the end user doesn’t understand or incompatibilities within the environment.

The amount of flexibility and complexity within the software “problem space” allows for more rapid development, but it comes with it’s own problems, and could remedied with more environmental regulation. It’s often a matter of the economics of infinite multi versioning.

Biological evolution is arguably inefficient. The shark and dolphin both evolved the same energy efficient body pattern through independent random chance. We have lost the “code” to provide us with gills, so we can’t just turn that feature back on for our summer holidays. We aren’t constrained like this when designing (evolving even) application evolution systems. We could for example – use libraries of previously evolved building blocks that can be plugged together to speed up the application creation process.

Are you not making the mistake of thinking in terms of basic unit testing & how that would be used to express requirements? Writing a test, then another test with slightly different values is like using Intel 4004 assembler rather than a modern programming language.

For example, taking your add example, we know that if x is 10, add(34,1) is the same as add(add(3x, 0x), add(4, 1)). In other words, to prove add(a, b) works:

1. We need to test it handles adding the small 2D array of values of a in -9 .. 9 and b in -9 .. 9.
2. Then for any two numbers, we can split them in to two sets of digits, use the proven add() to add the digits, handle the overflows and compute the expected result.
3. Provide the test method with a set of data and have it repeatedly apply rule 2 to the numbers to determine the expected result and compare it with the actual results.

Using this, we can prove add() for every single number combination with just two tests. And all I’m doing is using features in NUnit already. I’d be very surprised if testing frameworks in 50, 100 or even more years time will be substantially more advanced than NUnit!

Let’s evolve an implementation of Add(a: int, b: int): int … first some tests:

> test: Add(1, 2) = 3
> test: Add(34,-2) = 32
…
Done!

Okay, thanks computer, Add() is ready to go!

> Add(34,1)
6786998

Hmm, I see we needed to add another test case…

(And so on )

Managing the Byzantine set of test cases even for something as simple as Add() would be pretty onerous. Even if the computer could infer the full set of tests from our examples, there are an infinite number of functions that can fit a given set of points.

We might find some improvement in forming the tests from logical predicates:

> For all a, where a: int
> For all b, where b: int
> Add(a, b) = a + b

But, this isn’t a test any more (we’ve ditched the empirical measurement) – it is a theorem about Add(), and the role of the computer has turned around to start assisting with proofs.

And, the computer isn’t writing the code any more, we are…

(Someone with more background and familiarity with this approach might pick holes in this observation, of course.)

I’d love it if the future ‘feels’ like TDD, but at least as a naive observer, it seems like proof systems are laying the groundwork for that today, rather than the test-driven approach that you and I are using.

On the other hand, I’m quite happy writing code, and adding another indirection between what I express and what the computer executes seems like a leap I’m unprepared to make with the currently-available tools. Wrapping hand-written code with tests a-la TDD is something of a sweet spot, don’t you think?

Thanks for the thought-provoking article.

Essentially GP is a set of instructions and a fitness function to measure how well a computer has performed a task [cited: http://en.wikipedia.org/wiki/Genetic_programming

this sounds like GP all over again, i.e. an idea from 1954, the generations are faster but the principles remain the same

Reminds me of that quote “If houses were built like software projects, a single woodpecker could destroy civilization”

But as you say – that is why nowadays the growing trend is to apply TDD to ensure the software is robust, and use BDD and rapidly prototype applications so you don’t spend months creating something the client did not actually want.

It seems to me this dude probably mainly works for public sector projects where there is not the push nor even the need to be agile and competitive. I have often wondered whether agile applies as effectively to non-commercial type projects.