Main

What is codesoup?

What has been done so far?

So you want to help

FAQ

Docs

Links

Sourceforge Project

Sourceforge Forums

Sourceforge CVS

Contact me.

SourceForge.net Logo

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.

    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.


    Last modified: Wed Jul 2 16:57:24 BST 2003