Introduction
Welcome to a work in progress site on the
Artificial life project Codesoup, that tries to explore evolution, how it
occurs and what is neccescary for the diverse and adaptive behaviour in
it.
In order to explore evolutionary behaviour you need a system,
in this case the system is a program called codesoup, that as the name
suggests is supposed to be a primordial soup for code. Here the code can
evolve and adapt to different challenges presented to it both from other
bits of code and from changes to what the environment rewards.
Now from Darwin we know that evolution needs variation and selection by
some method. What makes my soup slightly different from others is that
there is no external mutation. This means that any changes to the genome
has to be done by the parent. This is so that the methods of variation can
change over time, to be more creative or less destructive. Due to
the fact the system doesn't include anything like the central dogma of molecular
biology, this project will be a very poor guide to what happens in real
evolution, however that is not my main goal, which can be seen in the
Manifesto part of this website.
Here is the reason why I am doing this
The New Computing manifesto
Computing in the early years of the new
millennium is in a sorry state, with spam on the increase, viruses costing
millions of pounds worth of wasted time and effort, adware, spyware and vendor
lock in, and millions spent on training and retraining the workforce.
There are solutions to these problems but
most current technical fixes do not solve the underlying problem. The underlying reason for all these problems is that computer don't
actually do what you want them to do. They do what the people who
programmed them guessed that you want them to do, plus what the programmers want your computer to do. You may want a program that does not pop-up ads for porn or you may just want a program that can read a certain proprietry file type, but you are constrained to what you can find on the market. The typical user has to go through the following
arduous steps to try and fulfil his computing needs.
Find out the name of what he wants the computer to do (e.g. Firewall, spam filterer) Find out what programs are available Download
or buy the software Install it Optional swearing when it doesn't work, needs more hardware, or is terminally buggy
Repeat until satisfied.>
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. - The program modifying itself so
that it jumps into empty code and stops executing
- The program getting
into an infiniteloop
- The program letting in from the outside world
or accidentally writing a virus that destroys the program
- The program
modifying itself so that it no longer modifies itself
- 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.
Last modified:
Wed Jul 2 16:57:24 BST 2003
|