One step at a time

[Soma]

Lynn H. Maxson wrote:
> Like several others on this mailing list I have
> pursued a project on my own that parallels Tunes.
> I, too, want "...to replace existing Operating
> Systems, Languages, and User Interfaces by a
> completely rethought Computing System...".  After
> that point we start to differ in priorities.  For
> example at the end of this quote comes "...yet
> (eventually) a highly-performant set of dynamic
> compilation tools...".  This implies a shift in
> "system" priorities, a consideration of features
> separate from their implementation.

Here Here.

I am kind of responding to Jecel's email here too. I feel the rethink is
neccessary because we are looking at a 40 year history of software
development which got many things wrong (which need no longer be the case
now but mostly still is), and like any great artifice, the most important
bricks are at the bottom.

And it's true: an operating system is not a thing in itself, rather it is a
platfrom from which to build applications, and applications are what sell
computers. Many of the members of the list probably have some application
they imagine sitting on top of their desired operating system.

My own idea is that the killer app of the first part of the 21st century is
natural language. The main purpose I envisage for the system I am dreaming
up is a system in which everything arbitrary can be changed dynamically.
Rather than try and invent a language, like tunes is, I feel the way forward
is to allow the user to define their own language, where you can program the
computer with something like what we presently call pseudocode. This
language system need not be textual, however, I have seen visual programming
systems, and they make programming so simple.

So I guess my project is aiming at blowing open development to the common
user. If you have a piece of software, and you want it to do something
differently, I feel that you should be able to tell the system so, and that
through a question/answer dialogue the computer figures out what you mean by
you explaining and elaborating until it understands what you intend.

Then for the money side of it: applications will get built for this system,
and the OS comes free with it.

As every one knows, the OS market is now defunct pretty much, so in line
with that, the system I am building, the "os" part, is going to be as bare
as possible. I am using an 'exokernel' model, and just yesterday decided
that the best way to program it is with a bytecode dynamic
translation/interpretation system, because that allows one to jump platforms
much easier - only device interfaces and executive kernels need to be
tailored to hardware, which reduces the porting workload. This has been
demonstrated with Tao OS, and I recently encountered a macintosh Oberon
system which used a dynamic translation system to handle the two different
mac hardwares.
    I decided on this path after looking at x86 assembler - it's memory
addressing system is such an ancient retrofit, even the one on the 386 and
above. I am used to 68000 assembler, but the 68k system doesn't make you use
the mmu system just to look at a stupid 64k block. I am of the view that the
need to protect applications from each other shows a shortcoming on
conventional operating systems in the development systems used to write
applications.
    The problem is that the programming models in common use are at least
ten years old. I used to own an amiga computer, and it did multi-tasking
without any memory protection, If an application has bad memory usage
patterns it needs to be fixed. The cost of protecting the system from these
kinds of errors should be on the development side, and ideally the compiler
should know how to make sure that programs stay within their memory
allocations.

I guess I don't really have to build my system from scratch, but there is a
number of reasons why I want to: the database/linking system that it will
use I want to be orthogonally persistent, and I also want to implement a
filing system that is tuned to the database's way of doing things. The
reason for using a bytecode translation system is that I prefer to program
in assembler for the high efficiency. However I fully intend that once I
develop the base platform (it's kind of like a LibOS on top of an exokernel)
that the system be able to re-compile itself, and even change all the
assembly language into english.

So I guess the killer app I am aiming for is a totally open, extensible
system development system, which can be taught to understand any new
language, and can be redefined as circumstances require. It is about time
that computer programmers stop reinventing wheels.

My 2c

Soma