(A rendered version of this document is available here.)
This project is to computers what computers are to calculating by hand on paper, but to a less extent.
This project's envisionned final product is a computer program P that is an interactive tutorial for (re)creating P from scratch. But more importantly, helps recreate significant variations of P.
Now let's step back and unpack that. See how we arrive at this, what exactly it is and history of this project.
Instead of flying cars, we got computers and the internet. Which let us distribute information through channels like blogs. What would previously need large teams and infrastructure can now be done by a single person or small group, but its usage is seen as a skill, with technology that enabled as a almost forgotten backdrop.
Improving our tooling is less flashy but much more efficient. Funding such projects can improve the success probability of 100s of other projects and allow the existence of many more. But it'd be years from initial prototype to market-wide adoption.
Furthermore, if this project will be completed, finishing it sooner rather than later will help out many more projects.
Currently, to create a new computer program, you would survey existing programs, library and programming languages, pick ones that are "close" to the new program in mind and try to create your program from them.
If the new program is randomly chosen within the space of all possible computer programs (say any string that compiles in your favourite language), it is unlikely any of these is of use at all! And the resources needed to create this new program is huge.
This has a reverse effect where new programs are selected to be close enough to existing ones to be creatable with less effort and then new programmer's thinking shaped to only "want" these nearby programs.
So how can we make programs that help make programs that are vastly different? The answer is this project. Because P is a tutorial for recreating itself, it is copied not as source code but as ideas, each one of which can be reshapen to suit the destination program. This makes P as reusable as possible.
Ok, but what's a non self-referential description of this program P?
As a simplified concrete example, imagine a slide deck with instructions on them to recreate the slides using the slide editor ("click new project", "new slide", "add a text field", "type in the title", etc). But the slides also has instructions to recreate the slide editor itself (to then be used to create the slides). And instruction to recreate the libraries used to make the slide editor. And also the programming language used to write the libraries.
For an even more concrete (but also more oversimplified) top few layers, see How to Make These Slides.
With the general idea in our mind, here are the actual envisioned components of the project and their properties. (This part gets a bit technical so feel free to skip it and watch these videos that showcase some individual aspects of the project: video 1, video 2.)
A quine is a computer program that prints its own source code when run. They are a curiosity with no applications that I know of. This project is made up of multiple generalizations of quines, nested into one another (mostly). Each one is made using the previous ones.
We'd like to design the components to be answer "what is the most useful thing we can make to help create a future unknown computer program (in the space of all possible programs)?"
The main property is of course, self reference and blurring the editor/edited boundary so there's no distinction between improving the editor and making the final product. Ideally, we'll take the "improve the editor" action all the way through. Though in reality the components and their boundaries will still be very visible.
Although the any part of the program is ultimately modifiable through its recreation, each part will be made as dynamic and runtime modifiable as possible so that small changes can be tested out quickly and interactively.
The entire project will minimize total internal complexity since any extra piece will will lengthen the tutorial needed in the end. We have to make sure not to add too many "features" unless it helps the creation or editing process. Since the tutorial is for recreating the whole thing, we need to minimize complexity at each later.
Although not strictly needed, we also want to minimize the total complexity of external tools used, such as compilers and interpreters (that we didn't write) for running our programs. This mainly so that we don't stuff complexity into those tools.
This project is already underway, using my own time and savings. My blog details some of the progress.
Anything about future work is of course speculative and better routes may be discovered.
Aside from creating the remaining components (or recreating some in the right places), design challenges periodically arise when delving into the details. For example, a current difficulty is the the running sppeed of the program (and how to improve that while still keeping low internal complexity).
Please email all questions to: asrp email com (add @ and . in the appropriate places).