Re: Writing an Operating System in Ada

[Shark8 <onewingedshark@gmail.com>]

> > Interact with other systems? You know, you might want to sometimes
> > move your "persistent objects" to another machine.
>
> Marshaling? In terms of ADT it is assignment. Create a local object of the
> type. Assign the remote object to it. Done.
>
> Provided you have the assignment defined.

What happens when the network is disrupted in the middle of an
assignment though? Is the assignment atomic? If it's a large store of
data is it resumable, or does having a large file on a flaky server
doom you to never being able to retrieve the data?

> > Did I mention that you might want to move you whole hard drive to
> > another machine as well? :-)
>
> Did you try? What happens with a NTFS drive in a Linux system? Can you
> mount it as an ext4?

Ah, here you're confusing "is a" and "has a" because the drive itself
is NOT a file_system, but it may have one [or a part of one]. You can
think of the file system as a format-for-the-data. So, like some
people have done with compression/encryption and made an abstract base
to derive from we can do the same with file-systems.

> This is not a question of objects or raw blocks. If the OS recognizes the
> pluggable component, there is no problem,

Nope. The OS can detect a perfect & compatible drive and yet be
mystified by its contents because it doesn't understand how to read
it. If the drive is a dictionary, the entries are the particular files/
directories/objects thereon, but it is pretty useless to give someone
a dictionary in a language they can't read.

> if it does not there is a
> problem. Nothing prevents a portable design of persistent storage.

You are correct. And that is what a file-system IS. The design of [a
method] for persistent storage.

> Note that the file system itself is built on a layer of blocks and sectors.
> So if your argument worked, there would be no need for a file system. We
> would still read sectors and count drive heads...

Oh please don't say that the best way to reference disk-data is by
(sector, block) direct access... I'd prefer to have my hardware a
little more intelligent than that, and have my CPU available for
things other than calculating location-offsets.

>
> > There is a reason why none of the pure-OO-OS-let's-do-it-correctly
> > ever really took off.
>
> Yes. There are many reasons. For all there is no consistently designed
> OOPL, Ada included.

Ada is one of the most consistently designed languages I've come
across {LISP is another}, so if your argument is valid it should be
more doable in such language[s] than in other languages.

> Without MI, MD, tagged tasks, there is no chance to get
> it right.

If by MI you mean multiple inheritance I think the Java/Delphi/Ada2005
interfaces handle that pretty well.
If MD is multiple dispatch then we're talking about something that
simply explodes combinatorically-speaking: Say we have a multi-
dispatch procedure with two dispatching parameters [Letter and
Number], ok? Now, if we have two versions of each of those in the
classes we get something like:
(A,1)
(A,2)
(B,1)
(B,2)

Now let's say we extend our families of letters and numbers by a
single item we get the following:

(A,1)
(A,2)
(A,3)
(B,1)
(B,2)
(B,3)
(C,1)
(C,2)
(C,3)

And each of these instances must be defined because we have no way to
restrict invalid combinations, and if we don't restrict invalid
combinations we quickly run into huge data-sets that are [mostly]
worthless. If multi-dispatch were sorting it's somewhat akin to having
bubble-sort be your only method of sorting. We don't have efficient/
proper techniques for dealing with it.

> In long
> term perspective we sooner or later will be forced to use computing
> resources more efficiently.

Indeed, I completely agree. Which is actually the reason I named my OS
after the Commodore; if we could have the same 'wow' level of
effectiveness & efficiency given current hardware as they did then, I
believe that we would have normal-people absolutely astounded at what
their computer could do.