Moose specs: Revision 0!

[Gary D. Duzan]

=> Well, I've read your first specifications. I must agree with most of it, as
=>you explained how to take the best from the intel 386 processor to build an
=>operating system. But I think your mixing up the 386 implementation with the
=>system itself.
=> If we are to rewrite a system (and moreover, if it is to be ported to many
=>platforms, including 680x0 based computers), we musn't define it frome
=>its particular implementation on machines we have mainly because of economica
l
=>issues. I think we must define the system from high-level, and then use the
=>hardware the best we can to implement it; else, we will have a DOS-like
=>hardware-level system, which we will have either to abandon or to be
=>compatible with when we will want to improve it.

   I couldn't agree more. If portability is a goal, then we can't build
the design around the features of a particular architecture. We need to
look at concepts first and link them to methodologies later, though we
would so well to keep in mind the capabilities of modern architectures
in general. But then, you can hardly blame Dennis. After all, he works
for Intel. :-)

=> DOS is directly programmed with 8088 assmebly language; Unix is programmed
=>with C; MacOS is OO styled programmed with Pascal. In every case, the system
=>and the language are thought together, and each adapted to the other.
=> It will be the same with MOOSE. Whatever language you choose to program
=>with (I mean high-level stuff, not the Kernel, which is bound to be mainly
=>done in assembly), it with shape your system. If you don't choose any
=>language, the default will be assembly, and you'll be as unportable and
=>unimprovable as DOS. If you choose C, you won't do better than U*ix. Perhaps
=>C++ can do better, but it inherits much from C low-level philosophy, and
=>won't give you a clean high-level OO system.

   True, but what can we do? If we can get a compiler for a good
object-oriented language that will compile on a number of different
machine, that would be great, but not, I think, too likely. I suppose
we could try to get a number of language/compiler design people to whip
up a language and GCC front-end for us to use if we really wanted to,
or maybe use an existing language and develop a GCC front-end for it. I
hate to say it, but C++ looks like the way to go for now. As long as we
specify the interfaces and abide by them, we should be able to make it
language-independant. It might be a good idea to develop a Smalltalk
interface in parallel.

=> To conclude, I think we mustn't rush doing what would be the kernel of a
=>system whose features aren't defined yet. Let's define the high-level object
=>orientation of the system before we write the kernel (more precisely, let's
=>not write something in the kernel we should have to change completely because
=>it will not fit high-level system requirements).

   Agreed. And likewise, let's not design high-level facilities that
are natural on one platform but aren't easily implemented on others.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts