杏吧原创

CALL ME a gardener, if you like, for I grow plants from seeds. But you won鈥檛 find my plants in any garden. They grow in the fertile soil of my computer, and their stems and leaves are made from software. My plants are computer programs that write, adapt and repair themselves. No programmer is required.

They could hardly be more different from today鈥檚 software. Conventional programs are designed to operate within strictly limited criteria, and these fragile monoliths crash at the slightest hint of an exceptional circumstance. Worse, modern software is fast becoming too complex for any one person to understand, and the bugs and glitches that are now accepted as an inescapable fact of life are the result. Most of us reluctantly put up with the frustration of rebooting our PCs and redoing the work lost in a software crash. But what if the faulty software is in the telephone network, or the microprocessor controlling your car鈥檚 brakes? What if it鈥檚 in a power station or an air-traffic controller鈥檚 computer?

Computing researchers have been aware of this problem for decades, and have been exploring alternative approaches. But now a shift in thinking about software is happening that could replace the programming methods of today with an entirely different way of producing software.

You could say we are going back to nature. I am convinced that in the future, software will evolve and grow instead of being designed and built. In place of programmers there will be digital horticulturalists who plant, prune and grow software from seeds that they have cultured. Not a single line of code will ever be typed into a computer again.

The consequences flowing from this new approach will be profound. Software will be able to alter its behaviour to continue to fulfil its function if its environment changes. And like a living organism, it will be able to repair itself if it is damaged by a computer virus, say, or a glitch in the hardware of the computer on which it is running.

This new software will be biological in all but substance. It will have the digital equivalents of genes, proteins, cells and organisms. We won鈥檛 be able to understand evolved software in the same way we understand the purpose of every line of code in human-designed software. But, crucially, we won鈥檛 need to, as we will be confident that our programs will adapt to their environment and heal themselves just like other forms of life. And if anyone feels uneasy over this loss of control, they can look at the world around them for reassurance that this approach works.

Software genes

The idea of using computers to evolve solutions to problems isn鈥檛 new. Programs designed to investigate and exploit the natural process of evolution in biology have been around since the 1970s (see 鈥淚n the beginning鈥�). But these were evolutionary solutions for optimising engineering designs, such as bridges and engines. What about software? Could we make computers program themselves?

A decade ago, an approach known as genetic programming (GP) seemed to hold the answer. In this approach, the basic commands and functions that make up a program 鈥� mathematical functions such as addition and multiplication, and programming statements such as loops to repeat sets of instructions 鈥� were treated as units that represent genes. These were then assembled by evolution into a working program. Outputs from the program were compared against a set of sample outputs, and the more the program got right, the better it was deemed to be. John Koza of Stanford University in California, one of the pioneers in the field, succeeded in evolving programs that define many different types of electronic circuit. Examples included analogue audio filters and amplifiers, and robot controllers.

But the initial flush of success with GP was illusory. Although these kinds of methods allowed small, simple programs to be evolved, something was preventing evolution from creating programs that even began to rival the complexity and capability of modern software. This was serious. What use was evolution if it could only ever design basic solutions to unrealistically simplistic problems?

In 1997, while I was researching material for the book Evolutionary Design by Computers, I was talking to developmental biologist Paul O鈥橦iggins, a colleague at University College London, about the processes involved in embryogenesis. I wanted to understand what really happens in biology. During the conversation, I realised that there was a glaring omission in computer scientists鈥� model of digital genes. There was no concept of development.

To explain, imagine we wanted to compose a melody. According to traditional computer evolution, we would use a gene to define each note of the melody. The first gene would define the pitch and duration of the first note, the second gene would define the second note, and so on. Guided by the ear of a listener, evolution would evolve good genes, and you would end up with a nice melody. If you wanted a longer tune you would include more genes to define those extra musical notes. But what if you wanted a symphony? You would need millions more genes. The human body has trillions of cells: what if you wanted a piece of music with similar complexity? You鈥檇 need trillions of genes. The numbers are just too big for computer evolution on its own to cope with.

And it gets worse. What if you wanted to have a melody that would survive any damage done to the score from which it is played 鈥� a melody that even if you dropped ink blots on it that obscured one-third of the notes would somehow be the same melody? How in the world do you make that happen with genes? But that鈥檚 exactly what we want. Replace 鈥渕elody鈥� with 鈥渃omputer program鈥�, and 鈥渘otes鈥� with 鈥減rogramming commands鈥�, and you see the problem.

Biological evolution manages to produce staggeringly complex organisms that build themselves, adapt, repair themselves 鈥� even make more copies of themselves. The genetic programming approach being used by computer scientists wasn鈥檛 even coming close. But the reason we were failing was plain to any biologist. We weren鈥檛 using development. There was no concept of growing a solution from a single cell into something with billions of cells. Though we were trying to copy biology, we had forgotten one of its fundamental processes: embryogenesis.

We had been using each gene to specify a part of a solution. For example, a gene defined a single note in a melody, or a single command in a computer program. Biological genes don鈥檛 work like that. In nature, genes are 鈥済rowing instructions鈥�.

Genes produce proteins. Proteins control everything: they turn genes on and off, they tell cells when to multiply, and what to become. The complex interactions that happen between proteins and genes, genes and proteins, proteins and cells, cells and cells鈥攁nd many other interactions besides鈥攑roduce multicellular organisms. Everything from a fruit fly to you and me.

This concept of development ought to ring a bell with many computer scientists. A gene behaves a little like a basic computer instruction called an IF/THEN statement, which works like this: if a particular condition is true, then perform a particular action. This matches what happens in biology almost exactly. A gene is switched on when the right proteins match its cis-site (the IF condition is satisfied), causing the gene to start making its own proteins (performing the action in the THEN part of the statement).

Natural born program

The human genome, or any animal鈥檚 genome, for that matter, is a computer program more complicated than any software ever written. What is more, it runs asynchronously (without a clock signal like the one a PC uses to synchronise its actions), and performs billions of these instructions simultaneously, in parallel. The other noticeable feature is that it works. Unlike computer software, nature鈥檚 code is not full of bugs. Only evolution could write this code.

By 1999, after studying biological development for two years, the next step was becoming clear to me. Instead of designing computer programs as we currently do, why not evolve and develop them as nature does? It鈥檚 not hard to implement. A digital protein can be defined by just a couple of numbers, one acting as its name and the other defining how much of it there is 鈥� its concentration. And just as natural genes look like IF/THEN statements, digital genes can be set up to behave the same way. For example, the digital gene 001011 001010 001110 would mean: 鈥淚F protein 001011 exists with a concentration above 001010 THEN increase concentration of protein 001110.鈥� Sets of these numbers representing genes and proteins can be stored together in a data structure such as a list, which represents a cell. Set the program running, and the genes start to emit proteins, which act on other genes, and so on.

Unlike in living organisms, our systems also have digital genes that are activated in the same way whose only purpose is to determine the function of the cell they鈥檙e in; they do not make proteins of their own. If activated, one of these genes might tell a cell to produce a copy of itself (like a biological cell dividing), or to perform a specific function (like a biological cell differentiating into a neuron or blood cell). These function-determining genes allocate a traditional computer instruction to each cell. For example, such a gene might say: if protein 001110 exists in the cell, then this cell鈥檚 function is to increase the value of a particular variable in the program by one.

We begin with one cell containing one set of genes and iterate through the genetic rules. The result is an evolved, developed computer program that might perform the same function as a program designed by a human. But the evolved program works in a way that no human programmer would ever be likely to dream up.

In this way, I have already evolved and grown a robot brain, from scratch, capable of controlling a real robot. Not only are there no bugs in this evolved brain, if you damage it by removing some of the genes or proteins that help build it, the brain will still develop and work.

Research in the area is expanding rapidly. Julian Miller at the University of York in the UK focuses on regenerative software. For example, his computer can evolve genetic programs that develop specific two-dimensional shapes made from hundreds of cells. If he then damages the shape by removing cells, it will repair itself by regrowing the right cells in the right places. There is no reason why one day an organic operating system or word processor 鈥� or something even more complex 鈥� could not be evolved and grown.

If these ideas are taken up commercially, programmers as we now know them will eventually become redundant. Instead, software will be developed in organic nurseries where it will evolve and grow like biological life to perform a specific task, adapting to its environment and changing its behaviour to fit new environments. Instead of programmers, there will be digital horticulturalists who develop seeds for the new software, which they then cultivate.

Code that is evolved and grown still faces many major hurdles, including some that are cultural rather than technical. Conventional software can be mathematically proved to meet its specification, a feature software designers are using more and more for crucial parts of their projects. With evolved code, such mathematical proofs are impossible, and that鈥檚 a worry for traditional engineers. They like to know how their systems work, and are suspicious of the impenetrable workings of evolved solutions.

This hostility is misguided. Conventional software may be provably correct in certain defined settings, but that doesn鈥檛 mean it won鈥檛 fall to pieces when faced with the unpredictable circumstances of the real world. Evolved systems will be more robust, and for reassurance we need look no further than how people behave. For example, we cannot predict or prove that human airline pilots will always perform appropriately in all situations, but we train them until we are satisfied that they are reliable. We need to adopt the same approach to software. We cannot predict what traditional human-designed technology will do under unforeseen circumstances, so there will, I am sure, come a time when we will trust software that adapts and lives in harmony with itself. Then we will have software ecologies, not software crashes.