Functional and object oriented programming both suck

[McSwan]

The biggest problem with programming is that the code cannot change, unless a programmer changes it.

ie Data driven design allows data to be changed, but not how it is interpreted.

The ideal way to program is to allow a program to adjust it's own code as well as it's data.

The issue, is that, in reality anything can be related to anything else. ie flying elephants are related to purple fish. They are related because they are in the previous sentence together. When you stick ideas into "objects" it represents one of the millions of ways objects can be related together. Frequently, placing "objects" together in object oriented language begins excluding the possibility of other relationships, hence, in our current state of programming, programmers will be programming forever, never able to represent every possibility.

However, what if program can build, change and test relationships between it's data?

[nullsquared]

The problem is that computers are so stupid they only do exactly what you tell them. There's all kinds of advanced concepts out there (there is code that can write and extend itself), but it still all boils down to what the programmer hardcoded for the base.

[McSwan]

What if the base is written generically?

[Kojack]

The ideal way to program is to allow a program to adjust it's own code as well as it's data.

One problem with self modifying code (depending on how self modifying it is, on the Amiga some people used to write code which continuously modified itself) at a lower level is that it pretty much ruins cache and branch prediction performance, plus you can't run the code from rom (without copying it into ram first, which on small devices is very wasteful). Higher level self modifying code (like in a vm based language) isn't as bad.

A kind of related thing is runtime assemblers like SoftWire. You can write a block of assembly using c++ objects (eg. you have a compiler object, and it has methods for every assembler opcode), including using if commands to conditionally add bits of code, then tell it to assemble the block. It returns a pointer to where the assembled result is, you just call it like a function pointer. This lets you do things like check the cpu type for enhanced instructions (like sse) and insert them directly.

[McSwan]

Hi,

I found a better way to do self modification:

It doesn't suffer from the awkward problems of trying to change a program on the fly.
Instead, It compiles a copy of itself and runs it, and kills itself.

You could easily add code to modify it source before it recompiles itself and runs.

I use g++ which requires mingw, etc to run on windows. You could easily replicate the same idea using visual studio.

Code: Select all

/* This program is designed to be an Introduction to "Code Generation Design." */

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

#include <iostream>
#include <cstdlib>

using namespace std;

int main(int argc, char *argv[])
{
	cout << "Hello, world! I am Alive! Rooaaar!" << endl;
	

/* Modify the code here */


	if (system("g++ -o asexual_mutator asexual_mutator.cpp")!= 0)
	{
		// some sort of error - quit for now
        	exit(0);
	}
	system("./asexual_mutator");

	cin ;
	
	return EXIT_SUCCESS;
}

Here's example of how you could use the above. I tried making it simple but self changing code can be hard to get your head around. They were experiment 1.1 and 1.2 for my masters:

Code: Select all

/* This program is designed to be an Introduction to "Code Generation
Designs." */

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

#include <iostream>
#include <cstdlib>

#include <stdio.h>
#include <time.h>

using namespace std;

int main(int argc, char *argv[])
{
    cout << "Experiment 1, Part 2 Asexual Mutator\n" << endl;
    srand ( time(NULL) );

    FILE * pFile;
    long lSize;
    char * buffer;
    size_t result;

    char stripped_exe_name[512];
    char code_filename[512] ;
    char number[32];
    ////////////// Self Modified code ahead! //////////////////////////
    // The next line is changed from the code above, to give a unique exe name
    int self_modified_int = 3; //this is changed to a number from 0 to 9.
    ///////////////////////////////////////////////////////////////////
    sprintf( number, "%d", self_modified_int);

    // The file that created this program is the same name as the exe except with a .cpp extension
    strcpy(stripped_exe_name, argv[0]);
    char* endpoint = strstr(stripped_exe_name, ".exe");
    if (endpoint != NULL)
    {
        *endpoint = '\0';
    }
    char* remove_dot_slash = strstr(stripped_exe_name, "./");
    if (remove_dot_slash != NULL)
    {
	remove_dot_slash += 2;
	strcpy(stripped_exe_name, remove_dot_slash);
    }

    strcpy(code_filename, stripped_exe_name);
    strcat(code_filename, ".cpp");
    cout << "Opening file ----> " << code_filename << endl;

    pFile = fopen (code_filename, "r" );
    if (pFile==NULL)
    {
        //fputs (code, f);
        cout << "Couldn't open file " << code_filename << endl;
        fclose (pFile);
    }

    // obtain file size:
    fseek (pFile , 0 , SEEK_END);
    lSize = ftell (pFile);
    rewind (pFile);

    // allocate memory to contain the whole file:
    buffer = (char*) malloc (sizeof(char)*lSize);
    if (buffer == NULL) {fputs ("Memory error",stderr); exit (2);}

    // copy the file into the buffer:
    result = 0;
    result = fread (buffer,1,lSize,pFile);

    char *insert_null = buffer + result;
    *insert_null = '\0';

    //if (result != lSize) {fputs ("Reading error",stderr); exit (3);}

    /* the whole file is now loaded in the memory buffer. */
    char the_programs_code[30000];
    strcpy(the_programs_code, buffer);
    // This is where the code gets weird. The code that we're looking for
    // hasn't been executed yet.
    char *pmutate_point = strstr(the_programs_code, "int self_modified_int = ");
    // change the code so that it choses a hard coded number instead of new num
    pmutate_point +=24;
    int new_num = self_modified_int;
    while (new_num == self_modified_int)
    {
        new_num = rand() %10;
    }
    switch (new_num)
    {
       case 0:*pmutate_point = '0'; break;
       case 1:*pmutate_point = '1'; break;
       case 2:*pmutate_point = '2'; break;
       case 3:*pmutate_point = '3'; break;
       case 4:*pmutate_point = '4'; break;
       case 5:*pmutate_point = '5'; break;
       case 6:*pmutate_point = '6'; break;
       case 7:*pmutate_point = '7'; break;
       case 8:*pmutate_point = '8'; break;
       case 9:*pmutate_point = '9'; break;
    };

    // terminate
    fclose (pFile);
    free (buffer);

    // figure out what the cpp filename should be
    char cpp_name[1024];
    sprintf(cpp_name, "Part%d.cpp", self_modified_int);

    // Now save the new code
    FILE * f;
    f = fopen (cpp_name, "w" );
    if (f!=NULL)
    {
        fputs (the_programs_code, f);
        fclose (f);
    }


    // Mutate the name of the resulting executeable
    char buf[512];
    strcpy(buf, "g++ -o ");


    char exe_name[256];

    strcpy(exe_name, argv[0]);
    exe_name[6] = number[0];

    cout << "number " << number << endl;

    cout << "exe " << exe_name << endl;
    strcat(buf, exe_name);
    cout << "buf " << buf << endl;
    strcat(buf, " ");
    strcat(buf, cpp_name);

    cout << "Creating " << buf << endl;
    if (system(buf)!= 0)
    {
        // some sort of error - quit for now
        exit(0);
    }

    system(exe_name);

    //char a;
    //cin >> a;

    return EXIT_SUCCESS;
}

Here's what it does:

Part 2.
Hypotheses: Prove that a program can take it's source code, slightly modify it, and
create a new program and source from the modification. ( Design: Asexual Mutator)
Again, this is a slightly more complex example of Code Regeneration Design.
Please refer to the file on disk instead of Appendix A for the source listings.
The program when run, will do the following.
1. Generate a new mutated file of it's own source, with a different name.
2. Compile the new source and create a new (differently named) executable.
3. Exit and run the new executable.
When one runs the program, you can see it creates a new source file Part3.cpp, and
then compiles a new program from it, Part3( the executable). Part3 runs and creates
a new executable Part? ( where ? is a random number between 0-9) and a new
executable Part?. Part? runs and creates a new source Part? and executable Part?,
and so on and so forth. The program continually gives birth to new programs, and
dies immediately afterwards, theoretically forever.
Explanation of source code:
Declare the code that will get mutated at the top. In this case it's called
int self_modified_int = 3;
The program will change the value “3” into a random number from “0” –“ 9” by
changing the source code.
The self_modified_int is then used to give source code a new filename. For example
Part2.cpp will now be modified to Part3.cpp.
Part3.cpp will have the code int self_modified_int = 3; modified to a random value,
which will be stored in Part3.cpp. Part3.cpp is then compiled to produce Part3 ( the
executable).
Part 3 is then executed, which does the same thing as the previous executable, and
randomly create a Part?.cpp (where ? is a random number between 0-9) and Part?
executable.
The program jumps between executables forever.
Summary
The program proves that a program can take it's source code, slightly modify it, and
create a new program and source from the modification.

I have videos of these, it makes more sense to see them running.


For my masters the last experiment wrote a program thats learns it own programming and rewrites itself according to what the user wants. It's still very simple atm though, and theoretically generic ( I need to prove it's "generic - ness"). I have a video of it which I can show you if you like.

I'm doing some more experiments program mimicry, which, is the process of one program learning what another program does and attempts to write a program that is similar.

I might try and put the videos up on you tube and edit this post.

[jjp]

Can you give a practical example where self-modifying code would be useful? "Anything can be related to anything" is not a good justification - of course everything can be, in some sense. To take your example I probably don't care at all if flying elephants have something to do with purple fish. Abstracting this relationship away would be sensible, then. Simplification and abstraction are the point of modelling something within a computer, after all.

[McSwan]

I'm writing a paper on this to explain it better. ( The paper is what I'd consider revolutionary. It's hard to contain my excitement. I'll share it as soon as it's finished to get opinions.)

But in short,

I probably don't care at all if flying elephants have something to do with purple fish.

You do care, because ignoring possibilities makes your code non-generic. Hence, the inevitability of more coding work for you.

Abstracting this relationship away would be sensible

Again, Good-bye generic code.

[xavier]

The paper is what I'd consider revolutionary.

I would try to contain my excitement until after peer review.

I probably don't care at all if flying elephants have something to do with purple fish.

You do care, because ignoring possibilities makes your code non-generic. Hence, the inevitability of more coding work for you.

I refer you to YAGNI.

[McSwan]

I refer you to YAGNI.

Well, I'll put it to you this way. Your brain handled the "flying elephants have something to do with purple fish" connection. Why would it handle a stupid connection if it wasn't needed ?

Anyway, talking in riddles because I don't want to give away the secret until I've finished the paper sucks. I've spent at least 5 years researching it, with many, many many, many failures, and only the smallest of successes. Just wait for the paper, I'll post it in general. Hopefully only a couple of days away now. It'd be nice to get some more time writing testing code, but I think I have reasonable proof for now.

[xavier]

I refer you to YAGNI.

Well, I'll put it to you this way. Your brain handled the "flying elephants have something to do with purple fish" connection. Why would it handle a stupid connection if it wasn't needed ?

Why do you assume my brain handled the aforementioned? The central tenet of YAGNI is that you don't -- if there is a connection to be dealt with, and you don't need to deal with it now, you don't.

I have to confess that I am skeptical of a computer system that can make that connection in some meaningful way, without a programmer doing "more work" to help it make that connection. Even andriods are programmed, and someone had to do the work to program them. Anything more requires sentient consciousness, and if you are saying you are a few days away from a computer system that not only can truly reason for itself, but make new logical connections for itself with no human intervention, then yeah, I'd keep that to yourself until, as I said, it's been thoroughly peer reviewed, because you've discovered in 5 years what the best minds on the planet haven't been able to do in the past 50.

[jjp]

I probably don't care at all if flying elephants have something to do with purple fish.

You do care, because ignoring possibilities makes your code non-generic. Hence, the inevitability of more coding work for you.

Abstracting this relationship away would be sensible

Again, Good-bye generic code.

I don't really believe making the code generic in your sense can involve less work than not doing it and adding/changing code later. I repeat my request for a practical example where your self-modifying program would be helpful. There are lots of reasons why programs don't change themselves (anymore). I imagine you need a language with a very restrictive structure to do this without reliability and security going down the drain.

[Thrakbad]

Well I'm really looking forward to reading this paper. But you'll excuse me for having a few reservations here. Maybe your ideas are really groundbreaking, then I'll tip my (non existant ) hat to you after reading the paper. At least until then I'm with xavier here and do not see why I should need it. In my mind a program should only be able to handle the tasks it is designed for. And for the vast majority of the existing programs the relation between flying elephants and purple fish can be neglected. When you're talking about a program that searches for new tasks itself and discovers the knowledge base for them itself, well that would be nice, but I'd have huge security concerns with such things.

[volca]

The issue, is that, in reality anything can be related to anything else. ie flying elephants are related to purple fish. They are related because they are in the previous sentence together. When you stick ideas into "objects" it represents one of the millions of ways objects can be related together. Frequently, placing "objects" together in object oriented language begins excluding the possibility of other relationships, hence, in our current state of programming, programmers will be programming forever, never able to represent every possibility.

However, what if program can build, change and test relationships between it's data?

Code does not have an idea about the data it processes besides what it is given to understand by the programmer. I so far don't see how a self-modifying code could improve this.
Data driven application is half way there (the universal code I mean). Component based objects approach also helps (In case this approach can be used). Aspect oriented programming is somewhat failing approach to this as well. I say give the data driven application the possibility of extensions and you're as far as you want. Start with an empty space that can define objects, rules, relations and representations, then create some of those and give them meaning using "plugin/extension" code.

But the problem is always the same - the more generic you're trying to be, the more crap the code will contain - it will be possible to express nearly everything, but also anything will be hard to express.

[nikki]

Code is data, right? It's just because one thinks of it differently and uses it differently that a difference is suggested.

[jjp]

Code is data, right? It's just because one thinks of it differently and uses it differently that a difference is suggested.

One doesn't just think differently of it; the seperation between code and data is built into the OS, CPUs have seperate caches for code and data and so on. The seperation wasn't there from the beginning.. just imagine what kinds of hacks you could do with a C-like language that would allow changing a program's code during execution. And how.. interesting it gets if you want to understand such a program

[madmarx]

To make automatic binding with a scripting language, the source code of one of my project was analysed by DOXYGEN, to create automatically the corresponding .cpp calls. It was half failure because of course, doxy is not perfect, and neither my knowledge of it, but I still think this was a cool way to go.
Anyway, this kind of things has been available for a long time in Virtools (which unfortunately sucks - we call it vircrap at work-), by allowing inside the running program to generate C++ through a scripting language, then clic on "compile", and obtain a new dll that is used as a plugin.

IMO :
1/ nothing new under the sun.
2/ happy debugging.

[Fish]

/me wonders when McSwan's discovery will gain self-awareness, initiate a global takeover of military hardware, launch a nuclear war against humanity, and then order that a scant number of humans be kept alive in order to be used as slave labor.

<shudders>

[kutraj]

Code is data, right? It's just because one thinks of it differently and uses it differently that a difference is suggested.

Well, like jjp mentions, its not just you (the programmer) who thinks of it differently. IIRC, even the early microchips from Intel had this distinction (all though they were stored sequentially and retrieved when using Assembly) The 'program counter' register and a couple of auxiliary registers were responsible for keeping track of what was to be executed and what was to be 'used' for execution. After all, it had 1 byte opcodes and 2 byte data values, and somewhere it had to figure out which was which.

[Klaim]

/me wonders when McSwan's discovery will gain self-awareness, initiate a global takeover of military hardware, launch a nuclear war against humanity, and then order that a scant number of humans be kept alive in order to be used as slave labor.

<shudders>

You mean, used as slave to debug the programs the discovery generated? That's horrible.

[nikki]

Code is data, right? It's just because one thinks of it differently and uses it differently that a difference is suggested.

Well, like jjp mentions, its not just you (the programmer) who thinks of it differently. IIRC, even the early microchips from Intel had this distinction (all though they were stored sequentially and retrieved when using Assembly) The 'program counter' register and a couple of auxiliary registers were responsible for keeping track of what was to be executed and what was to be 'used' for execution. After all, it had 1 byte opcodes and 2 byte data values, and somewhere it had to figure out which was which.

Yeah, but the IP register points to a location in memory, so can't one just take an offset from that pointer and change the instruction pointed to accordingly? It's all in memory anyway. Unless I'm mistaken, both data and code coexist in memory, and take the same form.

Also, instead of using the IP, you could just put a label in code and use that (labels are memory locations anyway, just check an assembler listing file, like 'nasm -l').

I think getting permission to modify the page containing the code in a protected memory model would be pretty simple.

[Kojack]

/me wonders when McSwan's discovery will gain self-awareness, initiate a global takeover of military hardware, launch a nuclear war against humanity, and then order that a scant number of humans be kept alive in order to be used as slave labor.

If you think it's unlikely, consider this: when McSwan and I used to work together, we wrote ai for killer robot tanks. Ok, just classroom exercises, but still, get that into a military robot like this and see what happens:



Although I'm more of a Jailbot fan, now that's how to make a killing machine!
Or a tachikoma (instead of the cliché of robots going on killing sprees when they become self aware, when it happens to a Tachikoma it goes to help a young girl find her lost dog)
Unfortunately (or fortunately) neither are physically possible yet.

[McSwan]

Heya,

I put an old theory of mine into off topic called "Brain Loop Theory and Overlapping Redundancy". I'm still working on my other theory, but thought I'd get your responses on that one in the meantime.

Yup, I wrote an AI tank blaster game with Kojack about 4 years ago? Found out that scripting wasn't quite powerful enough for self coding as it was stuck onto an exe and which couldn't evolve beyond what the exe allowed. Oh well 2 years wasted, and back to the drawing board

However that was the first time I discovered the power of what I call "conditional spam". Every possible distance the tank was a way from an enemy tank, it would constantly update (rewrite) itself with more optimal artillery firing "forces" depending on the distance they were away. Required me to cheat though

Code: Select all

 if(self.DistanceToEnemyTank<=32)then
	  if(self.DistanceToEnemyTank>=30)then
		  FireArtillery(15,26.948246002197)
		  return
	  end
  end
  if(self.DistanceToEnemyTank<=34)then
	  if(self.DistanceToEnemyTank>=32)then
		  FireArtillery(15,27.595956802368)
		  return
	  end
  end
  if(self.DistanceToEnemyTank<=36)then
	  if(self.DistanceToEnemyTank>=34)then
		  FireArtillery(15,28.680084228516)
		  return
	  end
  end
  if(self.DistanceToEnemyTank<=38)then
	  if(self.DistanceToEnemyTank>=36)then
		  FireArtillery(15,29.850040435791)
		  return
	  end
  end
  if(self.DistanceToEnemyTank<=40)then
	  if(self.DistanceToEnemyTank>=38)then
		  FireArtillery(15,32.405464172363)
		  return
	  end
  end


........


  if(self.DistanceToEnemyTank<=190)then
	  if(self.DistanceToEnemyTank>=188)then
		  FireArtillery(15,78.572067260742)
		  return
	  end
  end

  if(self.DistanceToEnemyTank>=190)then
	  FireArtillery(15,80)
	  return
  end

[stoneCold]

I wouldn't be too sure about that. Imagine this thing coming at you with a .50 caliber mounted on top. This is the real deal.

http://www.youtube.com/watch?v=W1czBcnX1Ww

It's weird you mentioned a dog. Watch how it handles the ice. Amazing. "Release the hounds!" The hounds of hell that is.

Kind of spooky, isn't it?!
But I think if they act as clumsy with a .50 cal mounted on top, as they do without it, they rather will shoot themselves (/their fellows) in the feet xD
P.S.: I bet a tenner that they filmed the parts at 0:35 and 1:25 more than once, don't you think so?

[_tommo_]

I wouldn't be too sure about that. Imagine this thing coming at you with a .50 caliber mounted on top. This is the real deal.

http://www.youtube.com/watch?v=W1czBcnX1Ww

It's weird you mentioned a dog. Watch how it handles the ice. Amazing. "Release the hounds!" The hounds of hell that is.

Enjoy.

It's too creepy

Looks like an ill-zombie dog inspired by the Metal Gear... and it was just scary when seen in slow-motion!
Looked and sounded exactly as one of that mini-striders from HL2
Don't know why, but it just disgusts me, as it moves, as it is made... like a big insect...

[Kojack]

Big dog is pretty cool. Here's the newer model: http://www.youtube.com/watch?v=DrmYk_VBelg

I prefer Boston Dynamics (the big dog creators) other robot, the RHex: http://www.youtube.com/watch?v=a0NFrA-Nx4Y
It can handle virtually any terrain (rough ground, stairs, even swim). It would make an awesome mars rover.