1. Uniformity must be very pervasive, providing the
deep consistency that allows large bodies to be efficiently built from small
ones. What must be uniform? Anything that comes into contact with something
else. In particular we need:9/24/99 - Jack Harich - First Draft
| It turns out the ultimate goal of frameworks is not higher reuse as we know it. The following is difficult to explain clearly and is awkwardly presented. Please bear with us on these breakthrough ideas. |
System federations have structure. A large body of systems must be a semi-structured collection (a web or network, not a tree or list which is way too limiting) to more closely reflect its mission. Individual systems can be trees, bags, lists, webs or any suitable structure. Systems perform the role cells do in life - They are the basic building blocks for large functionality. They work mostly independently. Each has its own mission. The network of system connections is the federation structure. The sum of the system missions allows a federation mission.
Each system has uniform sense points. The interface to each system must be at multiple points. Otherwise the system cannot respond fast or flexibly enough. Those interface points need a set of uniform protocols. For example the sense points can use TCP/IP, JINI, Messages and Datatrons, and be reusable via DK, allowing sufficient different types of points.
The role of frameworks is to provide enough uniformity to have "SoftLife", which consists of many collaborating systems working toward mutually beneficial goals. This is the logical result of Metcalfe's Law, which states that the total value of a network is proportional to the number of subscribers. A certain magical threshold is crossed when the systems are doing the job better than other life forms, such as humans, and the systems are gratefully acknowledged as SoftLife. The prime role of frameworks is NOT to provide higher reuse or make development easier. That is early, antiquated, Amoebic Age thinking. :-)
(We're getting a little excited here. This is NOT the only role for frameworks! :-)
The minimal requirements for SoftLife are standard protocols. However without the uniformity frameworks provide, SoftLife is limited to crudeness like amoebas, bacteria and slime molds. Call this the Amoebic Age of Software. That's where we are today - It's all we can do to lurch forward with blobs of independent systems that are a bear to get to collaborate. It's impossible to get thousands of such systems to work together towards common goals, though we are seeing the beginnings of this in the www. Every new system is mostly hacked out from scratch each time.
Given the above, we see that SoftLife frameworks must provide Uniformity, Building, Replication, Controlled Evolution and Mobility. The latter ones all depend on Uniformity.
1. Uniformity must be very pervasive, providing the
deep consistency that allows large bodies to be efficiently built from small
ones. What must be uniform? Anything that comes into contact with something
else. In particular we need:
2. Building is the act of creating the large from
the small. In the case of SoftLife, building includes the ability to start from
the most compact representations possible. The three types of things needed
are Declarative Knowledge (DK, aka genetic information), builders and workers.
Given the DK for a system, a small set of builders can build the many types
of workers (even other builders) whose behavior is the system. Note we start
from the primordialness of just DK and builders. Currently requirements serve
as the DK, humans play most of the builder role, and the workers are programs,
connected in innumerable odd and silly ways. Building includes renewal, such
as repair and replacement.
3. Replication is required to create one federation
from another, one system from another or one system element (a part) from another.
Otherwise learned behavior, state and/or composition cannot be transmitted cleanly
or at all, and we start from square one each time. Also, creation from scratch
is much slower than replication of existing elements, and is fraught with error
and waste. Without replication completely different architectures are required,
and SoftLife becomes impossible to achieve.
4. Controlled Evolution allows something to control
the construction or refinement of systems. This allows faster, safer and more
appropriate results than Random Evolution. For example:
5. Mobility is needed to move federations, systems
and parts to where they are needed. Greater mobility is an outstanding advantage
animals tend to have over plants, the Air Force over the Army, adults over screaming
babies, cars over duck blinds, etc. Examples in SoftLife are:
We now have a bit of fun, and examine four approaches to building systems with behavior.
One can see how we're on a logical progression from Current Software Development to The BA to SoftLife, using Mother Nature as the guiding master.
When I sketched this out in my notebook on the evening of 9/22/99, I was struck by how easy it was to find the pattern involved. Popping it into Visio the next morning, it clarified even more into the "plugpoints" the pattern seems to offer. This was all very striking, and gives me the confidence we are on the right, but long, trail.
The SoftLife diagram is merely speculative. We really don't know exactly how the yellow and green areas (and Code Generators) would look. But it would be something like this, with the same pattern strategy as the others, particularaly Mother Nature. The important issue is that SoftLife is not a huge jump from The BA version - It's just an incremental step. This should give us the confidence it can be done, because it looks downright difficult until we've done it. :-)
One insight from these diagrams is it seems that software technology is converging on a distinct, tried-and-true pattern that has been there all along - the System Builder Pattern. This pattern allows something to very efficiently build systems with desired behavior from Declarative Knowledge and materials. (Is this pattern name sufficiently distinct?)
Declarative Knowledge (DK) is "what to do" as opposed to "how to do it". It is the key to the entire pattern. The pattern has five main plugpoints.
The system itself is an emergent property, since it consists of all of this. It is not just the Workers, because a mature system can replicate itself, repair itself, adapt itself and grow. For this it needs all five things. Mature examples of this pattern are self referential.
If a pattern is deep, it has widespread applicability. So naturally we looked to see if it appeared anywhere else. In a few minutes we came up with these two pattern examples. This confirms reasonably correct pattern identification. Again, note how all five things are required for the running system, not just the "output".
Presently when a computer starts up, it essentially builds a running organism from a set of lifeless forms such as files and chips. These mechanisms are completely different from what we are shooting for with SoftLife.
SoftLife will be reached when we have systems that cannot be "turned off", because they cannot be recreated from lifeless forms. There is something of value in a SoftLife preventing recreation from non-life. (Just what is it? :-) Thus "life comes from life", which is completely different from "systems come from programs, data and hardware". SoftLife requires very special "LifeWorks", not frameworks.
Actually we foresee loose stages, because all this is so difficult:
As these stages progress, we have a hybrid continuum. At first, all workers are handmade. These are known as parts today. Then we figure out how to use DK and Builder Parts to create some Worker Parts, such as by code generation, or empty or skelton worker configuration. We now have hybrid systems of handmade and DK/Builder made behavior. Then we get so good at Builders the handmade parts disappear, and we are left with Workers created from DK and Builders. Then the role of humans will be designing DK and creating/improving Builders. Way down the road systems will become able to do this better than we can.
As you can see, we are talking about very large, complex life forms that often span computers. This will lead to SoftLife behaviors that are not yet fathomable, including how we react, what our roles become and where our cultures go.
Working backwards from visions like this, we can design today's frameworks to take us there one small step at a time....
We now return you to normality and the Amoebic Age. :-)
We are indebted to the fantasitc book "The Way Life Works" by Hoagland and Dodson. In it a scientist teams up with an artist to pictorally explain the complexities of biology, in a way this is fun, thought provoking and informative. A similar book that goes even further in other areas is "Ultimate Visual Dictionary of Science" from DK Publishing.
We are also indebted to Steve Alexander for introducing me to the concepts of "emergent property" and "self referential". Thanks!
This is all an alternative or supplement to phases 5 and up on the UHR Technology Grid.
Our purpose is to use some of the abstractions that work so well in biology, not to try to reproduce life itself. We also use some concepts from electronics (devices and datatrons) but these details are not involveded here.
Another term for "SoftLife" is "LifeWare". Hmmmmmm....