Re: Writing an Operating System in Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 14 Jan 2010 01:40:57 -0800 (PST), Maciej Sobczak wrote:

> On 13 Sty, 10:17, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> 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.
> 
> What remote object? I just plugged in my USB stick or spun the DVD in
> the drive.

You said you wanted to move an object.

> If you want to see a "remote object" in this operation, you will have
> to somehow instruct the system that the "remote object" is the one
> which is on USB. In which case there is no point in having it
> (unnecessary step) as you might just as well instruct the system that
> your *local* object should be constructed from what is on the drive,
> by perhaps providing the file name.

I.e. you don't want to move it... (:-))

> Which is exactly what we have today.
> 
> The high-level OO abstraction still has to hit the bare metal at some
> point, which only shows that it does not solve any problem, only moves
> it elsewhere.

Absolutely. Also no programming language solves anything about that. In the
end it is the p-n-p transistors which do the job. What is the point?

>>> Did I mention that you might want to move you whole hard drive to
>>> another machine as well? :-)
>>
>> Did you try?
> 
> Sure, my USB stick works fine.

Because it has FAT, which is supported.

>> What happens with a NTFS drive in a Linux system?
> 
> I have no idea since I do not have any NTFS drives around. :-)
> 
> But I do not see how the OO approach would solve that problem. Plug
> the OO-aware drive from the OO-aware system from Microsoft into your
> OO-aware system of choice and you will be in the same mess.

Sure. But your argument was that a file system would handle it better. It
does not.

> Again, no problem solved.

Yes, the only solution of the problem is to write some code. You can write
it in assembler, C, Ada etc. But the code must be written. So the problem
is how do we write the code, and not whether there should be some.

> (because the problem of compatibility is in standardization, not in
> paradigm)

Standards reduce the number of variants to support. But note that the
standards themselves are influenced by the state of the art. Consider POSIX
as an example. If there were no UNIX, the standard would be very different.

>> But the major problem is lack of any interest, since the market
>> of operating system was burnt down to the ground.
> 
> Or maybe the problem is that people try to perceive any given paradigm
> as a silver bullet for solving all problems.

No. It is because people tend to buy only silver bullets. So whatever you
sell, you better do it as such.

> I do not think that OO is
> one (and I though the industry came to this conclusion some 15 years
> ago already).

Yep.

> Personally, I'm not even sure if I would like to use the OS that was
> made pure-OO from the ground up in all possible aspects. Some paradigm
> flexibility is needed to find optimal solutions in different
> situations and that cannot be achieved if a single idea is driving
> everything.

What is the opposite paradigm? I don't care much about OO, I do about ADT.
The real alternatives are typed vs untyped. I think we have been using the
latter for too long and it won't stand up safety and quality requirements
of future omnipresent computing.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de