This assumes that there is program out there that does exactly what the customer wants, if there isn't the user would have to go and ask/pay a programmer to write it and would have to wait for the results. Also the end user might get certain features that program maker might want him to have, but the person himself might not want, for example Windows update.

The programmer has the added option of creating a program for himself, but that is not always feasible. So how can we minimise the time spent in the loop between desire and satisfaction so that computing can be a more enjoyable experience? The ideal situation is to give control to the user, whilst also giving ease of use to the user. As the system should do what the user wants without hassle. This is the eternal struggle that has been going on in computing, currently best typified by Linux vs Macs. Macs "just work" but you do not have control over what architectures it can be installed on and other advanced features like its kernel and what filesystems you use.

A possible solution

The ultimate optimisation of this feedback loop would be to make a program or collection of programs that could change theselves to how the user wants them. Rather than relying on an outside developer.

So if a user wanted a curvier user interface he would just indicate it and a program would just change, or he could indicate the magnetic north had changed and all programs that relied on a compass bearing would change. This would be the ideal situation.

There is no mathematical reason why this shouldn't be possible, after all a program is just a number and programs are well skilled with manipulating numbers.

Programmers and IT managers at this stage may well be going, "This guy is trying to do us out of a job! Why should we help him?", and they would be right to a certain extent. But to them I say, would you rather be on the crest of a wave or left behind? Would you rather be luddites or the trend setters, because this is coming sooner or later, if not my system then someone else's. The thousands of crashes, accidental deletions and screams of "Why don't you do this", will make it so. Also it would be best if it were an open source program as it would be hard to trust a closed-source corporation wouldn't put in back doors to make the program do what they or a government wanted. There will be plenty of jobs for this in the beginning ascompanies and individuals start using the new types of systems.

Whilst there are no mathematical reasons it is not possible there are however plenty of practical problems. There are many ways you could go about creating such a system, so I will briefly detail why I have chosen the way I have.

First, I have adopted the principle that the program should be as modifiable as possible. This is so that the program can alter itself as much as possible to conform to the desires of the user, minimising the amount of dependency the user has on the coder of the system. So imagine, if you will, a simple user-orientated self-programming system that can alter all its code with no constraints. We shall use this sort of program to illuminate the problems that any other self-programming system will have to deal with. Now as we cannot guarantee such a program is bug free there are likely to be a number of things that could go wrong with the program. I shall list a few of the practical problems that the program would be likely to encounter and then describe my system and how it deals with them.

1. The program modifying itself so that it jumps into empty code and stops executing
2. The program getting into an infiniteloop
3. The program letting in from the outside world or accidentally writing a virus that destroys the program
4. The program modifying itself so that it no longer modifies itself
5. The program alters itself so it no longer follows the wishes of the user

I shall briefly nod my head to those that have giants whose shoulders I stand upon, I shall properly reference this section later.My system is composed of many replicating programs that copy themselvesand alter their copies code. They execute in a virtual machine where the programs can guard there own code from modification. This solves the first three problems as if a program does a stupid action, their will be another program to take over and they cannot easily hurt the other programs. The fourth is thornier as, all things being equal, programs that don't modify themselves will be more likely to survive as they will have fewer flawed offspring, however if those that do change their offspring can find sufficiently better programs in a reasonable they will outcompete the static cousins. The fifth is slightly problem dependant, however it boils down to the user rewarding the programs those programs she likes, with a quality (I call utility or energy) that allows them to survive better. It does this in the current system by allowing them to over write those programs with less utility.

Some people familiar with Tierra might be asking, "What's the difference between this and Tierra?", well the main difference is the fact that the system is designed so that programs and not the external mutation is the driving force of the evolution. This property allows the way that the system changes its programs to change over time and it is this recursiveness along with a few other details that should hopefully make the difference.