OOP Language for OS Development

[Martin Krischik]

Philippe Ribet...

So you could, for example, write the really low level stuff in
assembly, write the bulk of the OS in Eiffel, and then use CECIL to
bridge the two? What I'm asking is, if you were writing an OS in
Eiffel, is that what you might do?

I think the option was Assembly -> C -> Eiffel.

If that's all it takes then I highly recommend Eiffel for OS
development. The more I think about it the better it sounds.

Well Eiffel is not the only language which would allow this strategie. You
could do the same with the gcc Ada compiler. My hope is that the OP will
now choose a language apart c/c++ for his OS development.

With Regards

Martin

 

[Brian_Heilig]

Martin Krischik...

I think the option was Assembly -> C -> Eiffel.

CECIL = C Eiffel Call in Library. CECIL is the bridge between C code
and Eiffel code.

Well Eiffel is not the only language which would allow this strategie. You
could do the same with the gcc Ada compiler. My hope is that the OP will
now choose a language apart c/c++ for his OS development.

Right, but I believe Eiffel is the best choice except for the
potential risks I mentioned in the parent post. Philippe has helped to
alleviate many of those concerns. In particular SmartEiffel can be
used to compile non-system code. At first I thought Eiffel was the
best language solution, but had some practical barriers. Now I see
that those practical barriers are on par with other popular languages.

Brian

 

[Peter Hermann]

Right, but I believe Eiffel is the best choice except for the

a proprietary language can never be a "best choice", IMHO.

 

[Steven Wurster]

a proprietary language can never be a "best choice", IMHO.

As I'm sure others will tell you before it shows up on my newsreader,
Eiffel is not a proprietary language. It's controlled by a non-profit
consortium (NICE), and is undergoing ECMA standardization. It is true
that the extensions that ISE implements in their products tend to get
added to the language proper.

Java, on the other hand, is proprietary. It's controlled by Sun,
unless something else has changed recently. And I believe people are
developing OSs with that language.

Steve

 

[Richard Riehle]

That's more related to multi-threading. Which Eiffel can do, and there
is even a SCOOP version of SmartEiffel.

Is there a currently working version of SCOOP? What platform?

Richard Riehle

 

[Dr Chaos]

They sort-of can, because there are ways to do the checks at compile time,
but no one really cares. Most C++ folks consider it a mistake to try to
limit generic parameters in this way, because it limits the usability of
templates for absolutely no reason.

If the programmer puts it there, usually there is a reason.

If the template happens to work for
some class that doesn't conform to T, why should it be prevented from doing
so?

At some point, C programmers learned many years ago that

*( (OhWhatTheFuck*) p) = whatever;

can often seem clever, but is not wise.

Yeah, whatever.

Eiffel doesn't REQUIRE the type constraint.

 

[Berend de Boer]

Richard> Is there a currently working version of SCOOP? What
Richard> platform?

Yes, for SmartEiffel, Linux pthreads:

http://cs.anu.edu.au/~Richard.Walker/eiffel/scoop/

--
Regards,

Berend.

** you're welcome to the #eiffel irc channel on irc.freenode.net

 

[Ged]

[...]
If the template happens to work for
some class that doesn't conform to T, why should it be prevented from doing
so?

Because in Eiffel its all about the contract.

When the interface accepts paramaters to conform to T the objects
author is taking on a responsibility to ensure that the feature will
always accept a paramater that conforms to T. The compiler will do
everything it can to help the author meet that commitment.

This means that when the author of another objects uses this object,
he can make sure that he meets the type requirements expressed in the
interface and then move on.

The contract works for both the programmers. The client programmer
can be confident that future updates to the library are not going to
break his code. The library programmer can be update code confident
that he will not cause any damage to his clients.

This extra effort helps to avoid situations like this one,
http://www.kuro5hin.org/story/2004/2/15/11942/2702, where Microsoft
developers are forced to code around the dependancy that Borland had
upon a bug.

In summary, you have at least 3 levels:

- Should always work.
- Happens to works now, but may change.
- Does not work.

The middle grey area can be a source of future problems, and should be
avoided. This is why somebody should be prevented from doing
something that happens to work.

Of course, how much benefit you attach to this all depends upon the
domain you work within. For some it is essential, for others it is
nuisance.

 

[=?ISO-8859-1?Q?Thomas_Gagn=E9?=]

[...]
If the template happens to work for
some class that doesn't conform to T, why should it be prevented from doing
so?

Because in Eiffel its all about the contract.

When the interface accepts paramaters to conform to T the objects
author is taking on a responsibility to ensure that the feature will
always accept a paramater that conforms to T. The compiler will do
everything it can to help the author meet that commitment.

What' the difference between that and any other statically type-checked
language? Does the compiler remember what the programmer said the type
was and complain if they change it?

 

[Ged]

[...]
If the template happens to work for
some class that doesn't conform to T, why should it be prevented from doing
so?

Because in Eiffel its all about the contract.

When the interface accepts paramaters to conform to T the objects
author is taking on a responsibility to ensure that the feature will
always accept a paramater that conforms to T. The compiler will do
everything it can to help the author meet that commitment.

What' the difference between that and any other statically type-checked
language? Does the compiler remember what the programmer said the type
was and complain if they change it?

The original question was 'If the template happens to work [...] why
should it be prevented from doing so?'

The key difference between Eiffel and other statically type-checked
languages is design by contract, explicitly distinguishing between
'correct use' and 'what happens to work.' If the pre-conditions are
met, then the post conditions are guaranteed.

Of course, the compiler cannot enforce all of this. However, it can
provide a lot of support.