Prism Rationale, Part 1
Mon, 04 Jan 1999 21:36:58 -0700
I haven't received any responses to my Prism announcement, so I thought
I'd go ahead and explain a little more of what Prism's about. (Of
course, it's only been one day, but I'm not the patient type. :) )
Prism stemmed from concepts similar to some of the ones being tossed
around on the Tunes list now, so that's why I'm bothering you all with
this stuff. If you want me to shut up and go away, let me know. :)
Prism Rationale, part 1:
Give Me A Little History
(But Skip the War Heroes, Please)
A couple of years ago, I started working on an object-oriented OS I
called "Sphere". It was going to be cross-platform, use concurrent
objects, and support automatic persistence and garbage collection. Its
goals were to be stable, secure, and easy to use and develop for. Ease
of development was the reason for the persistence, garbage collection,
and concurrent objects.
That went on for about a year and a half. I created several
specifications for it (which are still available on the Sphere web site
-- http://www.teleport.com/~sphere -- look in the document map under
"Inactive Projects") and actually got to the point where I was ready to
start writing code.
That's when I ran into a brick wall. Not because I couldn't write the
code, but because I wanted to use my object-oriented paradigm throughout
the system, and I was having trouble figuring out how to transition from
the world of objects to the world of bits.
Struggling with this issue made me rather introspective. I started
asking myself questions: Why am I doing this? (Because I want a
concurrent object-oriented operating system.) Why do I want that?
(Because it's better than what's currently available.) Why is it
better? (Because it's concurrent and object-oriented throughout.) So
what? (So it's easier to program, so less bugs.) Why is that?
(Because it's consistently object-oriented.) What makes
object-orientation so good? (Because... uh......)
This line of thought led me to several unanswered questions. What's so
great about object-oriented programming? What's the philosophy behind
programming in general? Why do some languages result in more buggy
programs, and others result in less?
--> If I'm going to create a programmable operating system, what's going
to make it any better or worse than everything else? <--
At this point, I wrote an essay, "Requirements for a New Programmable
System." It's also available on the Sphere web site, but it basically
boiled down to "Ease the creation of programs, and increase the range of
programs which may be created." Okay, not exactly rocket science. But
the requirements weren't bad:
[To increase the ease of creating programs]:
1) Reduce the number of semantic expressions required to solve a
2) Create semantic rules which reduce the number of semantic fallacies
which may be expressed.
3) Create a syntax in which each syntactic expression clearly relates to
a specific set of semantic expressions.
4) Create a syntax which reduces the number of syntactic errors which
may inadvertently be introduced.
5) Reduce the amount of physical work (keystrokes, hole punches [don't
ask :) ], etc.) required to syntactically create a semantic expression.
[To increase the range of programs which may be created]:
6) Increase the number of semantic actions
7) Create semantic rules which increase the variety of possible semantic
Keep in mind that I'm not necessarily talking about Turing-equivalent
systems, which is why the second batch of requirements is in there,
although I must admit I think the first set is a lot more insightful...
particularly numbers one and two.
So, anybody still with me?
Hmmm... thought not. Oh well, that's okay. I like shouting into the
thankless and unforgiving void. ;)
Anyway, on March 17th, 1998, I set forth this rather interesting list of
requirements. Then, on March 21st, I found the mother lode -- The
Solution to the Software Crisis.
Well, not really. But it's an important concept nonetheless. It's also
* Semantic errors may be reduced by using a programmable system whose
semantics are as close as possible to the semantics of the problem
And thus was born Paradigm-Independent Software Engineering. I spent
the rest of the year refining the theory, and in the process I created
Prism, a paradigm-independent programmable system. (Actually, it was
really the other way around, but it sounds better this way.)
If anybody got this far, let me know and I'll send you a virtual
lollipop. :) Next time, I'll describe Paradigm-Independent Software
Engineering in more detail, and describe how Prism fits in. Or you can
just go to the Sphere web site and read about it there, although it
won't be nearly as poorly written. ;)
Jim Little (firstname.lastname@example.org)