This is the one first example that came to mind, down in '91, when thinking about my own "New System". At the time, I didn't mean to revolutionize anything, but just to tackle my growing dissatisfaction about existing computing systems.
The problem was to design a simple system which would help me manage a database of my own collection of classical music compact disks, that would allow me to do more than what I could do by just looking at the well-ordered shelf where the disks lie.
So I started to imagine what useful things the computer could (and thus eventually should) do to help me with my CD collection: of course, I should be able to make listings, to select entries and sort the database according to arbitrary criteria; but I'd also have to be able to communicate simply with other people, to enter names in whichever language they really are, to automatically link entries to external resources, to share my appreciations with others, or use it as the basis for biased random selection of a disk to listen; I'd like to ultimately know the main tune from each track, and perhaps even to retrieve a disk according to a tune in my mind.
After a while, I realized how such things were not just impossible, but inconceivable even at any reasonable cost in existing systems. Then, I understood that my project would be more than an enhanced toy project, but truely a revolution in the way computing is thought about. As Carl Sagan said much later,
"To make an apple pie from scratch,
you must first create the universe",
which fits perfectly the situation I found: to write my small piece of personally useful software, I'd have to first make a whole computing system.
When I had to choose a name for what this project became, I remembered this old CD database, and it was part of my choice for the name "Tunes". Therefore it could be said that the TUNES project began with this CD database idea.
In this document, we tell how a TUNES user, F, who never read the paper docs, but knows the general principles of TUNES computing, and how to use on-line help, will try to build a system to catalog all the CD's and tapes in his own personal collection.
This database should eventually allow him to do just anything one does manually that could be automated, and even things one couldn't do manually, that can be done automatically:
This may seem an ambitious project, but why shouldn't it be possible? We'll prove that it is, and show how the techniques proposed in the TUNES project allow do it incrementally, just the way a human actually thinks about things when designing a database, through automatic rewrite of the database as the structure evolves.
This document describes an interaction between a TUNES user, who will be refered to as F, and the TUNES system.
The TUNES system will dynamically divide into objects during the session. In this document, objects will be refered to by the list of names or code numbers that were successively attributed to subobjects to reach the object from the topmost user-visible one:
These objects communicate with the human user, and with each other, which will be denoted by a sequence with the message originator, followed by an arrow, followed by the message recipient, followed by a colon, followed by the message contents, e.g.
() -> aa.1.xx : "how are you ?".
For ease of reading and writing, the objects will more than often be replaced by some higher object in the accessibility hierarchy. Particularly, many objects will remain hidden behind the topmost () object.
How those messages are actually passed is not in this paper's scope. The TUNES User Interface should manage the interaction between computer objects and the human, while other meta-protocols decide how objects communicate one to the other.
.....
.....
In this chapter, we saw how TUNES allowed the user to create the database using the same tools as he uses everyday. He didn't have to learn a new procedure for just this case.
You may have noticed that we didn't specify how exactly the messages were passed between the user and the system or between different subsystem. Actually, the user could have personalized his way to communicate with the system to fit his taste. If he didn't, he would have used the same standard way as was provided by the system developper and programmers of the tools he uses. Keyboard and Text screen, point-and-click interface and graphical screens, voice recognition and synthesis, or any conceivable means are acceptable.
For example, the newly created object would not really be given a name 1, but on a graphical screen, a subwindow of a visible stack window may be its "name", that the user refers to by pointing with a mouse, while the system uses whatever ad-hoc pointing convention internally.
Changing the object's name might be dragging the visual representation of the object into another persistent store than the default one, with would then prompt for a textual name, give a default one, or again have it be implicit until defined.
All this is only a suggestion about how interaction could be done, for how it is really done constitutes a topic completely independant from managing a CD database. See the Interfaces subproject for more about it.
Important points which are not yet integrated:
The metaclass of (1) is the "data base": it has many fields of information. For the moment, regard the base as having only one list of elements, an empty list, and its elements being of the Empty type (2.1).
(Remark: the system opens the list all the same so that the user doesn't have to do it, based on the unlikelihood that the user cares about the actual list itself.)
Remark:(1) knows that this order will not modify the organization of its data, but (or perhaps "and therefore") integrated this change.
Remark: There be a type "Name of Person", but F it have not see in the list. Perhaps have it not take the trouble to consult this long list, or have it not know restrict this list with type connect with character strings, and let it drown under the mass of type available. Choose the more familiar, but also the more primitive.
Remark: F. returned only the name of the authors, not their first names.
As we see, a database is not a fixed structure; even it's "type" evolves. Database means that the computer integrates knowledge, and allows the human to access it. Knowledge is due to evolve unpredictably (see Karl Popper's works about this); no static structure can restrict it. That's why no static database structure can dynamically satisfy the human's needs.
Now what of all the data already entered? In traditional database systems, it would be lost, or the user would have to write some very complicated program to statically translate it from the old structure to the new one. TUNES won't let you down like that. It will automatically generate and apply the translating some function when needed, so the database is extended with all the existing data preserved.
The structure of the database can get completely rewritten, not just extended, so as to reflect deep changes while still conserving all the existing data.
Rewrite is done by default in a reversible way, so that errors can be undone trivially, and rewrite be done again in better ways.
Optimizing is a special case of directed rewrite that conserves the semantics.
Up to now, we have focussed on logical structures; now that these are settled, we may think about their physical (well, lower level) representation: to begin with, manual enhancements. Then, automatical optimization:
In existing systems, you must give the low-level details of the database implementation right from the beginning, at a time when you have only a faint idea of what will be the actual manipulations users will do on the database, and the time constraints they will induce. Then, you cannot modify this implementation without having to rewrite a great lot of the database plus translators. It is impossible to test multiple implementations and choose the best one. Thus, however "optimizing" (according to completely arbitrary criteria), the existing databases are much slower than they could (hence should) be. TUNES solves this problem: optimizing is just some kind of performance-directed rewrite.
The user can integrate music-playing and later music-recognition software to his database.
In this chapter, we saw that integration in TUNES was not just a matter of a uniform interface, with some hack to have coarse-grained low-level applications communicate between each other, as in leading commercial operating systems, but simple and deep concept of fine-grained higher-order modularity. The consequences are that little technicity is required to customize a system, so large teams with lots of boring and stubborn docs are no longer needed to maintain and extend software, and people are no longer taken hostages by large corporations and specialized vendors: if one is not willing or able to learn the small amount of technicity required, one can easily find a qualified technician, and needs not abide by the diktats of monopolistic providers.
music pieces:
There would be some global CD database, everyone managing the CDs one has, with some system to merge/cross-reference diverging versions of entries. One's collection would just be a list of which CDs one has. CDs could also be let and the manager remember who borrowed what. One could publish his entries, but One has all control on the way his entries are updated from globally published sources (so that one won't be helpless victim of viruses), particularly when it comes to destructive updates and structural updates.
Now we can sell this piece of software to companies selling music recordings as the finest possible database system ;-)
Eventually, add support for tune-directed browsing (e.g. you whistle the tune, and a tune-recognition system finds the piece, then the right tracks on the right CDs, and perhaps even the right second in the track!). This way, music lovers can walk their CD collection (or a CD library) easily, or play games about recognizing tunes, CD publishers can interactively advertise their products, copyright managers can check piracy more easily.
This is the miracle of TUNES: there is continuous progress between a personal hack and a globally useful publishing system. People can really reuse what they or other did, and really contribute to global welfare.
Existing database systems require your designing in advance the full structure of the database, with no possibility to correct, amend or enhance it whatsoever. That's why they are so bad.
Again, all this is the same one problem that arises everywhere in computing: one has to choose between a static design or a dynamical system. Statism may be expedient if you have a one simple problem to solve immediately, but only dynamism is truely useful in the long run, where problems ever evolve and grow in complexity. All companies sadly seem to have chosen statism and expediency, as they live in the short term by their local interest. Tunes is a Useful, Not Expedient, System, hence chooses dynamism and utility.
This is truely part of the moral fight of clairvoyance against narrow-mindedness. TUNES is an ethical project in the computing world, which is why it shall overcome eventually. To help it is to help you as well as the whole world. Please help yourself, please help us. The first and simplest way to help is to tell us how we are erring if you see that we are, so we can correct our views and be useful when we would have been harmful.