> I would suggest that most of what we want already exists in pieces,
> and that it's a matter of creating the core and interaction standards
> that let them work together. I wonder if that's called an operating system?
> I hope the problem isn't that large.
Unfortunately, it is.
An operating system does essentially what you suggest, and the reason
they are as easy to develop as they are (which is still none too easy)
is that the only data types they have to worry about are bytes and
files. In UNIX, everything is a byte stream (files, sockets, arrays,
devices). In the system you envision, there may be several hundred
data types, times many variations on those types.
Now, we can develop a language to work on such a variety of types;
an interpreted language and environment like LISP or Smalltalk.
It would be suitable for prototyping, but what about real work?
You see, I've come to believe that the concept of prototyping is a red
herring. Working software is too valuable to throw it away to start
over again to develop the "real thing", so what begins as a
"prototype" often becomes the "real thing" after an identity
transformation. As soon as the prototype is perceived to be useful,
it's not a prototype any more. So I resist the separation of
prototyping from development of real products or doing real work.
What may serve the need is a distributed software environment in which
component capabilities run as separate programs, perhaps on different
coputer systems. The components are built using a large, shared class
library that defines the data types used by all the components. This
class library defines the gaming table; you have to ante up (by learning
how to use the big class library) in order to be allowed to play.
The components interact via the network. The operation of the components
is controlled by another distributed component that does *not* need to be
built from the large class library, but rather simply communicates
instructions to the computational components. These would include
data manipulation instructions like "Ask *that* component to send you
its third image" as well as computational instructions like "Take the FFT
of your second image".
I have a small working version of such a thing now, and it looks
really sweet.
- --
Dr. James M. Coggins
Associate Professor & Associate Chairman for Academic Affairs
Department of Computer Science E: coggins@cs.unc.edu
University of North Carolina V: 919-962-1738 F: 919-962-1799
Chapel Hill, NC 27599-3175 W: http://www.cs.unc.edu/~coggins/
------- End of forwarded message -------