If simpletons had attributes then writing a simpleton scheduler is made much simpler. The scheduler could dynamically alter which simpletons are currently active based on which predicates their attributes satisfy just as the simpletons select among entities based on which predicates the entities's attributes satisfy.

The first version of a scheduler needn't do much except watch all the simpletons. Next it might manipulate their thread priorities. Then it might assign threads to simpletons from a thread pool rather than having each simpleton getting a thread for itself. Instead, simpletons would implement some other interface and when their run() method is executed what actually happens is that the next free thread in the thread pool is assigned to execute that run() method, assuming that that simpleton has permission to run then. The scheduler can then alter the priority even of running simpletons on the fly. That way the kernel keeps control of the running of the whole system. One advantage of this scheme is that the system can then be made to run (slowly) even on low-end machines.

Giving simpletons attributes would do away with a simpleton scheduler's need to know the name of a simpleton class. It would be only necessary to search for simpletons that have the requisite attributes. The scheduler could then do the equivalent of calling for all simpletons that are "shaped" to do various things (shaped by having the right attributes). Once assembled they can then be ordered or modified or whatever else the scheduler decides to do with them. That gives us even more freedom to introduce and control arbitrary simpletons at any time.

Giving simpletons attributes just like entities gives us the ability to do sophisticated things. From now on assume that simpletons can have attributes just as entities do. Also assume that there is a simpleton scheduler that can detect those attributes and check predicates defined on them. This leads to some nicely generalized ways of doing arbitrary things.

Scheduler Applications

Suppose the user wants to read mail now. Instead of invoking a separate application, it's only necessary for the system's scheduler to give strong preference to simpletons dedicated to 'mail entities' (that is, entities with the attribute 'personal email'---note that the system may contain email that isn't personal since a webpage could contain an email message, or email messages, as could a news article, and so on). Giving such simpletons priority isn't enough though since the mail also has to be displayed as a cohesive whole, separate from the other chunks of data in the system. The natural and extensible way to do this is to identify all such entities as being in one cluster, and simpletons associated with that cluster (which will be specified in their list of attributes) now have dominance since the user now wants to read or organize or search the collection of personal mail.

Similarly, if the user wants to read news now, one large cluster should be returned (or, rather, should already exist), and within it should be other clusters representing different interest areas. Simpletons who make it their business to know all about news entities would then have dominance.

Say the user wants to search for something now. A simpleton family could be created on the spot to do the search by looking for entities whose attributes satisfy the predicate the user specified. Whatever entities are hit in the search should then be included in the same cluster, even if a cluster has to be created just to hold those entities, because the user may want to search for such a thing again, in which case the cluster can be immediately returned.

To ensure good response to user search requests, the scheduler could simply give high priority to simpletons whose attributes match the current search criteria. Those simpletons would then cascade through the system, temporarily drowning out the other simpletons, then die down once the pool of entities has been thoroughly examined and the search results returned to the user.

Also, the search itself (as opposed to the results of the search) should be stored and analyzed as a separate object inside the system (perhaps as one of the first 'sideband entities') so that all the 'search objects' can be in their own cluster and future simpletons can then be generated to analyze them to derive metainformation about the user's search habits and interests and so on.

There appears to be no limit to the amount of layering of functionality that is possible with this scheme.

A Virtual Machine

If simpletons are entites just as everything else appears to be an entity, then making clusters of simpletons seems like a natural thing to do. If we could link simpletons together then a cluster of such simpletons would have access to one entity at a time and the entity's processing would pass on from simpleton to simpleton simply by the previous one terminating.

This cannot introduce deadlock since the simpletons in the cluster wouldn't be contending for access to the same entity. It would be just like having a giant simpleton with lots of parts that process the entity in stages. The advantages of keeping the simpleton code in separate simpletons are first that it's easier to debug a single simpleton and second that any one of the simpletons in the chain could be a part of some other simpleton cluster (even simultaneously with it being used in the first cluster since the entities it would be working on in the two separate clusters would be different).

We can even divorce the construction of new functionality for the system from Java entirely and make it available through a script language (a simple scheme would work for Simpleton creation, and another, even simpler scheme would work for Entity creation), so even people who don't know Java will be able to alter the system's verbs (simpletons) or nouns (entities). The point of course would be that not only would it open up the space of system "programmers" enormously, but also for those working on the core of the system it would make new functionality even easier to create. They won't even have to code up the class shell around the code they want to specify.

We could then write a "simpleton scripting language" so that people could string together simpletons in clusters with arbitrary logic stitching them together. Some collection of entities (initially we would need just one entity) would be "variables" for such a "program" and the program's "operators" would be whole simpletons. Their actions would be the same as simpletons today: they would examine the entities and alter their attributes (just as program statements can "examine" and "alter" primitives or objects today) and processing of the entities would pass from simpleton to simpleton according to the flow of control of the script just as data passes from statement to statement in any programming language today.

Initially of course this "simpleton language" should be very simple: perhaps allowing just a means to string simpletons together in linear order. Later we can add an "if" test, then a "while" loop, and so on. Note that someone could learn this scripting language and not know Java at all.

From this it is possible to conceive of an entire programming language defined on simpletons such that the simpletons are performing "atomic" actions on entities as specified in the programming language just as statements in Java perform atomic actions on data today.

Script hackers (who develop simpleton application programs to, say, read mail or handle meeting schedules), would then be working on top of simpleton hackers (who alter small parts of the architecture by adding, deleting, or modifying simpletons running on the kernel), who would be working on top of kernel hackers (who make major changes in the architecture by altering its basic structure). Normal users of course would be on top of that whole pyramid, picking and choosing between the various flavors of the system that all this hacking makes possible.

To make all this possible, the system needs a kernel that handles entity management as if entities were blocks of memory and simpleton management as if simpletons were processes. So far we have a little bit of that in place with the datapools, which are the bare beginnings of a 'memory manager'. Next up would be a 'process scheduler' (that is, a simpleton manager). So that you could do things like initiate a major change in the way the program is functioning simply by replicating a family of simpletons (or even just one simpleton). This is just like upping the priority on a process.

This entire superstructure would be one giant virtual machine running in gigabytes of memory distributed on terahertz machines. This system would be an entire programming environment, completely divorced from the underlying language (Java) with its data being large composite chunks (that today we call entities) and its statements being large programming chunks as well (that today we call simpletons). The operating system (say, windows 2005) itself would be far, far below and totally irrelevant to the kinds of things the user could do just as today the processor is far, far below and totally irrelevant to the capabilities the operating system provides the user.

The "desktop" would then be completely malleable, and out of the hands of the large corporations. Anyone, anywhere, would be able to monkey with it.