By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,718 Members | 1,840 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,718 IT Pros & Developers. It's quick & easy.

OOP Language for OS Development

P: n/a
Hi All,
I am developing an object oriented OS code-named "ikbocs".
1) What are the pros and cons of the following languages interms of
Effectiveness on System Programming, Object Orientedness etc ?
(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
I suppose Java is not suitable for Sys. Programming.

2) Which OOP language would be better for OS development?

TIA
KingIshu
Jul 22 '05 #1
Share this Question
Share on Google+
70 Replies


P: n/a
"KingIshu" <ik****@yahoo.com> wrote
Hi All,
I am developing an object oriented OS code-named "ikbocs".
1) What are the pros and cons of the following languages interms of
Effectiveness on System Programming, Object Orientedness etc ?
(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
I suppose Java is not suitable for Sys. Programming.

2) Which OOP language would be better for OS development?


This is off-topic in comp.lang.c++ and very likely in every other newsgroup you
cross-posted to.

Claudio Puviani

P.S.: yawn @ the 3000th kid who says he's writing an OS
Jul 22 '05 #2

P: n/a
KingIshu wrote:
Hi All,
I am developing an object oriented OS code-named "ikbocs". 1) What are the pros and cons of the following languages interms of
Effectiveness on System Programming, Object Orientedness etc ?
(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
I suppose Java is not suitable for Sys. Programming.
Pros for Ada:

Ada has been created for embedded programming and as such is suitable for
system programing.

Ada's representation clauses alow you to specify the pyhsical layout of
*any* datatype. Important for maping hadware interfaces.

Ada's units are based on bit not byte so exotic data types (like 4 bit enums
and 12 bit integers) are handled by the language. No need for complex bit
shifting.

Ada is very strict so many programing mistakes are found at compile time.
Very heplfull since debugging an operating system is quite painfull.

Ada checks for null pointer and protects against buffer overruns as well as
range over- and underruns. No need to add asserts all over the code.

All checks metioned above can be switched off when speed os more important
then robustness.

Ada 95 supports all major OO features as well a generic programing
(templates).
2) Which OOP language would be better for OS development?


Answering that question will only lead to a flame war - so I hope nobody
does.

With Regards

Martin

--
mailto://kr******@users.sourceforge.net
http://www.ada.krischik.com

Jul 22 '05 #3

P: n/a
KingIshu wrote:
Hi All,
I am developing an object oriented OS code-named "ikbocs".
1) What are the pros and cons of the following languages interms of
Effectiveness on System Programming, Object Orientedness etc ?
(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
I suppose Java is not suitable for Sys. Programming.

2) Which OOP language would be better for OS development?

TIA
KingIshu


I'll rephrase this question in terms that won't make the conservative
reactionaries go bonkers. I'm also removing crossposts. Let's ask the
question:

is C++ a good programming language for writing an OS?

I will qualify what I say by informing you that I don't have a lot of hands
on experience with C++.

My answer. Yes. But then I have to go a step further and ask what do you
mean by OS? The only parts of a computing environment that really
constitute the OS are the kernel and the device drivers. Since C++ has all
the low level capabilities of C, then it is clear that you can write and OS
in C++. But now let me share what Linux Torvalds said in 1998 (in terms of
computer technology that's a lifetime ago):

http://www.linuxgazette.com/issue32/rubini.html

Alessandro: "Many people ask why the kernel is written in C instead of C++.
What is your point against using C++ in the kernel? What is the language
you like best, excluding C?"

Linus: "C++ would have allowed us to use certain compiler features that
I would have liked, and it was in fact used for a very short timeperiod
just before releasing Linux-1.0. It turned out to not be very useful, and I
don't think we'll ever end up trying that again, for a few reasons.

"One reason is that C++ simply is a lot more complicated, and the
compiler often does things behind the back of the programmer that aren't at
all obvious when looking at the code locally. Yes, you can avoid features
like virtual classes and avoid these things, but the point is that C++
simply allows a lot that C doesn't allow, and that can make finding the
problems later harder.

"Another reason was related to the above, namely compiler speed and
stability. Because C++ is a more complex language, it also has a propensity
for a lot more compiler bugs and compiles are usually slower. This can be
considered a compiler implementation issue, but the basic complexity of C++
certainly is something that can be objectively considered to be harmful for
kernel development."

You can google up more of Linus's arguments if you like. I'll just say
this. If you are going to write a kernel in C++, you *_must_* know how all
the features you are using are implemented at the hardware level. I've read
enough of the C++ Standard to know you /can/ have very tight control over
things such as memory allocation. My guess is Linus simply hasn't taken the
time to master C++.

If you don't already know C++, you probably need to put off starting your OS
for about 6 months to 2 years while you learn the details under the hood of
C++. BeOS may be worth taking a look at. I don't know how much of their
code is available to the public. I'm also not sure what the balance between
C and C++ is. I'm pretty sure they use both.

Windows NT was originally written in C using Microsoft inhouse extensions to
support OOP. You should find Helen Custer's, now ancient, _Inside Windows
NT_ to be informative reading. I really don't know what MS use for the
kernel of NT these days.

If I were to take on your task, I would probably take an approach similar to
the NT model, but also do thing very differently in a lot of ways. For one,
I would use a Unix model for the file system hierarchy. I would tell you
what I really think of the file system support in NT/XP except my ISP would
probably yank my service.

At the bottom, way down deep, I would have an object with a function in a
running a continuous loop called an event loop. I would represent the
hardware system as an object, and try to find the best way to abstract
services such as file systems, network access, etc. In that respect, I
would probably look to Linux for examples.

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
Jul 22 '05 #4

P: n/a
"KingIshu" <ik****@yahoo.com> wrote in message
news:95**************************@posting.google.c om...
Hi All,
I am developing an object oriented OS code-named "ikbocs".
1) What are the pros and cons of the following languages interms of
Effectiveness on System Programming, Object Orientedness etc ?
(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
I suppose Java is not suitable for Sys. Programming.

2) Which OOP language would be better for OS development?

I 'll talk about C++ which is the language i know about. Both runtime and
space efficiency was one of its design criteria. Abstraction facilities do
not impose additional run-time or space cost than equivalent C-style code.
"It leaves no room for a lower level programming language (except
assembly)".

It supports the OO paradigm, generic programming paradigm (templates),
modular programming paradigm (namespaces) and procedural paradigm. Each
paradigm is supported *well* and with space/run-time efficiency.

Actually those are the reasons that i decided to learn C++ after i learned
C. I think C++ is the best language out there and this not because of
language fanatism.

References:

http://www.research.att.com/~bs/esc99.html
http://www.research.att.com/~bs/bs_faq2.html
http://www.research.att.com/~bs/


Ioannis Vranos

Jul 22 '05 #5

P: n/a
Smalltalk has already been used for building an operating system so you
can either use that as a benchmark showing it can be done, or a reason
to do it in another language to prove it can be done with it as well.

KingIshu wrote:
Hi All,
I am developing an object oriented OS code-named "ikbocs".
1) What are the pros and cons of the following languages interms of
Effectiveness on System Programming, Object Orientedness etc ?
(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
I suppose Java is not suitable for Sys. Programming.

2) Which OOP language would be better for OS development?

TIA
KingIshu


--
..tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
<http://gagne.homedns.org/~tgagne/>
Jul 22 '05 #6

P: n/a
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message
news:c5**********@ulysses.noc.ntua.gr...

I 'll talk about C++ which is the language i know about. Both runtime and
space efficiency was one of its design criteria. Abstraction facilities do
not impose additional run-time or space cost than equivalent C-style code.
"It leaves no room for a lower level programming language (except
assembly)".

It supports the OO paradigm, generic programming paradigm (templates),
modular programming paradigm (namespaces) and procedural paradigm. Each
paradigm is supported *well* and with space/run-time efficiency.

Actually those are the reasons that i decided to learn C++ after i learned
C. I think C++ is the best language out there and this not because of
language fanatism.

References:

http://www.research.att.com/~bs/esc99.html
http://www.research.att.com/~bs/bs_faq2.html
http://www.research.att.com/~bs/


And of course http://www.research.att.com/~bs/bs_faq.html


Ioannis Vranos

Jul 22 '05 #7

P: n/a

"KingIshu" <ik****@yahoo.com> wrote in message
news:95**************************@posting.google.c om...
Hi All,
I am developing an object oriented OS code-named "ikbocs".


You're not going to have to kill me now, are you?
Jul 22 '05 #8

P: n/a

"KingIshu" <ik****@yahoo.com> wrote in message
news:95**************************@posting.google.c om...
Hi All,
I am developing an object oriented OS code-named "ikbocs".
1) What are the pros and cons of the following languages interms of
Effectiveness on System Programming, Object Orientedness etc ?
(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
I suppose Java is not suitable for Sys. Programming.

2) Which OOP language would be better for OS development?


You don't have to use an OO language to develop an OO OS. When I get back
onto my OS project, it will be written in Ada, it will be an OO OS, but it
will not be using tagged types (classes).

You need to define what you want your OS to do first, then decide what
language will help you to achieve this goal. You will need some assembly
language in there, and maybe some other languages may creep in ;-) Who
knows?

Luke.
Jul 22 '05 #9

P: n/a
Claudio Puviani <pu*****@hotmail.com> spoke thus:
P.S.: yawn @ the 3000th kid who says he's writing an OS


Well, you can't really blame people for trying - I mean, women really
gravitate to you when you write an OS. Just ask Linus Torvalds ;)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Jul 22 '05 #10

P: n/a
"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote
Claudio Puviani <pu*****@hotmail.com> spoke thus:
P.S.: yawn @ the 3000th kid who says he's writing an OS


Well, you can't really blame people for trying - I mean, women really
gravitate to you when you write an OS. Just ask Linus Torvalds ;)


So long as it's for reproductive purposes, I suppose I'll let it pass. ;-)

Claudio Puviani
Jul 22 '05 #11

P: n/a
KingIshu wrote:
Hi All,
I am developing an object oriented OS code-named "ikbocs".
1) What are the pros and cons of the following languages interms of
Effectiveness on System Programming, Object Orientedness etc ?
(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
I suppose Java is not suitable for Sys. Programming.

2) Which OOP language would be better for OS development?

TIA
KingIshu


Whichever one you understand the finer points of best.

--
http://barfdader.com
"Beat your children at least once a day; if you don't know why, they do."
-A surprisingly famous guy
Jul 22 '05 #12

P: n/a
> 2) Which OOP language would be better for OS development?

At this point C++ would seem to be the best choice. I don't think any other
language would match C++ in performance and power.

Besides, many operating systems have already been written in C++.

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - System Architecture Design CASE Tool
Jul 22 '05 #13

P: n/a
EventHelix.com wrote:
2) Which OOP language would be better for OS development?
At this point C++ would seem to be the best choice. I don't think any
other language would match C++ in performance and power.


This statement is of corse useless unless you state which progamming
languages you a firm with.

I for example a firm in C++, C, Java, Modula 2, Pascal and Ada and would use
Ada if I ever wanted to write an OS.

You can find the reason for my preference in my other posting.
Besides, many operating systems have already been written in C++.


The question was for quality not quantity. It might well be that there is
the perfect language out there for OS development only nobody ever tried it
out yet.

Besides, where is the fun in doing what everybody else does?

With Regards

Martin

--
mailto://kr******@users.sourceforge.net
http://www.ada.krischik.com

Jul 22 '05 #14

P: n/a
"EventHelix.com" <ev********@hotmail.com> a écrit dans le message de news:56**************************@posting.google.c om...
2) Which OOP language would be better for OS development?


At this point C++ would seem to be the best choice. I don't think any other
language would match C++ in performance and power.

You are certainly free to argue that C++ is a *good* choice, but when you say it is the *best* choice, could you tell over which
languages?

For example, do you know Ada well enough to explain why C++ would be superior?

--
---------------------------------------------------------
J-P. Rosen (ro***@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
Jul 22 '05 #15

P: n/a
"Jean-Pierre Rosen" <ro***@adalog.fr> wrote in message
news:op306c.fjq.ln@skymaster...

You are certainly free to argue that C++ is a *good* choice, but when you say it is the *best* choice, could you tell over which languages?

For example, do you know Ada well enough to explain why C++ would be

superior?
I think that it is happening what the OP intended: A war between
civilizations... There is no better way to start a flame than cross-posting
in different language newsgroups about which is the best language.


Regards,

Ioannis Vranos

Jul 22 '05 #16

P: n/a
EventHelix.com wrote:
At this point C++ would seem to be the best choice. I don't think any other
language would match C++ in performance and power.


Do you at least ever heard of Eiffel? I would say that C++ is far from
matching Eiffel power.

What about performance? If only you have made a single benchmark...

Such assessment is just a flame war start.

Nice day to everybody,

--
Philippe Ribet

The README file said
"Requires Windows 95, NT 4.0, or better."
So... I installed it on Linux!

Jul 22 '05 #17

P: n/a
Ioannis Vranos wrote:
I think that it is happening what the OP intended: A war between
civilizations... There is no better way to start a flame than
cross-posting in different language newsgroups about which is the best
language.


No, KingIshu first question was Ok. He asked for advantages and
disadvantages in respect to OS development. And we are the people to answer
that question. And to discuss the answers.

It would have been better not to ask the 2nd question.

The real problem are answers like the one from EventHelix. He did not state
any specific advantages of C++ just stating C++ is best. This shows great
inexperience in the use of the usenet.

Experienced usenet users will only state the advandages and disadvantages
of there favorite languages and refrain from comenting on other languages.
And saying that one language is best is - indirectly - comenting on other
languages.

With Regards

Martin

--
mailto://kr******@users.sourceforge.net
http://www.ada.krischik.com

Jul 22 '05 #18

P: n/a

"Ioannis Vranos" <iv*@guesswh.at.emails.ru> a écrit dans le message de news:c6***********@ulysses.noc.ntua.gr...
I think that it is happening what the OP intended: A war between
civilizations... There is no better way to start a flame than cross-posting
in different language newsgroups about which is the best language.

Not necessarily wars. Technical discussions are interesting, provided people have a wide enough view.
Note that I didn't say "Ada is superior", I said "please explain why you think that C++ is superior".

And if we refrain from religious argument, a technical discussion about what makes a language appropriate for writing an OS (or
anything else) could be quite interesting.

--
---------------------------------------------------------
J-P. Rosen (ro***@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
Jul 22 '05 #19

P: n/a
In comp.lang.c++ Ioannis Vranos <iv*@guesswh.at.emails.ru> wrote:

(comp.lang.c++ removed from follup-to)
I think that it is happening what the OP intended: A war between
civilizations... There is no better way to start a flame than cross-posting
in different language newsgroups about which is the best language.


Indeed, which is why a) the crossposting to comp.lang.c++ should stop
immediately, if nothing else, and b) I am plonking this thread as of
now.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Jul 22 '05 #20

P: n/a
Philippe Ribet wrote:
EventHelix.com wrote:
At this point C++ would seem to be the best choice. I don't think any
other
language would match C++ in performance and power.

Do you at least ever heard of Eiffel? I would say that C++ is far from
matching Eiffel power.


In terms of "raw power", both languages are Turing powerful (if we
ignore the "can a finite computer be Turing complete" pedentry). So
power in what sense? What's really nice and neat to do in Eiffel that
is difficult in C++? Give some source code, or at the very least a link
to an article.

Can for example Eiffel implement its own allocators, or is its type
system itself Turing complete (C++ templates)?
What about performance? If only you have made a single benchmark...

Such assessment is just a flame war start.

Nice day to everybody,


Jul 22 '05 #21

P: n/a
Calum wrote:
In terms of "raw power", both languages are Turing powerful (if we
ignore the "can a finite computer be Turing complete" pedentry). So
power in what sense? What's really nice and neat to do in Eiffel that
is difficult in C++? Give some source code, or at the very least a link
to an article.


http://burks.bton.ac.uk/burks/language/eiffel/index.htm

---------------------------------------------------------------------
John English | mailto:je@brighton.ac.uk
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
School of Computing Maths & IS | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
---------------------------------------------------------------------

Jul 22 '05 #22

P: n/a
Calum wrote:
Philippe Ribet wrote:
EventHelix.com wrote:
At this point C++ would seem to be the best choice. I don't think any
other
language would match C++ in performance and power.

Do you at least ever heard of Eiffel? I would say that C++ is far from
matching Eiffel power.

In terms of "raw power", both languages are Turing powerful (if we
ignore the "can a finite computer be Turing complete" pedentry). So
power in what sense? What's really nice and neat to do in Eiffel that
is difficult in C++? Give some source code, or at the very least a link
to an article.


It's obvious here that language power means expressivity.
Can for example Eiffel implement its own allocators, or is its type
system itself Turing complete (C++ templates)?


Could you please re-formulate questions about allocators and type
system? I do not understand what you mean, sorry.
--
Philippe Ribet

The README file said
"Requires Windows 95, NT 4.0, or better."
So... I installed it on Linux!

Jul 22 '05 #23

P: n/a
Philippe Ribet wrote:
Calum wrote:
Philippe Ribet wrote:
EventHelix.com wrote:

At this point C++ would seem to be the best choice. I don't think
any other
language would match C++ in performance and power.
Do you at least ever heard of Eiffel? I would say that C++ is far
from matching Eiffel power.


In terms of "raw power", both languages are Turing powerful (if we
ignore the "can a finite computer be Turing complete" pedentry). So
power in what sense? What's really nice and neat to do in Eiffel that
is difficult in C++? Give some source code, or at the very least a
link to an article.

It's obvious here that language power means expressivity.


I am in no doubt that Eiffel is cleaner safer language, however that's
not quite the same as power.

So what can you express in Eiffel that cannot be expressed in C++?
[Actually, resolving name-clashes in multiple inheritance is one,
contracts is another.] But are these fundamentally difficult in C++, or
just a little uglier?
Can for example Eiffel implement its own allocators, or is its type
system itself Turing complete (C++ templates)?

Could you please re-formulate questions about allocators and type
system? I do not understand what you mean, sorry.


C++ allows you to specify where in memory an object resides. This is a
low-level feature that most people would not use, but gives C-like
performance since you can cache-localize data, and implement more
efficient memory managers where you know the allocation patterns.

Are parameterized types in Eiffel as flexible as those in C++?

Jul 22 '05 #24

P: n/a
Calum <ca********@ntlworld.com> wrote in message news:<c6**********@newsg1.svr.pol.co.uk>...

I am in no doubt that Eiffel is cleaner safer language, however that's
not quite the same as power.

So what can you express in Eiffel that cannot be expressed in C++?
[Actually, resolving name-clashes in multiple inheritance is one,
contracts is another.] But are these fundamentally difficult in C++, or
just a little uglier?
Contracting is fundamentally difficult in C++, because adhering to the
inheritance rules of contracting is not easily accomplished. Doing so
requires a lot of preprocessor directives/macros, and makes the code
extremely ugly.

Resolving name clashes in C++ *can* be difficult if there are a lot of
them, and you need to make sweeping changes. Automated search and
replace can help, of course, but may not do everything you need.
Otherwise, it's just flat out ugly in C++.

Eiffel supports selective exporting, covariant argument redefinition,
constrained genericity, and has polymorphism by default without any
added performance penalty. C++ supports none of these. Eiffel also
fully supports the Open Closed Principle, while C++ does not (due to
requirement of virtual keyword and private access limitations). None
of these issues really affect the choice about whether one can develop
an OS with them or not.

Are parameterized types in Eiffel as flexible as those in C++?


Not really. Eiffel supports constrained genericity, but it does not
support expression templates like C++ does. Of course, expression
templates are really a side-effect in C++, as they were not part of
the original intention. They are great for performance and expressive
power, but they are damn ugly. :-)

Steve
Jul 22 '05 #25

P: n/a
Steven Wurster wrote:
Eiffel supports covariant argument redefinition


Which is a huge mistake, since it menas that one can
no longer supply a derived class to something which
expects a base class.
Jul 22 '05 #26

P: n/a
In comp.lang.ada Calum <ca********@ntlworld.com> wrote:

: I am in no doubt that Eiffel is cleaner safer language, however that's
: not quite the same as power.
:
: So what can you express in Eiffel that cannot be expressed in C++?
: [Actually, resolving name-clashes in multiple inheritance is one,
: contracts is another.] But are these fundamentally difficult in C++, or
: just a little uglier?

How would you write "once" routines in C++?
How about the fine grained visibility control (where each feature
can be made visible to only a specified set of types)?

:
:>> Can for example Eiffel implement its own allocators, or is its type
:>> system itself Turing complete (C++ templates)?
:>
:>
:> Could you please re-formulate questions about allocators and type
:> system? I do not understand what you mean, sorry.
:
: C++ allows you to specify where in memory an object resides. This is a
: low-level feature that most people would not use, but gives C-like
: performance since you can cache-localize data, and implement more
: efficient memory managers where you know the allocation patterns.
:
: Are parameterized types in Eiffel as flexible as those in C++?

They are different I think. Can you express

deferred class C [P -> T]
feature foo(x: P): P is deferred end
end -- C

in C++?

Then there is currently a (justified) limitation in C++ with
float parameters. This is not the case in Ada generics.

georg
Jul 22 '05 #27

P: n/a
Georg Bauhaus wrote:
How would you write "once" routines in C++?
With a static method containing a static value, of course.

class UponATime
{
static double Once(/* args */)
{
static double value = /* some calculation */;
return value;
}
};

It appears from my looking up what once functions do,
that arguments to the call are irrelevant for determining
whether it should be re-executed. If so, that's another
example of a hideous language design choice made by Eiffel.
How about the fine grained visibility control (where each feature
can be made visible to only a specified set of types)?
Speaking of hideous design decisions. This whole concept
of classes having fine-grained dictatorial control over
whom they allow access to their innards is more than a
little silly.
They are different I think. Can you express
deferred class C [P -> T]
feature foo(x: P): P is deferred end
end -- C
in C++?


Sure. You just don't define the method, and if it gets used,
the linker will complain. Or if it's virtual, then you can
make it abstract.

template <typename T>
struct C
{
T foo(T x);
virtual T bar(T x) = 0;
};
Jul 22 '05 #28

P: n/a
In comp.lang.ada Hyman Rosen <hy*****@mail.com> wrote:
: Georg Bauhaus wrote:
:> How would you write "once" routines in C++?
:
: With a static method containing a static value, of course.

So in the general case where the method will have (side)
effects on object variables I use an if (once) {...} with a
static bool once, I guess? Whatever suggests the necessity
of ONCE in a language, if it is necessary then being able
to write ONCE might have an advantage in my view.

:> They are different I think. Can you express
:> deferred class C [P -> T]
:> feature foo(x: P): P is deferred end
:> end -- C
:> in C++?
:
: Sure. You just don't define the method, and if it gets used,
: the linker will complain.

So the compiler, compiling seperately, will not know which types
can be passed to some_C.foo before the linker is run.

Jul 22 '05 #29

P: n/a
Georg Bauhaus wrote:
So in the general case where the method will have (side)
effects on object variables I use an if (once) {...} with a
static bool once, I guess?
What do you mean? A static variable in a function is initialized
the first time control passes through the declarartion, and never
again. So my code is equivalent to your ONCE method - the first
time the function is called, the variable will be initialized, so
you can plant all of the code you want to execute once as part of
that initialization. After that, no matter how many times you call
the function, the initialization code won't be executed.
Whatever suggests the necessity of ONCE in a language, if it is
necessary then being able to write ONCE might have an advantage
in my view.
*Shrug* I'm not thrilled with a language feature which allows the
compiler to replace a call to f(2) with an earlier call to f(1),
but maybe that's just me. Ada allows you to decorate a function
with Pragma Pure, and then it can elide multiple calls to a function
if it is called with the same parameters (regardless of whether the
function has side effects).
So the compiler, compiling seperately, will not know which types
can be passed to some_C.foo before the linker is run.


In C++, there is no some_C.foo. There is a some_C<T>.foo for each
type T that some_C is instantiated with. Each one is a logically
separate function, and they have nothing to do with each other.
Jul 22 '05 #30

P: n/a
Hyman Rosen:
Steven Wurster:
Eiffel supports covariant argument redefinition


Which is a huge mistake, since it menas that one can
no longer supply a derived class to something which
expects a base class.


Either I don't understand your post or you are mistaken. If the
derived class conforms to (inherits from) the parameter's type then
there is no problem.

Brian
Jul 22 '05 #31

P: n/a
Brian_Heilig wrote:
Either I don't understand your post or you are mistaken. If the
derived class conforms to (inherits from) the parameter's type then
there is no problem.


In Eiffel, Derived::Foo(Derived) overrides Base::Foo(Base).
That means that if you have a Base object, and you call
some_base_reference.Foo(some_other_base_reference) , the call
looks correct, but if some_base_reference is really a Derived
and some_other_base_reference is not a Derived, you have an
error.

It's a horrible misfeature, but its proponents cling to it
tenaciously, and they have spent years trying to figure out
workarounds so that the errors can be caught.
Jul 22 '05 #32

P: n/a
Hyman Rosen <hy*****@mail.com> wrote in message news:<10***************@master.nyc.kbcfp.com>...
Georg Bauhaus wrote:
How would you write "once" routines in C++?
With a static method containing a static value, of course.

class UponATime
{
static double Once(/* args */)
{
static double value = /* some calculation */;
return value;
}
};


You are nowhere near the expressivity of once routines:
1. The body of `Once' will be executed with each call except for the
stuff after the static declaration. In other words, you must put all
of your calculation behind the equal sign!
2. You still need once per thread, once per object, and manual once
functions.
It appears from my looking up what once functions do,
that arguments to the call are irrelevant for determining
whether it should be re-executed. If so, that's another
example of a hideous language design choice made by Eiffel.
This is of course a consequence of your misunderstanding of once
functions.
How about the fine grained visibility control (where each feature
can be made visible to only a specified set of types)?


Speaking of hideous design decisions. This whole concept
of classes having fine-grained dictatorial control over
whom they allow access to their innards is more than a
little silly.


You're funny.
template <typename T>
struct C
{
T foo(T x);
virtual T bar(T x) = 0;
};


You missed the constrained generic parameter. G -> T means that G is
the generic type and it must conform to T. I don't think C++ templates
can emulate constrained generics yet, but I could be wrong.

C++ will never reach the expressive power of Eiffel, but then again,
you can't make an Eiffel compiler solve factorials, so maybe you win?

Brian
Jul 22 '05 #33

P: n/a
Hyman Rosen <hy*****@mail.com> wrote in message news:<10***************@master.nyc.kbcfp.com>...
Steven Wurster wrote:
Eiffel supports covariant argument redefinition


Which is a huge mistake, since it menas that one can
no longer supply a derived class to something which
expects a base class.


That's not true. I've done it plenty of times in Eiffel, even with
covariant redefinition. Redefinition isn't necessary, but is
supported. In fact, in many cases, it's the best solution.

Let's get off this language holy war argument.
Jul 22 '05 #34

P: n/a
Hyman Rosen <hy*****@mail.com> wrote in message news:<10***************@master.nyc.kbcfp.com>...

It appears from my looking up what once functions do,
that arguments to the call are irrelevant for determining
whether it should be re-executed. If so, that's another
example of a hideous language design choice made by Eiffel.
Explain why. Don't just say it's 'hideous' without giving rationale.

Speaking of hideous design decisions. This whole concept
of classes having fine-grained dictatorial control over
whom they allow access to their innards is more than a
little silly.


Why? You need to provide your reason for your opinion. Selective
exporting is way ahead of the public/protected/private of C++ and
Java. A good example is the visitor design pattern, in which the
visit routines should only be available to the accepting classes.
This is easily done using selective exports in Eiffel. But in C++ one
must either make the routines public, which violates encapsulation, or
make *every* accepting class a friend, which violates information
hiding and requires a lot of programmer bookkeeping.

Steve
Jul 22 '05 #35

P: n/a
ik****@yahoo.com (KingIshu) wrote in message news:<95**************************@posting.google. com>...
Hi All,
I am developing an object oriented OS code-named "ikbocs".
1) What are the pros and cons of the following languages interms of
Effectiveness on System Programming, Object Orientedness etc ?
(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
I suppose Java is not suitable for Sys. Programming.

2) Which OOP language would be better for OS development?

TIA
KingIshu


Eiffel Pros:
Design by Contract - a process and a language, Design by Contract
defines things like software correctness, software errors, and
exceptions like no other method. Integration into the language
dramatically helps with documentation and debugging. Many other
reasons why DbC alone puts Eiffel near the top of the list. No problem
with buffer overruns in Eiffel (the number one security risk in
operating systems), thanks to DbC.
Tight language design - all language features can be traced back to
about 10 basic principles. Eiffel has been systematically designed as
a language making it concise, easy to learn and easy to use.
Strict type system - operating systems require secure and correct
code. With Eiffel you'll catch more bugs at compile time. This strict
system makes it more difficult to design your code, but the benefit
greatly outweighs the increased effort.

Eiffel Cons (related to OSes):
There is no turnkey Eiffel compiler for you to use for operating
systems. All the current compilers are system-oriented, that is, they
generate systems, which for example have command-line arguments and
garbage collectors. Unless I'm mistaken this is probably the show
stopper.
I'm pretty sure it is impossible to write an entire OS completely in
Eiffel. Number one reason, Eiffel has no method for declaring
interrupt handlers. The good news is that Eiffel integrates with other
languages easily (C for example which has an interrupt keyword).
If efficiency is your number one priority Eiffel may not be for you.
SmartEiffel and ISE Eiffel generate very efficient code, but I don't
think it meets the demands of a CPU scheduler, for example.

Brian
Jul 22 '05 #36

P: n/a
In comp.lang.eiffel Hyman Rosen <hy*****@mail.com> wrote:

: What do you mean? A static variable in a function is initialized
: the first time control passes through the declarartion, and never
: again. So my code is equivalent to your ONCE method -

O.K., though that will require another non-local private function?

Jul 22 '05 #37

P: n/a
On Fri, 23 Apr 2004 18:33:05 -0400, Hyman Rosen <hy*****@mail.com>
wrote:
Brian_Heilig wrote:
Either I don't understand your post or you are mistaken. If the
derived class conforms to (inherits from) the parameter's type then
there is no problem.


In Eiffel, Derived::Foo(Derived) overrides Base::Foo(Base).
That means that if you have a Base object, and you call
some_base_reference.Foo(some_other_base_reference ), the call
looks correct, but if some_base_reference is really a Derived
and some_other_base_reference is not a Derived, you have an
error.

It's a horrible misfeature, but its proponents cling to it
tenaciously, and they have spent years trying to figure out
workarounds so that the errors can be caught.


It's an LSP violation. Code written to deal with base classes can be
broken by new derivatives that can't accept the arguments that the
base can. This makes it hard to follow the Open Closed Principle
which says that you should try to make modules extensible without
having to change them.

-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
Jul 22 '05 #38

P: n/a
Steven Wurster posted:
Calum <ca********@ntlworld.com> wrote in message
news:<c6**********@newsg1.svr.pol.co.uk>...

I am in no doubt that Eiffel is cleaner safer language, however that's not quite the same as power.

So what can you express in Eiffel that cannot be expressed in C++?
[Actually, resolving name-clashes in multiple inheritance is one,
contracts is another.] But are these fundamentally difficult in C++, or just a little uglier?
Contracting is fundamentally difficult in C++, because adhering to

the inheritance rules of contracting is not easily accomplished. Doing so requires a lot of preprocessor directives/macros, and makes the code extremely ugly.

Resolving name clashes in C++ *can* be difficult if there are a lot of them, and you need to make sweeping changes. Automated search and
replace can help, of course, but may not do everything you need.
Otherwise, it's just flat out ugly in C++.

Eiffel supports selective exporting, covariant argument redefinition, constrained genericity, and has polymorphism by default without any
added performance penalty. C++ supports none of these. Eiffel also fully supports the Open Closed Principle, while C++ does not (due to requirement of virtual keyword and private access limitations). None of these issues really affect the choice about whether one can develop an OS with them or not.

Are parameterized types in Eiffel as flexible as those in C++?
Not really. Eiffel supports constrained genericity, but it does

not support expression templates like C++ does. Of course, expression
templates are really a side-effect in C++, as they were not part of
the original intention. They are great for performance and expressive power, but they are damn ugly. :-)

Steve

Why the hell would you want automatic polymorphism? There's times
when I want functions NOT to be polymorphic!

-JKop
Jul 22 '05 #39

P: n/a
Hyman Rosen wrote:
In Eiffel, Derived::Foo(Derived) overrides Base::Foo(Base).
That means that if you have a Base object, and you call
some_base_reference.Foo(some_other_base_reference) , the call
looks correct, but if some_base_reference is really a Derived
and some_other_base_reference is not a Derived, you have an
error. Your first statement is incorrect. You can decide whether it's
Derived::Foo (Derived) or Derived::Foo (Base). If you do implement the
former, you will indeed get an error. If you implement the latter, no
errors are generated.

Could you provide a scenario where you would need to have both the base
and derived class existing in the program, and you would need to
implement Derived::Foo (Derived) overriding Base::Foo (Base)?

It's a horrible misfeature, but its proponents cling to it
tenaciously, and they have spent years trying to figure out
workarounds so that the errors can be caught.


Those are some interesting allegations. Do you have any references which
support your claims?
Jul 22 '05 #40

P: n/a
JKop <NU**@NULL.NULL> wrote in message news:<XH******************@news.indigo.ie>...
Why the hell would you want automatic polymorphism? There's times
when I want functions NOT to be polymorphic!

-JKop


If the polymorphism is determined automatically, you don't need to
plug "virtual" keywords everywhere, and you don't need to spend any
time guessing as to which function should be allowed to be
polymorphic. Also, by determining this automatically, the Eiffel
compiler can optimize calls to eliminate polymorphism where it's not
needed. This is something that would be very difficult or impossible
for a C++ compiler to accomplish. If you know you don't want a
function to be polymorphic, then in Eiffel you declare it frozen.

Greg C
Jul 22 '05 #41

P: n/a
Back to the original question...

I would expect there's conflicting demands on the operating system and
consequently the language it's written in. It is presumably responsible
for interfacing directly with hardware, and must provide suitable
abstractions for anything that might be attached to it.

At the same time, the operating system must play host to applications
written for it, and it doesn't make sense to me that the OS should place
restrictions on application languages--though it could turn the tables.

In today's popular operating systems the lower-level a language you are
the greater advantage you have over higher-level languages. If the
operating system were written in an OOL that normally requires a virtual
machine then that VM would be more native (or natural, perhaps) to other
OOLs that could use the same VM. Low level languages would have to run
inside their own VM because the low-level operations might not be
available to them. Imagine writing a C program that didn't run as fast
as a Java program because the C program had to run inside a VM on top
the OS!

Of course, that may not be required. But let's look at two languages on
opposite sides of the spectrum--C and Smalltalk.

If the OS was written in Smalltalk then its imaginable the natural
instructions might be Smalltalk's. Would C programs be compiled into
Smalltalk opcodes? That would be interesting. Imagine if such a thing
were successful then chip manufacturers could begin developing chips to
make the VM run faster as was suggested by Alan Kay years ago:
<http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html#coda>

"Hardware is really just software crystallized early. It is there to
make program schemes run as efficiently as possible. But far too
often the hardware has been presented as a given and it is up to
software designers to make it appear reasonable. This has caused
low-level techniques and excessive optimization to hold back
progress in program design. As Bob Barton used to say: "Systems
programmers are high priests of a low cult."

"One way to think about progress in software is that a lot of it has
been about finding ways to /late-bind/, then waging campaigns to
convince manufacturers to build the ideas into hardware. Early
hardware had wired programs and parameters; random access memory was
a scheme to late-bind them. Looping and indexing used to be done by
address modification in storage; index registers were a way to
late-bind. Over the years software designers have found ways to
late-bind the locations of computations--this led to base/bounds
registers, segment relocation, page MMUs, migratory processes, and
so forth. Time-sharing was held back for years because it was
"inefficient"-- but the manufacturers wouldn't put MMUs on the
machines, universities had to do it themselves! Recursion late-binds
parameters to procedures, but it took years to get even rudimentary
stack mechanisms into CPUs. Most machines still have no support for
dynamic allocation and garbage collection and so forth. In short,
most hardware designs today are just re-optimizations of moribund
architectures."

Perhaps it's time for such a thing to be attempted. If done well enough
it could be the proof that late-binding is something much-needed in
operating system and not just their applications.

wrote:
Hi All,
I am developing an object oriented OS code-named "ikbocs".
1) What are the pros and cons of the following languages interms of
Effectiveness on System Programming, Object Orientedness etc ?
(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
I suppose Java is not suitable for Sys. Programming.

2) Which OOP language would be better for OS development?

TIA
KingIshu


--
..tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
<http://gagne.homedns.org/~tgagne/>
Jul 22 '05 #42

P: n/a
JKop <NU**@NULL.NULL> wrote in message news:<XH******************@news.indigo.ie>...

Why the hell would you want automatic polymorphism? There's times
when I want functions NOT to be polymorphic!


Automatic polymorphism is needed to support the Open Closed Principle.
But it can be turned off in Eiffel by declaring a routine as frozen.
Similar to final in Java, which also has automatic polymorphism.

Oh, and, nice attitude.
Jul 22 '05 #43

P: n/a
Robert C. Martin <un******@objectmentor.com> wrote in message news:<cn********************************@4ax.com>. ..

It's an LSP violation. Code written to deal with base classes can be
broken by new derivatives that can't accept the arguments that the
base can. This makes it hard to follow the Open Closed Principle
which says that you should try to make modules extensible without
having to change them.


Remember that it's not required for a descendant class to covariantly
redefine arguments in Eiffel. It is an option, however. And, yes,
doing it can lead to problems. In fact, we have a name for it in
Eiffel. It's called a CATcall, where CAT stands Changing Availability
or Type. That is, where a descendant routine either changes its
availability (i.e. becomes less visible) or its argument types. The
Eiffel community knows about this, and knows how to deal with it.
And, no, a compiler cannot reasonably detect where CATcalls lead to
LSP violations.

But, I'd rather use Eiffel with that 'hole' than languages that have
less power and less support for the OCP, among their other faults.

Steve
Jul 22 '05 #44

P: n/a
Thomas Gagné wrote:
Perhaps it's time for such a thing to be attempted.


Intel 432, Symbolics Lisp machines, probably a host of others.
Such things have been attempted, and are now consigned to the
ash heaps of history.

It should be obvious why. When you have good, fast general
purpose hardware, you can implement all sorts of cockamamie
ideas on it, and if something doesn't work out, you can try
something else. When you start implementing those ideas in
hardware and they don't work out, you're left with a useless
boat anchor.
Jul 22 '05 #45

P: n/a
Anthony Weissenberger wrote:
Hyman Rosen wrote:
In Eiffel, Derived::Foo(Derived) overrides Base::Foo(Base).
Your first statement is incorrect. You can decide whether it's
Derived::Foo (Derived) or Derived::Foo (Base). If you do implement the
former, you will indeed get an error. If you implement the latter, no
errors are generated.


So what's your point? All OO languages let you do the latter.
But only Eiffel allows the former, and it indeed can cause errors
at runtime. What exactly do you think is incorrect about what I said?
Could you provide a scenario where you would need to have both the base
and derived class existing in the program, and you would need to
implement Derived::Foo (Derived) overriding Base::Foo (Base)?
Beats me. Ask the Eiffel guys, since it's their theory.
Do you have any references which support your claims?


Sure. <http://www2.inf.ethz.ch/~meyer/ongoing/covariance/recast.pdf>
is a paper with Bertrand Meyer as one of the coauthors, dated 2003,
in which they are still talking about how to get compilers to do safe
covariance.
Jul 22 '05 #46

P: n/a
Georg Bauhaus wrote:
O.K., though that will require another non-local private function?


It could, if that code was complicated enough.
It all just turns into a static boolean anyway,
either explicit or by the compiler. If Eiffel
wants to nominate it into a first-class language
feature, bully for it.

Jul 22 '05 #47

P: n/a
Steven Wurster wrote:
Explain why. Don't just say it's 'hideous' without giving rationale.
If I see code which says 'f(1) + f(2)' I would be very surprised to
hear that the compiler was tossing out the f(2) and just reusing the
f(1). It's not that you can't do the same thing in C++ using statics,
but having it as a language feature just strikes me as weird. At least
Ada does it right, by only eliding calls with the same arguments for
Pure methods.
Why? You need to provide your reason for your opinion. Selective
exporting is way ahead of the public/protected/private of C++ and
Java.


It's only ahead if you think that such hiding is valuable and necessary.
I think some people have made a religion of it, and they need to stop
thinking of their code as some sacred virgin who must be defended from
the impure advances of everyone else's code, and just get the work done.
The world isn't going to end if someone gets to fiddle around with the
private bits.
Jul 22 '05 #48

P: n/a
Brian_Heilig wrote:
You missed the constrained generic parameter. G -> T means that G is
the generic type and it must conform to T. I don't think C++ templates
can emulate constrained generics yet, but I could be wrong.
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 template happens to work for
some class that doesn't conform to T, why should it be prevented from doing
so?
C++ will never reach the expressive power of Eiffel, but then again,
you can't make an Eiffel compiler solve factorials, so maybe you win?


Yeah, whatever.
Jul 22 '05 #49

P: n/a
On 24 Apr 2004 18:25:38 -0700, st***********@lycos.com (Steven
Wurster) wrote:
But, I'd rather use Eiffel with that 'hole' than languages that have
less power and less support for the OCP, among their other faults.


I completely understand that point of view.

-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
Jul 22 '05 #50

70 Replies

This discussion thread is closed

Replies have been disabled for this discussion.