comparing object-oriented platforms
Matt Wu
I'm currently evaluating several object-oriented development platforms
and I was wondering if any of you would like to share your opinions on
platforms that you prefer or know about. It'd be especially useful to hear
comparisons between different platforms (for instance, Eiffel v. Smalltalk).
So, for any evangelists out there, this is your chance. All replies will be
welcome. The hardware platforms that I'm using are principally the Macintosh
(under system 7), MS Windows 3.1 and NeXT Step 3.0. My most immediate concern,
though, is to find something for the Mac, so any information regarding that
platform will be especially appreciated.
Thanks,
John Nagle
>I'm currently evaluating several object-oriented development platforms
>and I was wondering if any of you would like to share your opinions on
>platforms that you prefer or know about. It'd be especially useful to hear
>comparisons between different platforms (for instance, Eiffel v. Smalltalk).
The language situation is roughly as follows:
Ada Big, no inheritance, some tools expensive but do
exist. Many books on language available. Many
free libraries available. DoD standard.
C++ Big, multiple versions of language, unsafe.
Tools widely available. Many books available.
Most popular choice.
Modula-2 No classes or inheritance. Many books.
Many implementations. Solid, but limited.
Modula-3 Limited interest - one free compiler, one book.
Adds classes to Modula-2. Less used than
Modula-2.
Eiffel Limited interest - one or two compilers, one book.
Less used than Smalltalk, C++, Ada, or Modula-2.
Smalltalk Slow execution, good tools. Multiple books
available. Clean language. Good for experimental
work. Avoid pure-interpreted versions if speed
at all important.
Ole Lehrmann Madsen
The Mjolner BETA System is available for Macintosh under system 7,
and with MPW. For information send e-mail to
>Thanks,
>Matt
>m...@orion.oac.uci.edu
Ole Lehrmann Madsen
olma...@daimi.aau.dk
Stefan Monnier
object-orient.. John Na...@netcom.com (1174)
I didn't know that Ada and Modula-2 were object-oriented !
Then from the remaining:
C++: very successfull but unsafe, that's true, lacks a
garbage collector. But very good environements available!
Modula-3: much less success: lacks a bit of consistency, I think
limited interest in general (don't realy know for the
available environment)
Smalltalk: not always that slow, excellent environment !
Eiffel: not that uninteresting: clean, powerful, I would say
it is state of the art in strongly typed OOL. The ISE
environment is quite decent (I heard the version 3.0 is
even good)
Personnally, I don't like C++ much (mainly cause of it's lack of GC)
Between smalltalk and eiffel, it's a question of taste: do you like
strong static typing or prefer dynamic typing ?
I really think the smalltalk environment is excellent, much better
than what I know for eiffel, but the strictness of eiffel makes it
really nice to debug !
I prefer Eiffel, cause it's faster and I much more used to it !
The rest is question of taste !
Maybe you prefer other OOL, like Self, simula, CLOS or...
CLOS may be a good choice, but I just don't know it yet !
Stefan Monnier
-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
Bill Maniatty
|> Excerpts from netnews.comp.lang.eiffel: 26-Sep-92 Re: comparing
|> object-orient.. John Na...@netcom.com (1174)
|>
|> > m...@orion.oac.uci.edu (Matt Wu) writes:
|> > >I'm currently evaluating several object-oriented development platforms
|> > >and I was wondering if any of you would like to share your opinions on
|> > >platforms that you prefer or know about. It'd be especially useful to hear
|> > >comparisons between different platforms (for instance, Eiffel v. Smalltalk).
[Stuff Deleted]
|> > Eiffel Limited interest - one or two compilers, one book.
|> > Less used than Smalltalk, C++, Ada, or Modula-2.
[More Stuff Deleted]
|> Eiffel: not that uninteresting: clean, powerful, I would say
|> it is state of the art in strongly typed OOL. The ISE
|> environment is quite decent (I heard the version 3.0 is
|> even good)
I'm interested in Operating Systems, and Massively Parallel architectures.
Just how can these techniques be applied to these areas. Consider Kernel
level programming. A strongly typed language with strong support for reuse
of software should make for a better kernel implementation and design.
On the flip side, I'm under the impression that real time programming cannot be
done with a Garbage Collecting language, as the garbage collection could
happen at an arbitrary time, and cause a violation of the timing constraints.
And I wonder just how well the Eiffel assertion checking could handle parallel
computations? Can I get a win by using Eiffel to do these sorts of things,
and if so, how?
|>
|> Personnally, I don't like C++ much (mainly cause of it's lack of GC)
|> Between smalltalk and eiffel, it's a question of taste: do you like
|> strong static typing or prefer dynamic typing ?
|> I really think the smalltalk environment is excellent, much better
|> than what I know for eiffel, but the strictness of eiffel makes it
|> really nice to debug !
(Debugging is a drag, any tool that reduces the debugging load gets my vote).
|> Stefan Monnier
Bill Maniatty
--
|
| mani...@cs.rpi.edu - in real life Bill Maniatty
|
Bob Hathaway
>...[On OO languages]...
>I'm interested in Operating Systems, and Massively Parallel architectures.
Me too.
>Just how can these techniques be applied to these areas. Consider Kernel
>level programming. A strongly typed language with strong support for reuse
>of software should make for a better kernel implementation and design.
>On the flip side, I'm under the impression that real time programming cannot be
>done with a Garbage Collecting language, as the garbage collection could
>happen at an arbitrary time, and cause a violation of the timing constraints.
Depends on the level and layering of the OS. You may not be able to use
all of the facilities of a language at all levels; you'll have to watch
for infinite recursion in some cases. So its silly to say languages with
GC can't be used in the OS; you just may not be able to use the facility.
This was all relevant in an OS I worked on in an OO extension of Ada.
Des....@bbs.actrix.gen.nz
> m...@orion.oac.uci.edu (Matt Wu) writes:
> >I'm currently evaluating several object-oriented development platforms
> >and I was wondering if any of you would like to share your opinions on
> >platforms that you prefer or know about. It'd be especially useful to hear
> >comparisons between different platforms (for instance, Eiffel v. Smalltalk).
>
> The language situation is roughly as follows:
>
> Ada Big, no inheritance, some tools expensive but do
> exist. Many books on language available. Many
> free libraries available. DoD standard.
> C++ Big, multiple versions of language, unsafe.
> Tools widely available. Many books available.
> Most popular choice.
> Modula-2 No classes or inheritance. Many books.
> Many implementations. Solid, but limited.
> Modula-3 Limited interest - one free compiler, one book.
> Adds classes to Modula-2. Less used than
> Modula-2.
> Eiffel Limited interest - one or two compilers, one book.
> Less used than Smalltalk, C++, Ada, or Modula-2.
"Object-Oriented Software Construction", B Meyer,
Prentice Hall, 1988,
over 100,000 copies sold
Clearly NOT of limited interest!
"Eiffel The Language", B Meyer, Prentice Hall, 1992
This is the industry reference manual for version 3
of Eiffel adopted by the international independent
standards body for Eiffel as the basis for the
standardisation of the Eiffel language.
Other languages are all still struggling even now
to keep up with Eiffel. None of them have yet
reached the level of elegance, simplicity
and mental power of Eiffel and Eiffel is
not standing still. ISE is working on version 3
at the moment. SIG is working on a DOS version
, with Windows coming soon. I have it on very
good authority that there are other compilers
in the works, I can't tell you who is developing
them because my source is sworn to secrecy,
and like a good honest source would not tell me.
No doubt we will see them some time next year.
ISE's Eiffel came out in 1986 with
multiple inheritance, repeated inheritance,
genericity, including constrained genericity,
static typing AND dynamic binding, polymorphism,
assertions
(method preconditions, method postconditions,
class invariants ) and the design of contracts
between client and supplier, a very object-oriented
and neat approach to exception handling where in
combination with assertions and contracts the error
is passed back exactly to its source, where the buck
stops : the client.
Assertions and the intelligent
legal-like framework for assigning responsibility
make this language very safe and a pleasure to debug
( if there can be pleasure in debugging) because you
rarely have to debug! Assertions and the intelligent
exception handling tell you exactly who did what to
whom and who is responsible for fixing the problem.
Run away error propagation is prevented by assertions
and intelligent exception handling. There is also a
retry capability where a delinquent client may restore
the damage it has done and retry its request via a
different pathway. But it is the clients job to clean
up its own mess.
Of course, a supplier has to deal
errors as a result of defaults in its side of the
contract if a postcondition fails. But again the
responsibility is clear and the error is localised.
Used intelligently assertions and the Eiffel exception
handling mechanism can save you days of grief compared
to almost any other language on the market OO or
otherwise.
ISE Eiffel 3 is in the pipeline at the moment
The new development tools are a big advance forward.
To the compiler has been added an interpreter which
is integrated with the compiler. This environment
is called EiffelBench.
This has an enormous advantage because you can
interpret some classes while leaving others
in compiled form. When you are dealing with a large
number of classes you will have the significant
advantage that you can experiment/prototype/maintain
a small subset of the class network and gain a much
faster turn around time than with a compiler alone.
However, unlike Smalltalk, the interpreter like the
compiler still provides full STATIC type checking for
each class that is interpreted. Smalltalk only checks
types at run time. Which is a bit like the pilot of an
aircraft checking, for the first time, to see if there
is enough fuel when you are over a large ocean!
Some people might be happy with such an airline, not
me!
So you have the advantage of fast development,
controlled change by limiting the span of interpretion
versus compilation, AND static type checking.
There is aslo a new interface builder called
EiffelBuild. Like Eiffelbench and the other
tools it operates on OO principles. You decide
what Context you are working in and then you add
,via drag and drop style, Commands that are relevant
in the Context. So you build up Modes that are able
respond to events on the GUI. The approach is a
visual programming style. The interface generates
Eiffel code.
EiffelStore is going to provide interfaces to
relational database systems : Oracle, Ingres,
Informix and others.
EiffelStore is also being interfaced to OO DBMS
systems: Versant and O2 interfaces are in the
pipeline.
Currently there are about 2100 Eiffel licenses
wordwide. These tend to be large companies or
Universities. Over 400 Universities use Eiffel
to teach the principles of OO.
So Eiffel is not yet as widespread as C++
but then how many people using a C++ compiler
are really doing OO ? C++ compilers may be better for
died in the wool C programmers who are scared to
venture to far from the nice little C hole they have
dug theselves. But C++ is a poor compromise at best.
It is not real OO. Even authors who work at AT&T
have documented, several times, how difficult it is
to teach the best C programmers to use the OO
extensions of C++. OO thinking is very very different
from procedural thinking. And it is just human nature
to slip to the bad old ways.
So when you see figure of enormous numbers of C++
licenses. Think what this really means in OO terms
rather that C terms.
My advice is not to be a sheep. Sheep get slaughtered
in the end.
Look at the various platforms and judge for yourself.
Decide what you need that suits you. Don't go on the
number of licenses!
Michel Dagenais
> Modula-3 Limited interest - one free compiler, one book.
> Adds classes to Modula-2. Less used than
> Modula-2.
I dont want to start a language war here (it already started, a dozen
replies already came out on John Nagle's post), but the extensive libraries
available ( X graphical user interface, read/write for objects) for free
with DEC SRC Modula 3 should be mentioned. Moreover it has garbage
collection AND preemptive multi-threading (all the libraries are thread
safe), which none of the others mentioned (C++, Eiffel, SmallTalk...) have.
Threads are quite useful for user interaction and client-server
applications.
--
---------------------------------------------------------------------
Prof. Michel Dagenais dage...@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal tel: (514) 340-4029
---------------------------------------------------------------------
James McKim
[...]
>
>I'm interested in Operating Systems, and Massively Parallel architectures.
>Just how can these techniques be applied to these areas. Consider Kernel
>level programming. A strongly typed language with strong support for reuse
>of software should make for a better kernel implementation and design.
>On the flip side, I'm under the impression that real time programming cannot be
>done with a Garbage Collecting language, as the garbage collection could
>happen at an arbitrary time, and cause a violation of the timing constraints.
Eiffel allows you to turn off GC when the system is under heavy time constraints
and then turn it back on when timing is less critical. The question then
becomes: Can you do a better job of GC manually than the system can do
automatically? The answer depends on you, your system and the quality
of the automated GC. As automatic GC algorithms and implementations improve,
fewer and fewer people will be tempted to write their own.
>And I wonder just how well the Eiffel assertion checking could handle parallel
>computations? Can I get a win by using Eiffel to do these sorts of things,
>and if so, how?
This is an area of current research. Bertrand just published a list
of references to work involving concurrency and parallellism with respect
to Eiffel. I could send you this list if you like.
>
>
>Bill Maniatty
>--
>|
>| mani...@cs.rpi.edu - in real life Bill Maniatty
>|
Hope this helps,
-- Jim
--
*------------------------------------------------------------------------------*
Jim McKim (203)-548-2458 In exactly 3.2 seconds it will be a few
Internet: j...@hgc.edu minutes to 5:00.
garry hodgson
In article <-t!p#_a.n...@netcom.com> na...@netcom.com (John Nagle) writes:
> m...@orion.oac.uci.edu (Matt Wu) writes:
> >I'm currently evaluating several object-oriented development platforms
> >and I was wondering if any of you would like to share your opinions on
> >platforms that you prefer or know about. It'd be especially useful to hear
> >comparisons between different platforms (for instance, Eiffel v. Smalltalk).
>
> The language situation is roughly as follows:
> Eiffel Limited interest - one or two compilers, one book.
> Less used than Smalltalk, C++, Ada, or Modula-2.
Correction: two books:
[ Many lines of Eiffel cheerleading,
including lots of interesting technical aspects, deleted ]
You know, up to this point, you were doing great. I found your
discussion of the various benefits of Eiffel very interesting.
I was even interested in finding out more.
Then you lay the following crap on me. My eyes glaze over, and I have
the same reaction I get to TV "info-mercials" and televangelists.
I tune out. Many of the "discussions" of C++ vs. Eiffel I've seen
in the past showed the same kind of wild-eyed enthusiasm for Eiffel,
mixed with disdain for the lowly cretins who would debase themselves
by using C++. Now, maybe I should be impressed that Eiffel can
generate that kind of enthusiasm, but zealots scare me, and my first
instinct is to stop listening, and to dismiss the technical arguments
as more of the same.
So Eiffel is not yet as widespread as C++
but then how many people using a C++ compiler
are really doing OO?
Quite a few of us, actually. Although perhaps our level of OO-enlightenment
is not up to your exalted standards, Oh Blessed One.
C++ compilers may be better for
died in the wool C programmers who are scared to
venture to far from the nice little C hole they have
dug theselves.
Yeah, I just spend all day cringing in my office, uh, hole, praying
I will never have to learn anything or have an original thought again.
Pssst. Don't tell my management.
But C++ is a poor compromise at best.
It is not real OO.
Perhaps by your definition. Many disagree.
Even authors who work at AT&T
have documented, several times, how difficult it is
to teach the best C programmers to use the OO
extensions of C++.
Now, how do you suppose they slipped that past the AT&T Thought Police?
OO thinking is very very different
from procedural thinking. And it is just human nature
to slip to the bad old ways.
Yeah, us C++ folks is definately too stoopid to learn nuthin' new.
So when you see figure of enormous numbers of C++
licenses. Think what this really means in OO terms
rather that C terms.
It means that a great many people are reaping the benefits of OOP.
My advice is not to be a sheep. Sheep get slaughtered
in the end.
Look at the various platforms and judge for yourself.
Decide what you need that suits you. Don't go on the
number of licenses!
Agreed. That is what the original poster is trying to do.
If we went by the number of licences, we'd all be using COBOL.
--
Garry Hodgson A slow winter day
AT&T Bell Labs A night like forever
ga...@alice.att.com Sink like a stone
att!alice!garry Float like a feather
John Nagle
>In article <8mg...@rpi.edu> mani...@cs.rpi.edu (Bill Maniatty) writes:
>>On the flip side, I'm under the impression that real time programming cannot be
>>done with a Garbage Collecting language, as the garbage collection could
>>happen at an arbitrary time, and cause a violation of the timing constraints.
There's been some effort on concurrent garbage collection.
Wirth introduced the first successful algorithm at a NATO Summer Study
session in the late 1970s.
Hermes has garbage collection and is intended for real-time applcations,
but the only available implementation is an interpreter. Hermes has
some very good ideas in it, and I recommend reading up on it to language
designers.
John Nagle
Des....@bbs.actrix.gen.nz
Since 1976 when the first Eiffel compiler was released it has had tuneable
garbage collection. The version from ISE ( the original ) allows you to turn
garbage collection off for time critical classes. The garbage collector in
ISE's version of Eiffel operates as a coroutine anyway. It is an incremental
garbage collector operating in small bursts rather than taking over the whole
system to clean the mess. The class MEMORY has features to control the
interval of collection. You can turn collection on or off and do partial
garbage collection.
So you can tune the collection for real time
applications to when the resources are available for collection and not impact
time critical method operations. This is not new. It has always been there in
Eiffel since the first release.
Des Kenny
Objective Methods
PO Box 17356
Wellington
New Zealand
Phone: 64 4 476 9499
fax: 64 4 476 9237
email: Des....@bbs.actrix.gen.nz
Des....@bbs.actrix.gen.nz
> In article <1992Sep28.0...@actrix.gen.nz> Des....@bbs.actrix.gen.nz writes:
> In article <-t!p#_a.n...@netcom.com> na...@netcom.com (John Nagle) writes:
> > m...@orion.oac.uci.edu (Matt Wu) writes:
> > >I'm currently evaluating several object-oriented development platforms
> > >and I was wondering if any of you would like to share your opinions on
> > >platforms that you prefer or know about. It'd be especially useful to hear
> > >comparisons between different platforms (for instance, Eiffel v. Smalltalk).
> >
> > The language situation is roughly as follows:
>
> > Eiffel Limited interest - one or two compilers, one book.
> > Less used than Smalltalk, C++, Ada, or Modula-2.
>
> Correction: two books:
>
> [ Many lines of Eiffel cheerleading,
> including lots of interesting technical aspects, deleted ]
interesting technical aspects and cheerleading.
>
> You know, up to this point, you were doing great. I found your
> discussion of the various benefits of Eiffel very interesting.
> I was even interested in finding out more.
Now be serious. You are not so easily put off surely. What
such fragile curiousity? I am rather skeptical about this as you can
gather. If a system is worth looking at then look. Don't let me sway
you one way or the other look for yourself. If you have not looked at
Eiffel and it has been around since 1986 where do you hide? There
must be some very deep holes at AT&T.
>
> Then you lay the following crap on me. My eyes glaze over, and I have
> the same reaction I get to TV "info-mercials" and televangelists.
> I tune out. Many of the "discussions" of C++ vs. Eiffel I've seen
> in the past showed the same kind of wild-eyed enthusiasm for Eiffel,
> mixed with disdain for the lowly cretins who would debase themselves
> by using C++. Now, maybe I should be impressed that Eiffel can
> generate that kind of enthusiasm, but zealots scare me, and my first
> instinct is to stop listening, and to dismiss the technical arguments
> as more of the same.
I reiterate this is merely my own opinion. Maybe I am right maybe I
am not. So go look for yourself. I can only state my impressions
you have to make up your own mind. But you have first to drag it over
the Eiffel manuals and a real Eiffel system, talk to some Eiffel users,
get the real pros and cons.
Don't tell me there are no Eiffel systems at AT&T! If nothing else
you should have one to see what the competition is up to.
This is basic marketing not even a technical issue.
So go look at it, criticise the hell out of it if you like but at least
do it on the basis of some real facts. I Would be delighted to see some
really enlightened criticism of Eiffel.
No system is perfect it is all
relative. So I hope we can look forward to your critical comments on Eiffel
when you have had a serious look at the documentation and the system.
I suggest you look at ISE's version for now. Other versions are not as
advanced yet.
>
> So Eiffel is not yet as widespread as C++
> but then how many people using a C++ compiler
> are really doing OO?
>
> Quite a few of us, actually. Although perhaps our level of OO-enlightenment
> is not up to your exalted standards, Oh Blessed One.
>
So there are some people using only the OO capabilities of C++.
Perhaps. My point is that C++ is often promoted as being easy to learn if
you already know C. There have been several people that have documented that
in general it is harder to teach experienced C programmers to unlearn
C so that they can learn only the OO capabilities of C++. They have found
that it is often easier to teach people the OO extensions of C++ and to
think in an OO way if they are not experienced C programmers.
So there seems to be a contradiction going on here. It seems that
the marketing people promoting C++ are not aware of this contradiction,
because they still push this argument.
> C++ compilers may be better for
> died in the wool C programmers who are scared to
> venture to far from the nice little C hole they have
> dug theselves.
>
> Yeah, I just spend all day cringing in my office, uh, hole, praying
> I will never have to learn anything or have an original thought again.
> Pssst. Don't tell my management.
>
So there are some exceptions. Congratulations! You appear to be an original
thinker. So we can expect to see some factual evaluations of Eiffel and
any other OO systems you are studying at the moment, as well as C++ of
course. I look forward to this publication.
> But C++ is a poor compromise at best.
> It is not real OO.
>
> Perhaps by your definition. Many disagree.
So Let us be more technically specific. I await your criticisms of
Eiffel and any other OO systems with anticipation.
>
> Even authors who work at AT&T
> have documented, several times, how difficult it is
> to teach the best C programmers to use the OO
> extensions of C++.
>
> Now, how do you suppose they slipped that past the AT&T Thought Police?
Far be it for me to say. "The truth will out", occasionally.
>
> OO thinking is very very different
> from procedural thinking. And it is just human nature
> to slip to the bad old ways.
>
> Yeah, us C++ folks is definately too stoopid to learn nuthin' new.
We shall see what your evaluation of Eiffel and other OO systems
tells us.
>
> So when you see figure of enormous numbers of C++
> licenses. Think what this really means in OO terms
> rather that C terms.
>
> It means that a great many people are reaping the benefits of OOP.
It also means that these figures are totally unreliable. Everyone
who wants a better C compiler will probably upgrade to C++.
This tells us absolutely nothing about who is really using the
OO capabilities of C++, and even less about who is EXCLUSIVELY
using the OO capabilities of C++, such as they are.
>
> My advice is not to be a sheep. Sheep get slaughtered
> in the end.
>
> Look at the various platforms and judge for yourself.
> Decide what you need that suits you. Don't go on the
> number of licenses!
>
> Agreed. That is what the original poster is trying to do.
> If we went by the number of licences, we'd all be using COBOL.
Numbers of licenses is a marketing argument used by many C++ vendors
to promote C++.
So we look forward to your criticisms of Eiffel and whatever else
you like.
> --Des Kenny
Objective Methods
Nadja Adolf
>Then you lay the following crap on me. My eyes glaze over, and I have
>the same reaction I get to TV "info-mercials" and televangelists.
>I tune out. Many of the "discussions" of C++ vs. Eiffel I've seen
>in the past showed the same kind of wild-eyed enthusiasm for Eiffel,
>mixed with disdain for the lowly cretins who would debase themselves
>by using C++. Now, maybe I should be impressed that Eiffel can
>generate that kind of enthusiasm, but zealots scare me, and my first
>instinct is to stop listening, and to dismiss the technical arguments
>as more of the same.
Agreed. I am afraid I moved into flame mode here as a result of the
response to my opinion that smalltalk is not realistic for use in
business programming. I received everything from comments on my penis
size (being female, I would like to inform those folks that I don't have
one, nor could I care less) to email letter bomb threats.
>Quite a few of us, actually. Although perhaps our level of OO-enlightenment
>is not up to your exalted standards, Oh Blessed One.
Thank you. Languages should be selected for their appropriateness to the
task at hand. Smalltalk is good for rapid prototyping; C++ for production
code. Modula-3 would be good for production code if it were more widespread,
and therefore the talent to use it was available. I don't know about
Eiffel; so I won't comment.
> C++ compilers may be better for
> died in the wool C programmers who are scared to
> venture to far from the nice little C hole they have
> dug theselves.
>Yeah, I just spend all day cringing in my office, uh, hole, praying
>I will never have to learn anything or have an original thought again.
>Pssst. Don't tell my management.
:-) I always thought that C++ was good for those of us who couldn't talk
management into Modula-3 or Ada. :-)
(Yes, Ada isn't object oriented, but don't tell the government.)
> But C++ is a poor compromise at best.
> It is not real OO.
>Perhaps by your definition. Many disagree.
OK. Now you've gone and done it. Which has the 'realest' :-) OO?
Smalltalk or C++?
> So when you see figure of enormous numbers of C++
> licenses. Think what this really means in OO terms
> rather that C terms.
>It means that a great many people are reaping the benefits of OOP.
> My advice is not to be a sheep. Sheep get slaughtered
> in the end.
Good thinking. I guess we can't pull the wool over your eyes. :-)
>Agreed. That is what the original poster is trying to do.
>If we went by the number of licences, we'd all be using COBOL.
Yep.
Or RPG.
--
The Earth Pig Bourne....
na...@node.com (prefered email address)
na...@weitek.com
Des....@bbs.actrix.gen.nz
> In article <-t!p#_a.n...@netcom.com> na...@netcom.com (John Nagle) writes:
>
>
> > Modula-3 Limited interest - one free compiler, one book.
> > Adds classes to Modula-2. Less used than
> > Modula-2.
>
> I dont want to start a language war here (it already started, a dozen
> replies already came out on John Nagle's post), but the extensive libraries
> available ( X graphical user interface, read/write for objects) for free
> with DEC SRC Modula 3 should be mentioned. Moreover it has garbage
> collection AND preemptive multi-threading (all the libraries are thread
> safe), which none of the others mentioned (C++, Eiffel, SmallTalk...) have.
> Threads are quite useful for user interaction and client-server
> applications.
In comparison to Eiffel I would like to know:
Does Modula-3 have inheritance/multiple inheritance?
Which leads to the question does Modula-3 have
polymorphism and dynamic binding?
Is the garbage collector an incremental one , operating as a coroutine.
Can the garbage collector be tuned from a running system, so that
the collection frequency and period is managed by an application or a user.
Although is really an issue of an environment rather than the language
per se. I agree it is certainly important.
______________________________________________________________________
As far as Eiffel is concerned there have been a number of discussions
on concurrency and some proposed implementation techniques.
A couple of the latest papers are from TOOLS USA August '92, Prentice Hall.
1. "Concurrency Annotations Improve Reusability", Klaus-Peter Lohr ( with an
oomlaut), Freie Universitat (with oomlaut) Berlin
email: lo...@inf.fu-berlin.de
Concurrency is implemented as an annotation which are inserted as comments.
"Carefully chosen annotations lead to a declarative style of concurrent
object-oriented programming and avoid problems with the interplay between
concurrency and inheritance" : from the abstract
This has been implemented in a system called CEiffel.
"The project relies on experience gained from DAPHNE, a module-based system
for distributed execution of sequential Modula programs [Lohr et al 88]
We did not introduce yet another "distributed' version of Eiffel. CEiffel will
be used for programming, and a configuration tool will take care of
distribution issues such as stub generation for remote object invocation and
construction and placement of load images on the nodes of a network. A
different approach has been taken for Distributed Eiffel, a considerably
modified version of Eiffel described in [Gunaseelan/LeBlanc 91]"
"We have developed a portable threading system in Eiffel (version 2), and
CEiffel is being implemented through a precompiler that generates threaded
Eiffel code"
This is an interesting approach. A particular class may be processed
sequentially or concurrently as you choose.
2. Another approach is given in the TOOLS USA, August '92 proceedings:
This is called
" A concurrency mechanism for sequential Eiffel", Murat Karaorman, John Bruno
University of California, Sanata Barbara,
email: mu...@cs.ucsb.edu, br...@cs.ucsb.edu
This approach is to consider concurrency as a "well-defined, inheritable
property of objects specified in the class CONCURRENCY, and provides a
methodology using inheritance to write concurrent object-oriented
applications."
Concurrency is considered a set of features that can be added to any class
by using multiple inheritance.
So no syntactic extension of the Eiffel language is required.
This is another illustration of the application of multiple inheritance.
It seems to me that we are going to see more of this type of approach to
add new capabilities to the Eiffel language without having to make
fundamental changes to the language syntax every time. It illustrates
the capaability of Eiffel's conceptual extension into new domains because
although you are not adding new syntax you are adding new TYPES to the
language, together with their relevant operators and constraints.
So the concepts of threads and concurrency are not foriegn to Eiffel.
See the references in these papers for earlier papers.
It will be interesting to see these techniques in action. I suggest you
contact the authors of the above papers for more information.
Regards
--Des Kenny
Objective Methods
PO Box 17356
Wellington
New Zealand
Phone: 64 4 476 9499
fax: 64 4 467 9237
email(Internet): Des....@bbs.actrix.gen.nz
Stephen Cooper
>>I'm currently evaluating several object-oriented development platforms
>>and I was wondering if any of you would like to share your opinions on
>>platforms that you prefer or know about. It'd be especially useful to
hear
>>comparisons between different platforms (for instance, Eiffel v.
Smalltalk).
>
> The language situation is roughly as follows:
Anyone have any info. on Simula? How OO is it? Is it a good pedagogic
lang? I'll be teaching a course in OOP in Dec, and was sold on
Smalltalk, but a friend said I should check up on Simula.
-----------------------------------------------------------
Stephen Cooper +46-(0)18-18 10 73 (voice)
Computing Science Dept +46-(0)18-52 12 70 (fax)
Uppsala University, Sweden ste...@csd.uu.se
Thomas M. Breuel
But C++ is a poor compromise at best.
It is not real OO.
I'm really glad that C++ is a compromise between OO and non-OO
facilities. If it weren't, it would be much less expressive and much
less useful.
Look at the various platforms and judge for yourself.
Decide what you need that suits you. Don't go on the
number of licenses!
I did; Eiffel didn't suit me.
Thomas.
Bill Maniatty
|> In article <+s_p3w=.na...@netcom.com> na...@netcom.com (John Nagle) writes:
|> > Bob Hathaway <obj...@netcom.com> writes:
|> > >In article <8mg...@rpi.edu> mani...@cs.rpi.edu (Bill Maniatty) writes:
|> > >>On the flip side, I'm under the impression that real time programming cannot be
|> > >>done with a Garbage Collecting language, as the garbage collection could
|> > >>happen at an arbitrary time, and cause a violation of the timing constraints.
|> Since 1976 when the first Eiffel compiler was released it has had tuneable
|> garbage collection. The version from ISE ( the original ) allows you to turn
|> garbage collection off for time critical classes. The garbage collector in
|> ISE's version of Eiffel operates as a coroutine anyway. It is an incremental
|> garbage collector operating in small bursts rather than taking over the whole
|> system to clean the mess. The class MEMORY has features to control the
|> interval of collection. You can turn collection on or off and do partial
|> garbage collection.
|>
|> So you can tune the collection for real time
|> applications to when the resources are available for collection and not impact
|> time critical method operations. This is not new. It has always been there in
|> Eiffel since the first release.
This does not seem safe, (I wish this weren't true). The whole point of garbage
collection is that when the system is out of memory, it can check the allocated
memory to see which parts of the heap are allocated but unreferenced (and
therefore garbage).
Consider the following scenario:
Suppose that there are real time constraints and the
user wants to control when garbage collection can and cannot
occur.
Now the application programmer needs to determine if and when the set of
active jobs will use all available memory.
This seems unreasonable, as Eiffel does its own allocation/deallocation
stuff under the hood (that is transparently to the user).
In that case the only alternative is for the system to detect and handle
the exception (that is interrupt when the ``out of memory''
condition occurs).
This could occur at a time not anticipated by the user.
The user has disabled the garbage collector from running at this time
however and the system locks up.
|> Des Kenny
|> Objective Methods
Knut Omang
> Anyone have any info. on Simula? How OO is it? Is it a good pedagogic
> lang? I'll be teaching a course in OOP in Dec, and was sold on
> Smalltalk, but a friend said I should check up on Simula.
SIMULA developed here at the University of Oslo, Norway in the middle 60's
was as far as I know the first language to introduce the terms
objects and classes.
It has been used in most of our low level programming courses since then,
and it is also used at least as the basic course in programming at some
other Universities, amonst them at Lund in Sweden, which have depeloped the
compiler for Sun that we currently use. SIMULA also this year replaced Pascal
as the beginners language at University of Bergen, Norway.
We also have a public domain SIMULA compiler compiling to C available
for a broad range of architechtures.
In my own opinion the original language was far ahead of its time, in several
ways. It introduced a whole new set of abstractions :
o The object oriented paradigm (some 15-20 years ahead of the next finshed
attempt Smalltalk, which were heavily infuenced of Simula)
Simula has classes, subclasses (single inheritance) and virtual functions
o Safety mechanisms (automatic variable initialization, pointer safety, and
relatively strong typing (pointers never point to anything but what they
are decared to point to or the null object)
o A high level debugger,
All errors in a Simula program compiled with an error free compiler
are caught "at the program abstraction level" by the run time environment,
which makes it excellent for teaching purposes, eliminating a lot of
matters to distract students from the main purpose of a beginners course.
o Quasi parallellity: Objects have a main action part which can operate
in its own, closed environment and be activated and deactivate leaving
control to another 'thread'-like object or to the main program.
It also had things like
o Garbage collection
o free nesting of procedures and classes
However, SIMULA was also subject
to a lot of unfortunate conditions :
o It was released in a time when efficiency at the micro level
was much more focused on, i.e. the RAM and CPU power was thought of
as much more expensive than hiring a bunch of extra programmers
to debug (?) CPU-effective FORTRAN programs.
o Developing a SIMULA compiler was a far more complex task than
for instance, a Pascal compiler.
o The SIMULA project didn't have the necessary freedom to give away
their compiler for free (the institutions financing it wanted their
money back too quickly) A good example is that Donald Knuth, which visited
our site in 1972, asked for a copy of the compiler to use in the
basic programming courses at Stanford, but had to leave empty handed
because of the price of the compiler!! He instead ended up with Pascal
for his courses.
There is a SIMULA reference- and information database along with
public domain software available
by anonymous ftp from
ftp.fenk.wau.nl, directory pub/simula
I'm taking the freedom of including their reference list below,
as the best candidate.
Our public domain compiler could be ftp'ed from
ifi.uio.no, directory
Knut Omang,
Dep. of Informatics, University of Oslo, Norway
e-mail: kn...@ifi.uio.no
included file from ftp.fenk.wau.nl, pub/simula/simula.info:
----------------------------------------------------------------------
SIMULA INFO
The most recent version is stored on the Simula database on Bitnet and Internet.
On Bitnet get a copy by sending GET SIMULA INFO as first line of your email to
Listserv@dearn.
On Internet use Gopher or ftp to ftp.fenk.wau.nl and look in the
pub/simula directory.
Send additions and corrections to Jan Scheutjens <j...@fenk.wau.nl>
--------------------------------------------------------------------------
1992-05-31
If you want to do object-oriented programming you definitely
should have a look at SIMULA. SIMULA is the first and still the
most advanced object-oriented programming language available on a
wide variety of machines *including* the Atari ST.
SIMULA has been in general use for twenty years and the soundness
of its philosophical foundation has been thoroughly established.
SIMULA in a Nutshell
====================
o Conventional general-purpose algorithmic capability in the
style of ALGOL 60.
o Object-oriented programming (classes) encompassing
encapsulation, inheritance, information hiding, autonomous
activity and strong typing, supporting the concepts of
modularisation, generalisation, specialisation, abstraction,
polymorphism and pseudo-parallelism.
o Basic features for manipulating text strings.
o File concept supporting sequential and direct access methods
for byte- and record-structured files.
o Large repertoire of utility functions.
o Features supporting 2-way linked lists. More complicated
list structures such as trees and lattices are easily
constructed from the basic class facilities.
o Features supporting discrete event simulation in various
styles including the object-oriented process view.
It should be emphasised that although in many quarters SIMULA is
best known for its simulation features, it is a truly general-
purpose language in the widest sense and was the inspiration for
almost all developments in the field of object-oriented
programming. For a growing number of users the name is becoming
an acronym for SIMple Universal LAnguage.
What you get with each SIMULA system
====================================
o Object oriented programming. A typical SIMULA program
execution consists of a set of interacting processes or
*objects*. Objects are incarnations of some prototype or
*class*, generated during the execution of the program.
Programs written in SIMULA in the object-oriented style
preserve more accurately the identities and relationships of
the functional entities occurring naturally in the
computation.
o Strong typing, checked mostly at compile time, ensuring
that objects are manipulated in a manner consistent with
their specification.
o Objects may act independently of each other in "quasi-
parallel". This enables the class objects to act as
coroutines, so that the autonomous activity of any object
may be temporarily suspended, later to be resumed at the
exact point of suspension. Coroutines facilitate a faithful
representation of systems composed of not only passive
objects but also active ones in which distinct bursts of
activity are tightly coupled in the notion of a coherent
process. This feature is an extra dimension to those commonly
associated with object-oriented languages and is only
recently beginning to appear in some of the newer ones.
o List processing. The standard class "Simset" may be invoked
to add list processing capabilities to the basic language
features. The programmer will then have tools for the efficient
manipulation of common aggregate information structures,
including queues, dequeues, stacks and cyclic buffers. The
facilities of Simset can be further refined for more
specialised purposes.
o Simulation. Application of the standard class "Simulation"
converts SIMULA into a powerful tool for discrete event
simulation in a style which preserves in the model the
inherent structure of the system under study. Object-oriented
programming originated in process-oriented simulation and
simulation in SIMULA is the epitome of the object-oriented
paradigm.
o Powerful text handling, dynamic arrays, flexible file
handling, etc.
o Modularisation. Separate compilation of classes and
procedures is an integral part of the language. The strong
typing extends to separately compiled modules allowing the
construction of large SIMULA systems to be partitioned into
subtasks, which may be assigned to different work groups
without fear of undetected incompatibilities.
o Garbage collection. Languages without automatic object
storage administration cause their practitioners enormous
problems in determining the life span of objects. This leads
either to the premature demise of useful objects or to the
silting up of memory resulting in unwanted and sometimes
irreproducible situations which defy diagnosis. SIMULA has
automatic garbage collection, eliminating intractable
problems of this nature.
o Portability. SIMULA has a rigid standard definition and
programs are highly portable between different computer
systems (source code compatibility).
Literature
==========
The Standard:
[SIS87] SIMULA Standard. Stockholm, 1987. Data processing -
Programming languages - SIMULA,
Swedish Standard SS 63 61 14.
Textbooks on SIMULA:
[BDMN73] Graham M. Birtwistle, Ole-Johan Dahl, Bjoern Myhrhaug,
and Kristen Nygaard. SIMULA BEGIN. Studentlitteratur,
Lund, Sweden, 1973. ISBN 91-44-06211-7. Also published
by Bratt Institut fuer neues Lernen, Goch, GDR and
Chartwell-Bratt Ltd., Bromley, England.
[Jed86] P. Jedlovzky. Do it with SIMULA. COMPUDRUG International,
Laxenburgerstr. 49/7/15, A-1100 Wien, Austria, 1986.
[Poo87] R. J. Pooley. An Introduction to Programming in SIMULA.
Blackwell Scientific Publications, Oxford, 1987.
ISBN 0-632-01611-6 resp. 0-632-01422-9 (pbk.).
[Lam88] Guenther Lamprecht. SIMULA - Einfuehrung in die
Programmiersprache. Vieweg Verlag, Braunschweig,
Wiesbaden, 3. neubearbeitete Auflage, 1988.
ISBN 3-528-23321-4. (In German, also available in
English)
[Kir89] Bjoern Kirkerud. Object-Oriented Programming with
SIMULA. International Computer Science Series. Addison-
Wesley Publishing Co., 1989. ISBN 0-201-17574-6.
Textbooks on Simulation:
[Fra77] W. R. Franta. The process view of simulation. Elsevier
North-Holland, New-York, 1977. Also published by North-
Holland, Netherlands.
[Bir79] Graham M. Birtwistle. DEMOS - Discrete Event Modelling
on SIMULA. MacMillan Press, London, Basingstoke, 1979.
ISBN 0-333-32881-8.
[Mit82] I. Mitrani. Simulation Techniques for discrete event
systems. Cambridge University Press, 1982.
[Kre86] Wolfgang Kreutzer. System Simulation Programming Styles
and Languages. Addison-Wesley Publishing Co., 1986.
SIMULA - Implementations
========================
SIMULA is available for the following computer systems:
Apollo DN3000
Apple MacIntosh/MPW
Atari ST/STE/TT
BESM 6 (USSR)
CDC 3000, CDC 6000/Cyber
Convex
Cromemco CS-x00
DEC 10/20, DEC DECstation (MIPS)
DG Eclipse/Desktop, DG MV
EC 1040/1055 (GDR)
Encore Multimax
ES EVM (USSR)
Honeywell Bull DPS8
HPUX hppa 9000s800, HPUX hppa 9000s700, HPUX mc68040
IBM mainframe
IBM PC/DOS, IBM PC/OS2, IBM PC/XENIX(UNIX)
IBM RS6000 AIX
ICL 2900
Indata IN4200
Masscomp
NCR Minitower, NCR Tower XP/32
Next
Nixdorf Targon/31
Norsk Data NORD 100/500
PR1ME
SIEMENS 7500/BS2000, SIEMENS 7800/BS3000
SIEMENS MX, SIEMENS WX200, SIEMENS PCD
Sony News
Sperry 1100
SUN-3, SUN-4 (SPARC)
VAX/UNIX, VAX/VMS
Since there are new implementations under way this list may be
already incomplete.
More information on SIMULA
==========================
Association of SIMULA Users (ASU)
Secreteriat: Henry Islo
Department of Manufacturing Systems
Royal Institute of Technology
S - 100 44 Stockholm
Sweden
Telephone: (+46 8) 790 60 00 exchange
(+46 8) 790 63 75 direct
(+46 8) 21 95 76 secretary
Fax.: (+46 8) 20 22 27
E-mail: h...@helios.sunet.se
h...@cadcam.kth.se
The ASU was formed in 1973 and has members in over 50 countries.
It arranges conferences, workshops and schools and publishes, free
of charge, a periodic Newsletter.
Contact for SIMULA in Germany:
SIMULA Project
c/o University Dortmund / IRB
P.O.B. 50 05 00
D - W4600 Dortmund 50
F.R. Germany
e-mail: sim...@informatik.uni-dortmund.de
Editors SIMULA Newsletter:
Karel Babcicky
Grafisk Institutt
Gaustadalleen 21
0371 Oslo 3
Norway
Tel: (+47 2) 95 85 77
Fax: (+47 2) 60 28 18
E-mail: k...@gi.no
Eileen Schreiner
Norwegian Computing Center
Postbox 114, Blindern
0314 Oslo 3
Norway
Tel: (+47 2) 45 35 00
Fax: (+47 2) 69 76 60
E-mail: eil...@nr.no
---------------------
ASU Council 1989/1990
---------------------
Ron Kerr, chairman
Computing Laboratory
University of Newcastle upon Tyne
Newcastle upon Tyne
NE1 7RU England
Tel: (+44 91) 222 8187
Fax: (+44 91) 222 8232
Telex: 53 654 uninew g
E-mail: r.k...@uk.ac.newcastle (r.k...@newcastle.ac.uk)
Karel Babcicky
Grafisk Institutt
Gaustadalleen 21
0371 Oslo 3
Norway
Tel: (+47 2) 95 85 77
Fax: (+47 2) 60 28 18
E-mail: k...@gi.no
Boris Magnusson
Lund Software House AB
Box 7056
S-220 07 Lund
Sweden
Tel: (+46 46) 13 40 60
Fax: (+46 46) 13 10 21
E-mail: bo...@dna.lth.se
Onno van Schalkwijk
Rekencentrum der Rijksuniversiteit
Postbus 800
9700 AV Groningen
The Netherlands
Tel: (+31 50) 63 80 80
Fax: (+31 50) 63 34 06
E-mail: o...@rc.rug.nl
---------------------------------------
SIMULA discussion list on Bitnet/EARN/Netnorth:
SIMULA@HEARN
SIMULA@DEARN
SIMULA@EB0UB011
SIMULA@FINHUTC
SIMULA@BITNIC
SIMULA@UGA
SIMULA@MARIST
Subscribe by sending
SUBSCIBE SIMULA your_full_name>
as the first line of your e-mail to LIST...@BITNIC.bitnet
To contribute email to SIM...@hearn.bitnet.
----------------------------------------------------
SIMULA database on Bitnet/EARN/Netnorth:
LIST...@DEARN.bitnet
Get the filelist by sending
GET SIMULA FILELIST
as the first line of your e-mail to LISTSERV@DEARN
----------------------------------------------------
SIMULA database on Internet:
Use Gopher or ftp to ftp.fenk.wau.nl
(user anonymous, password your email address).
Ciaran McHale
>As far as Eiffel is concerned there have been a number of discussions
>on concurrency and some proposed implementation techniques.
Don't you mean to say "As far as lots of OO languages are concerned..."
Eiffel is not unique in being used as a host language to test ideas on
synchronisation.
Of the proposals I have seen for synchronisation mechanisms, for
whatever language, none are perfect. We (people doing research in this
area) have been making great progress over the last few years but don't
expect any OO language, Eiffel included, to have a wonderful
synchronisation mechanism "real soon now."
>A couple of the latest papers are from TOOLS USA August '92, Prentice Hall.
>
>1. "Concurrency Annotations Improve Reusability", Klaus-Peter Lohr ( with an
>oomlaut), Freie Universitat (with oomlaut) Berlin
> email: lo...@inf.fu-berlin.de
>
>[...] This has been implemented in a system called CEiffel. [...]
>
>2. Another approach is given in the TOOLS USA, August '92 proceedings:
> This is called
>
>" A concurrency mechanism for sequential Eiffel", Murat Karaorman, John Bruno
>University of California, Sanata Barbara,
>email: mu...@cs.ucsb.edu, br...@cs.ucsb.edu
>
>[...] So no syntactic extension of the Eiffel language is required.
Whether or not a particular approach to synchronisation requires the
addition of an extra keyword or a change in syntax is not something
that I tend to worry about since there are other issues which seem more
important, e.g., the synchronisation mechanism's expressive power, its
compatability with inheritance and how it facilites/hinders code reuse,
does it support intra-object concurrency. I think it is more important
to solve these problems and then afterwards try to fit the resultant
mechanism into existing languages with a minimum of syntactic
disturbance. (Of course, this attitude of mine is of little help to
those who want a language *now* which they can use for concurrent OO
programming (COOP). But you must accept that whatever COOP langauges
which are available now or "real soon now" are certainly going to be
far from perfect.)
>It seems to me that we are going to see more of this type of approach
>[using multiple inheritance and introducing new concepts (such as
>concurrency/synchronisation) via new class types] to
>add new capabilities to the Eiffel language without having to make
>fundamental changes to the language syntax every time. It illustrates
>the capaability of Eiffel's conceptual extension into new domains because
>although you are not adding new syntax you are adding new TYPES to the
>language, together with their relevant operators and constraints.
One major problem I see with any synchronisation mechansism for Eiffel
which tries to support internal concurrency is the conflict between
internal concurrency and the evaluation of pre/postconditions. (What are
the semantics for evaluating pre/postcondition when instance variables,
which they access, are being updated by a thread executing an operation
of the object?) From my reading, it seems that CEiffel doesn't address
this issue. (I haven't read the paper by Karaorman & Bruno so I don't
know if they have a solution for this.)
I'm not sure whether or not this problem can be solved without having to
make "fundamental changes" to the language as you would like to
believe.
Ciaran.
--
Ciaran McHale ----
Department of Computer Science, Trinity College, Dublin 2, Ireland. \bi/
Telephone: +353-1-7021539 FAX: +353-1-772204 email: cjmc...@dsg.cs.tcd.ie \/
D.S.Riches
>In article <welAJHa00...@andrew.cmu.edu>, osoelga...@CMU.EDU (Stefan Monnier) writes:
>|> Excerpts from netnews.comp.lang.eiffel: 26-Sep-92 Re: comparing
>|> object-orient.. John Na...@netcom.com (1174)
>|>
>|> > m...@orion.oac.uci.edu (Matt Wu) writes:
>|> > >I'm currently evaluating several object-oriented development platforms
>|> > >and I was wondering if any of you would like to share your opinions on
> [More Stuff Deleted]
>
>I'm interested in Operating Systems, and Massively Parallel architectures.
>Just how can these techniques be applied to these areas. Consider Kernel
[Stuff deleteed]
Don't you just hate it when someone changes the subject in the
middle of a promising thread without changing the subject title!!
Dave Riches
Email: David.S...@bnr.co.uk
Smail: BNR Europe Ltd, London Road,
Harlow, Essex. CM17 9NA. England
Phone: +44 (0)279-402496
Fax: +44 (0)279-451434
D.S.Riches
>>On the flip side, I'm under the impression that real time programming cannot be
>>done with a Garbage Collecting language, as the garbage collection could
>>happen at an arbitrary time, and cause a violation of the timing constraints.
There have been a number of Real time systems produced using
Smalltalk for instance. Real time does not imply no garbage
collection but if you actually mean safety critical then that might
be a different issue.
However, you can write GC systems which collect only at specified times
and hence be taken into account on timing issues.
Des....@bbs.actrix.gen.nz
> In article <23...@alice.att.com> ga...@alice.UUCP () writes:
> >In article <1992Sep28.0...@actrix.gen.nz> Des....@bbs.actrix.gen.nz writes:
> >
>
> >Then you lay the following crap on me. My eyes glaze over, and I have
> >the same reaction I get to TV "info-mercials" and televangelists.
> >I tune out. Many of the "discussions" of C++ vs. Eiffel I've seen
> >in the past showed the same kind of wild-eyed enthusiasm for Eiffel,
> >mixed with disdain for the lowly cretins who would debase themselves
> >by using C++. Now, maybe I should be impressed that Eiffel can
> >generate that kind of enthusiasm, but zealots scare me, and my first
> >instinct is to stop listening, and to dismiss the technical arguments
> >as more of the same.
>
> Agreed. I am afraid I moved into flame mode here as a result of the
> response to my opinion that smalltalk is not realistic for use in
> business programming. I received everything from comments on my penis
> size (being female, I would like to inform those folks that I don't have
> one, nor could I care less) to email letter bomb threats.
you happen to be.
As for bomb threats ignore them they don't hurt a BIT.
Just don't publish your coordinates in case of ICBM's from
irate Smalltalkers or any one else.
I happen to agree that Smalltalk is a higher risk language for
industrial applications. There is no static type checking. I do not want to
find out at run time that there are type errors in the system!
There are enough other types of errors to contend with, not to mention
budget and time constraints, without having to deal with highly confused
users confronted with a type error and some wierd system message
that terrifies them that they just lost a days work!
So in this context I prefer Eiffel because I get Static type checking,
polymorphism and dynamic binding. In version 3 there is an interpreter
as well as a compiler. So you can interpret some classes and leave others
as compiled classes. You can then work on a small part of the system,
changing what is required, and get a fast response to your changes.
Before this capability Smalltalk had some advantage over Eiffel in the speed
of the turn around from change to testing. No one really likes
waiting around for a compiler to test a change. In prototyping
this can be a real drag. But now Eiffel can compete with Smalltalk in this
area also. In fact it can be faster than Smalltalk in some applications
because you only interpret the limited area you are changing. The rest of
the classes are running at the speed of compiled code! That suits me
very nicely.
nice.
What is also good about this new capability is that ISE has not sacrificed
Static typing at all to gain this faster development cycle.
The interpreter does full static typing.
So you can use Smalltalk for industrial applications but you are taking
very big risks. Most businesses like to minimise their exposure to risk
if they want to stay in business. Of course , this is an individual
judgement.
>
> >Quite a few of us, actually. Although perhaps our level of OO-enlightenment
> >is not up to your exalted standards, Oh Blessed One.
>
> Thank you. Languages should be selected for their appropriateness to the
> task at hand. Smalltalk is good for rapid prototyping; C++ for production
> code.
With version 3 of Eiffel you can use Eifel for rapid prototyping
and still get the benefits of static type checking, assertions,
contracts, responsibility driven exception handling ...
Modula-3 would be good for production code if it were more widespread,
I think there are more technical issues with Modula-3 to consider.
How well does it conform to the OO approach?
> and therefore the talent to use it was available.
This is an issue for all OO languages because they are so new.
Lots of C++ compilers do not neccesarily mean lots of people
who know how to use the OO capabilities of C++ and avoid the
old C style. This is a common confusion.
I don't know about
> Eiffel; so I won't comment.
I think Eiffel is definitely worth looking at. It may not suite your
requirements. You may think it is ghastly.
But you are never going to find out if you don't look at it.
>
> > C++ compilers may be better for
> > died in the wool C programmers who are scared to
> > venture to far from the nice little C hole they have
> > dug theselves.
>
> >Yeah, I just spend all day cringing in my office, uh, hole, praying
> >I will never have to learn anything or have an original thought again.
> >Pssst. Don't tell my management.
>
> :-) I always thought that C++ was good for those of us who couldn't talk
> management into Modula-3 or Ada. :-)
> (Yes, Ada isn't object oriented, but don't tell the government.)
>
> > But C++ is a poor compromise at best.
> > It is not real OO.
>
> >Perhaps by your definition. Many disagree.
It mixes two diametrically opposing paradigms.
The old procedural style with global state variables and
the OO style with encapsulated state and no access to state values
except by the methods of a class.
Eiffel does not deny the right of the older style to exist.
It simply treats it as a separate world. This is much cleaner
and easier to comprehend, learn and manage. Eiffel can call external
C/C++ modules. Also Eiffel objects can be called from C and I guess
from C++. So we have a neat path for evolution into a new paradigm
The old C/C++ code can be reused as long as it is useful by encapsulating
it with Eiffel classes.
This approach has been taken for the NeXT port of Eiffel, where
the Objective-C modules of NeXTStep have been encapsulated. So the
Eiffel port is somewhat insulated from changes to the underlying
NeXTStep mechanism.
> OK. Now you've gone and done it. Which has the 'realest' :-) OO?
> Smalltalk or C++?
Easy : Eiffel . But please do NOT take my word for this
go try it yourself. Be as critical as you like. But at least
get some real experience to base your criticism on
>
> > So when you see figure of enormous numbers of C++
> > licenses. Think what this really means in OO terms
> > rather that C terms.
>
> >It means that a great many people are reaping the benefits of OOP.
>
> > My advice is not to be a sheep. Sheep get slaughtered
> > in the end.
>
> Good thinking. I guess we can't pull the wool over your eyes. :-)
>
>
> >Agreed. That is what the original poster is trying to do.
> >If we went by the number of licences, we'd all be using COBOL.
>
> Yep.
> Or RPG.
So when are you going to try Eiffel and give us your criticisms.
I look forward to hearing them
-- Des Kenny
Objective Methods
Des....@bbs.actrix.gen.nz
I prefer the preventative approach rather than the curative approach.
But of course cures must be available as a last resort. But not as
a first resort.
Eiffel's incremental garbage collector is designed to clean the garbage
BEFORE you run out of memory for an application , rather than after you have
already run out.
You can turn on thr garbage collector for an application and let it
operate completely automatically, which may be the best option in many
cases.
Or you can tune it by inheriting from the
class MEMORY, where the tuning capability resides.
Many applications will operate fine by allowing the garbage collector
to run with the default system parameters. Garbage collection is then barely
an issue at all.
However, Eiffel does allow you to tailor garbage collection for specific
classes if you wish. Clearly it is up to the person using this facility to
know what the load is on the system and be aware of what memory , I/O ,
processor and other resources are available in such an environment
when the tunable class is running. This will involve a degree of
calibration.
Such a case may be a real time embedded system, where the parameters
of the system, boundary conditions, are reasonably precisely defined.
So the system load is not too difficult to predict. It will again vary
with individual cases.
Eiffel is being used in one such instance by Advanced Robotics Research Ltd
in the U.K. They are building a mobile robot weighing 1/3 of a ton.
The system has to respond at the 20ms level.
It is a safety critical application. A runaway 1/3 of a ton robot is
no joke!
It is using four T800 Transputers and two datalinks that have transfer rates
of 200MB/second.
So this is real time with Eiffel. I do not know how exactly
they are using the garbage collector. I will let you know when I find out.
But you can be sure that they can not afford a memory seizure of a mobile
1/3 ton beastie!
They have a spectrum of choices from no garbage collection, to tuned
collection to full system default collection. It will be very interesting to
see how they are approaching this issue.
>
> Consider the following scenario:
> Suppose that there are real time constraints and the
> user wants to control when garbage collection can and cannot
> occur.
As I said above the user must know the load profile on the system.
This applies to any kind of tuning you care to do on any system.
Every case is different. So you have to tune your applications in
the context that they are going to be used, including the system
resources available.
> Now the application programmer needs to determine if and when the set of
> active jobs will use all available memory.
You are clearly going to have to calibrate your applications in a
given context. Also we should aim for prevention rather than cure.
So a margin of error is wise in calculating memory required.
Then it is a matter of switching on the garbage collector at suitable
intervals to do PARTIAL collection. Note that this is not a full
collection. We are trying to prevent the application from running out
of memory before we get too close to the critical margin of error.
> This seems unreasonable, as Eiffel does its own allocation/deallocation
> stuff under the hood (that is transparently to the user).
This will have to be allowed for in the calibration.
> In that case the only alternative is for the system to detect and handle
> the exception (that is interrupt when the ``out of memory''
> condition occurs).
Not if you allow a margin of error and initiate partial collection at
frequent enough intervals.
> This could occur at a time not anticipated by the user.
> The user has disabled the garbage collector from running at this time
> however and the system locks up.
Not if you have calibrated the application in a given context of
other applications and system resources; and allowed a sufficient
error margin; and have partial collection at frequent enough
intervals.
Different applications in different contexts will use memory
with different profiles of usage. You can not always predict these
profiles but you can run sufficient cases to allow a safe
margin of error to be used. The cost of memory is no longer
such an issue, so you can err on the side of memory that
accounts for the margin of error.
Well it is not perfect but then you are asking for applications
to run at the limits of the systems resource capabilities.
So you have to provide enough resources to allow for the
imperfection in our ability to predict exactly what is
needed. This is by no means a new strategy in any system
context, OO or otherwise. Operating systems can thrash
if they are out of balance in terms of load and resources
such as memory and disk, for example.
It is going to extremely interesting to see how ARRL
handle this situation.
--Des Kenny
Objective Methods Ltd
PO Box 17356
Wellington
New Zealand
phone: 64 4 476 9499
fax : 64 4 476 9237
email(Internet): Des....@bbs.actrix.gen.nz
Des....@bbs.actrix.gen.nz
Yes Eiffel has static type checking but it also has polymorphism
and dynamic binding. The new version 3 has still the features of the
compiler but it also has an interpreter that does static type checking.
You can interpret classes selectively, speeding the development
cycle considerably.
> I really think the smalltalk environment is excellent, much better
> than what I know for eiffel, but the strictness of eiffel makes it
> really nice to debug !
>
> I prefer Eiffel, cause it's faster and I much more used to it !
>
> The rest is question of taste !
It may be just a matter of taste for oure research,
if such an activity exists any more in these recessionary
days.
But for applications in industry there are also software
engineering issues and economics to constrain us.
> Maybe you prefer other OOL, like Self, simula, CLOS or...
> CLOS may be a good choice, but I just don't know it yet !
>
As far as I know about CLOS:
CLOS is in some ways less safe than Smalltalk.
It also does
not enforce static type checking. But in addition access to the attributes
of a class can not be restricted. So you can easily violate encapsulation and
information hiding. So the class interface is not so safe.
It has no assertions. There is no standard class library.
It may be an improvement on Common Lisp for AI like applications.
But it would be a dangerous beast to let loose on the average industry
programmer without a major training and rethinking program. Besides I
suspect that the performance is still an issue to consider because
of the dynamic type checking. I would be interested to hear of any
industrial applications on a large scale.
--Des Kenny
Larry Smith
> A good example is that Donald Knuth, which visited
> our site in 1972, asked for a copy of the compiler to use in the
> basic programming courses at Stanford, but had to leave empty handed
> because of the price of the compiler!! He instead ended up with Pascal
> for his courses.
What a concept.
In some parallel universe out there, UCSD Simula went up against C and Pascal
for dominance of the industry. I wonder what happened?
Larry Smith (sm...@ctron.com) No, I don't speak for Cabletron. Need you ask?
-
How about we all do something reasonable? I bet that'll confuse 'em!
Paul Johnson
>[ Many lines of Eiffel cheerleading,
> including lots of interesting technical aspects, deleted ]
[...]
>Then you lay the following crap on me. ... Many of the "discussions"
>of C++ vs. Eiffel I've seen in the past showed the same kind of
>wild-eyed enthusiasm for Eiffel, mixed with disdain for the lowly
>cretins who would debase themselves by using C++. ....
[ Quotes asserting C++ is not real OO and refutations by Garry ]
Hold on everyone. PLEASE lets not have a language war.
For everyone's information, I learned C at University, did a large
project in C++ (including multitasking) and am now a wild-eyed Eiffel
enthusiast. However I do not write off C++ for OO programming. You
CAN write OO programs in C++. Some C++ programmers do this, others
don't.
You can also write spaghetti code in Eiffel. "A Real Programmer can
write Fortran in any language."
Can everyone please accept that all languages have pros and cons?
Some are language issues, others are mucky real-world issues. Lets
just leave it there.
Paul.
--
Paul Johnson (p...@gec-mrc.co.uk). | Tel: +44 245 73331 ext 3245
--------------------------------------------+----------------------------------
These ideas and others like them can be had | GEC-Marconi Research is not
for $0.02 each from any reputable idealist. | responsible for my opinions
Thomas M. Breuel
The system has to respond at the 20ms level.
It is a safety critical application. A runaway 1/3 of a ton robot is
no joke!
It is using four T800 Transputers and two datalinks that have transfer rates
of 200MB/second.
So this is real time with Eiffel. I do not know how exactly
they are using the garbage collector. I will let you know when I find out.
But you can be sure that they can not afford a memory seizure of a mobile
1/3 ton beastie!
They have a spectrum of choices from no garbage collection, to tuned
collection to full system default collection. It will be very interesting to
see how they are approaching this issue.
Assume I have a program that never has more live data than, say, 45%
of real memory. Does your Eiffel implementation guarantee that every
request for memory has a small bounded latency, and does it guarantee
at the same time that my program will never run out of memory?
I am all for GC, even in real-time applications. Furthermore, you can
do real-time GC "right", meaning, you can guarantee (small) bounded
latencies for all operations that would have bounded latencies in the
absence of GC.
However, your descriptions of "turning off GC" or "tuning your
application" sound like the Eiffel implemention you are talking about
isn't getting it right. "Turning off GC" means that you will
potentially run out of memory, which is probably even more dangerous
than garbage collecting for a little while. "Tuning your application"
means that you are hacking around without knowing whether your code
actually has a bounded latency.
So which is it? If there were a commercial implementation of a
real-time GC for a general purpose language, I'd definitely like to
know about it. Otherwise, Eiffel doesn't seem to be any more suitable
than run-of-the-mill CommonLisp implementations for real-time
programming, which have lots of facilities for "tuning". In fact,
using facilities such as weak references and pools, I suspect that a
run-of-the-mill CommonLisp implementation might even be better suited
(relatively speaking) to real-time programming than Eiffel.
Thomas.
Lee Douglas Sailer
I programmed in Simula during the late 70s and early 80s.
I want to add one important point. While it is true that Simula offers classes
and objects, they are used in somewhat different ways than you might be
used to in C++, smalltalk, or one of the better OO languages 8-)
For example the Simset "class" is really more like a language extension.
If you "inherit" it, you get access to a number of features that aren't in
the base language.
The "quasi parallel" features are also very interesting. A method can
deactivate itself in the middle of a computation, and then be reactivated later
if the rest of the calulations are needed. Some might call Simula an Actor
language rather than an OO language.
Des....@bbs.actrix.gen.nz
> In article <1992Sep28.0...@actrix.gen.nz> Des....@bbs.actrix.gen.nz writes:
>
> But C++ is a poor compromise at best.
> It is not real OO.
>
> I'm really glad that C++ is a compromise between OO and non-OO
> facilities. If it weren't, it would be much less expressive and much
> less useful.
>
or not. If you do then in my opinion Eiffel is the most advanced
OO language.
If you want to allow free state access style programming that is a different
issue. The Eiffel approach is to separate these two paradigms.
In traditional procedural style programming you have global states
which are accesible from any module, a module can not protect itself
from the incursions of other modules.
The OO approach is quite different. Each object/module is responsible
for the access and management of its own state. No other object can
get in and alter its states without permission. At least this is the case
in Eiffel. It is not true in CLOS and it is only partially true in
Smalltalk, you may be surprised to hear ( a subclass may access the
state of a parent class) and it is arbitray in C++.
In C++ you have a confusion of these diametrically opposing state
management philosophies. Some variables may be global while others
may be protected by methods. This is not a clean state of affairs.
It is a confusion of responsibility. The whole philosophy of OO
is to place responsibility for each module's state in the hands
of the module itself. There is a new autonomy and independence
given to modules. They can get on with their own job without
worrying that other modules can come along and mess in their state
of affairs.
So we are not just talking about minor syntax issues.
This is a major change in th philosophy and politics of
software modules. You may not like this. You may think that
there are some areas of OO that are dubious, still under research
etc. Which I may even agree with you in some specific cases.
But the central policy of OO is tha assignment of responsibility
of state management to each object/module and no other module should burgle
its way in to change states by avoiding method interfaces.
This is what OO is really all about.
In C++ in it is quite simple to violate this basic cornerstone of
OO. In Eiffel it is totally impossible to violate it.
The Eiffel approach is better. If you want to mix modules from
these different paradigms, or other paradigms like logic programming
or some other approach, then you call such modules from Eiffel.
But they are treated as another world which this particular application has
a need to communicate with.
So you can call C from Eiffel ( and Eiffel from C ) for example.
Such external modules are considered to be part of the implementation rather
than the specification of an Eiffel class. You may chose to replace an
external module with a new one, a better algorithm for example. Such
an implementation change has no impact on the specification/interface of a
class at all. From a point of view of large scale systems such isolation
from localised change is a major improvement in the stability of an
industrial system. You can not guarantee such a robust evolution
of change with C++ because it is not a 100% OO. There is global data,
states can be altered by other modules without permission of the
owner of the state. It is a philosophical and political confusion.
> Look at the various platforms and judge for yourself.
> Decide what you need that suits you. Don't go on the
> number of licenses!
>
> I did; Eiffel didn't suit me.
I wonder if you are really following the OO philosophy at all.
Maybe you don't agree with it. Maybe you think it will not work
for your application. Perhaps, perhaps not.
If you have some complaints with a particular implementation of Eiffel
that is another issue. Some implementations are better than others in terms
of the environment and the libraries.
The implementations are improving all the time, providing better
environments.
If it is the language itself then I doubt if you are following
the OO philosophy in reality. In which case no OO language
will satisfy you.
Are you perhaps using another paradigm such as logic programming
or functional style programming? These two styles have not yet
be reconciled with OO fully. Maybe they never will. We will see.
Some people are trying to merge them with OO
others say they should be treated as separate worlds and communicate
with each other as required. For example there are people claiming
OO style Prologs. There are people attempting to merge some OO principles
with the functional styles of languages like ML. It is very early
days to see what will happen here. But I hope we are not going
to get a confusion of opposing paradigms which I think is the case
with C++. It may be possible to achieve harmony. I think that
Eiffels approach to treating the old freely accesible state styles
like C, Fortran etc as other worlds does give us a reasonable
harmony. C++ is not harmony it is discord.
Regards
--Des Kenny
Objective Methods Ltd
PO BOX 17356
Wellington
New Zealand
Phone: 64 4 476 9499
Des....@bbs.actrix.gen.nz
> There are algorithms for Garbage Collection which use a second processor.
> I believe the Symbolics did this, and that it was responsible for much
> of their superior performance. Further, adding physical memory can be
> used to provide a "reserve buffer" for extremely busy times in an RT
> environment.
>
> Multi-processor systems are easy and cheap. Rather than spend a lot of
> time arguing about the SW design, and then immense manpower making the
> resulting RT system work, this one can be solved by an extra processor
> and 16MB of memory (retail cost about $1800 today, less next year).
>
> The actual economics of systems are rarely considered in the CS
> or SW Engineering environments. I see this same inability to consider
> economics in many companies : Often, they could save $1M in engineering
> by adding $200 in extra hardware. Most don't sell 5000 systems, so
> it would be a big win. Even if they sell more, costs decline and the
> $200/system is spent in manufacturing AFTER the product is selling.
>
> Now, someone will tell me that they system can still run out of memory,
> that all this design approach has done is to reduce the probability
> of doing so. Right. All RT systems eventually run out of some resource,
> so the designer must be able to detect these conditions and shed load before
> the system becomes unstable from the load. This is another practical
> approach they don't teach you in school, one which is crucial in any
> kind of life-critical RT system.
>
> Sorry if I brought a different reality into the conversation 8^).
>
I agree with this perspective. In a real time situation you can
not take for granted that the entire system design is going
to be a standard commercial computer.
You are at the limits. You have to adjust your viewpoint accordingly.
Things in general behave strangely when we reach the boundaries of any
system, computer or otherwise.
For example at Advanced Robotics Research Limited in U.K. they
are building this mobile Robot , weighing 1/3 of a ton.
The response time has to be of the order of 20 ms.
Clearly it is safety critical.
So they are not using the general run of the mill hardware
or even OS.
They are using Transputers and fast data paths ( 200 MB/S).
The application programming is being done in Eiffel.
Another example is at CEBAF, The Continuous Electron Beam Accelerator
Facility in the U.S.
"CEBAF is an electron accelerator with an energy of 4 GeV/c scheduled for
completion in 1994.
It is designed to allow the the detailed investigation of the quark
structure of the nucleus and will support several experiments operating
simultaneously at three end stations."
see TOOLS USA, August '92, Prentice Hall.
The hardware is custom built. It will be required to support a 10KHz event
rate with up to 10 KBytes per event.
So we are looking at a sensitivity of 0.1 ms to trap events.
This is real time enough. I guess it could be safety critical 4 GeV/c
sounds like a lot of juice to let run wild.
The hardware has fast data paths ( FASTBUS) , an Event Builder module
and a Processor Farm , all connected to workstations and a host.
The application software is written in Eiffel.
Hard real time , almost always means a serious look at the entire system
Hardware and Software.
-- Des Kenny
Objective Methods Ltd
Des....@bbs.actrix.gen.nz
>
> It is a safety critical application. A runaway 1/3 of a ton robot is
> no joke!
>
> It is using four T800 Transputers and two datalinks that have transfer rates
> of 200MB/second.
>
> So this is real time with Eiffel. I do not know how exactly
> they are using the garbage collector. I will let you know when I find out.
> But you can be sure that they can not afford a memory seizure of a mobile
> 1/3 ton beastie!
>
> They have a spectrum of choices from no garbage collection, to tuned
> collection to full system default collection. It will be very interesting to
> see how they are approaching this issue.
>
> Assume I have a program that never has more live data than, say, 45%
> of real memory. Does your Eiffel implementation guarantee that every
> request for memory has a small bounded latency, and does it guarantee
> at the same time that my program will never run out of memory?
>
memory. You have to calibrate this particular application
in a given context.
> I am all for GC, even in real-time applications. Furthermore, you can
> do real-time GC "right", meaning, you can guarantee (small) bounded
> latencies for all operations that would have bounded latencies in the
> absence of GC.
>
This is going to depend on the application and the resources
in a particular context. You have to allow enough hardware
to compensate for the fact that you can not make a perfect
prediction of exactly what resources are going to be required
during the entire run time of an application.
> isn't getting it right. "Turning off GC" means that you will
> potentially run out of memory, which is probably even more dangerous
> than garbage collecting for a little while.
Yes. I was merely saying that this is an option on the spectrum
of choices for any application. In real time it would be clearly
an undesireable choice.
> "Tuning your application"
> means that you are hacking around without knowing whether your code
> actually has a bounded latency.
I am not sure why you say this. If you calibrate the application
in a context of resources available you would be able to
measure resources consumed over time and time delays in response
to requests for system resources.
If you have calibrated these resource usages and response delays
and you have allocated sufficient hardware to account for
the extreme cases, I am not sure that there is an unsolvable
problem here.
You can then decide when are the best times to do partial garbage
collection and how long the collection interval should be.
I never said this was easy. But then real time is not easy.
> So which is it? If there were a commercial implementation of a
> real-time GC for a general purpose language, I'd definitely like to
> know about it.
I suggest you contact ISE for the details of the GC in the
new version of Eiffel (3.0). I do not know what SIG is doing
about this. Sather from Berkley has been targetted at real time.
It is a derivative of Eiffel. I do not know exactly how they are
handling GC.
Otherwise, Eiffel doesn't seem to be any more suitable
> than run-of-the-mill CommonLisp implementations for real-time
> programming, which have lots of facilities for "tuning". In fact,
> using facilities such as weak references and pools, I suspect that a
> run-of-the-mill CommonLisp implementation might even be better suited
> (relatively speaking) to real-time programming than Eiffel.
There are other reasons why CLOS does not suit my requirements.
It is too unsafe in its class interface: you can not restrict
access to attributes ( state ) to methods of the class.
So any other class can get into the state and alter it, by-passing
the OO principle of only allowing access via a classes own methods.
Also static type checking is not enforced. I prefer static type
checking for large scale industrial applications. I do not want to discover
a type error at run time! There are some applications such as small scale
prototypes/experiments/research where static type checking is not a
significant issue. However, in the industrial setting we need all the help
we can get from the tools to reduce the error rate in systems with finite
budgets and impatient users. Now these are REAL resource constraints
in industry.
Des....@bbs.actrix.gen.nz
4 GV would be big but eV is actually quite small : 1.6 * 10 ** -19 joule.
So the energy is very small.
4 * 10 ** 9 * 1.6 * 10 ** -19 j / 3 * 10 ** 8 m s** -1 is about
10 ** -18 js m** -1
Tony Wen Hsun Lai
>In comparison to Eiffel I would like to know:
>
>Does Modula-3 have inheritance/multiple inheritance?
>
>Which leads to the question does Modula-3 have
>polymorphism and dynamic binding?
>
>Is the garbage collector an incremental one , operating as a coroutine.
>Can the garbage collector be tuned from a running system, so that
>the collection frequency and period is managed by an application or a user.
>Although is really an issue of an environment rather than the language
>per se. I agree it is certainly important.
Um, I think Modula-3 has (single) inheritance, polymorphism, and dynamic
binding. Traced types are automatically garbage collected, and untraced
types must be allocated and deallocated by the programmer.
Mike Khaw
> Before this capability Smalltalk had some advantage over Eiffel in the speed
> of the turn around from change to testing. No one really likes
> waiting around for a compiler to test a change. In prototyping
> this can be a real drag. But now Eiffel can compete with Smalltalk in this
> area also. In fact it can be faster than Smalltalk in some applications
> because you only interpret the limited area you are changing. The rest of
> the classes are running at the speed of compiled code! That suits me
> very nicely.
> nice.
Ahem. One more time: compiled vs. interpreted is no more a language
property of Smalltalk than it is of Eiffel. There are interpreted
implementations of Smalltalk. ParcPlace Smalltalk is not interpreted.
It uses a hybrid approach that ParcPlace terms "dynamic translation".
For those unfamiliar with it, here's how it goes: When you define a
method, the Smalltalk system converts it to bytecode (an intermediate
representation). An interpreter implementation would interpret the
bytecodes when this method is invoked. In ParcPlace Smalltalk, when
this method is invoked, the running system first checks to see if the
native machine code translation of the bytecodes is already present in
an in-memory cache. If so, that native code executes directly from the
cache with no interpretation overhead, "at the speed of compiled code"
(to quote Des Kenny). If the native code representation is not in the
cache, there is a slight overhead of translating the bytecode
representation and then caching it. In general, this is a significant
win because empirical observation shows that methods once called tend
to be called again. In addition, bytecode is a much more compact
representation than native machine code (approx. 5-10 times, depending on
whether the processor is CISC or RISC), so keeping the bulk of the
system as bytecodes significantly reduces demands on memory.
Additionally, bytecodes are machine independent, so running Smalltalk
images can be saved to disk and moved to different platforms and
launched w/o explicit recompilation; i.e., ParcPlace Smalltalk images
are binary portable among platforms.
Now, I'm not saying that this makes Smalltalk faster than Eiffel.
I haven't used Eiffel, so I have nothing to say about comparing the
performance of the 2.
> So you can use Smalltalk for industrial applications but you are taking
> very big risks. Most businesses like to minimise their exposure to risk
> if they want to stay in business. Of course , this is an individual
> judgement.
Gee, I guess ParcPlace's customers, which includes large corporations,
either are big risk takers or else they find Smalltalk to be adequately
safe.
--
Michael Khaw Domain=kh...@parcplace.com, UUCP=...!uunet!parcplace!khaw
ParcPlace Systems, Sunnyvale, CA PRODUCT INFO: in...@parcplace.com
garry hodgson
>In article <23...@alice.att.com> ga...@alice.UUCP () writes:
>
>>[ Many lines of Eiffel cheerleading,
>> including lots of interesting technical aspects, deleted ]
>
>[...]
>
>
>
>
>Hold on everyone. PLEASE lets not have a language war.
I had no intention of holding a language war. In fact, Eiffel
sounds very interesting to me. I am not currently in a position
where I can use it, but that does not mean I cannot or will not
see its merits.
I was merely objecting to the tone in a previous post, and
the nonsense I am often subjected to here, that C++ is not
*real* OO, and that there is something inherently deficient
in those who would use it.
--
Garry Hodgson A slow winter day
AT&T Bell Labs A night like forever
ga...@alice.att.com Sink like a stone
att!alice!garry Float like a feather
Richard Bielak
[...]
>
>Don't you mean to say "As far as lots of OO languages are concerned..."
>Eiffel is not unique in being used as a host language to test ideas on
>synchronisation.
>
>Of the proposals I have seen for synchronisation mechanisms, for
>whatever language, none are perfect. We (people doing research in this
>area) have been making great progress over the last few years but don't
>expect any OO language, Eiffel included, to have a wonderful
>synchronisation mechanism "real soon now."
One very neat idea for synchronization was proposed by D. Caromel. He
called it "wait-by-necessity" (also called "lazy wait"). The idea is
that an thread will have to wait for a result of concurrent
computation, only at the point where it is needed. In Eiffel syntax:
x := obj1.compute_something; -- this starts asynch computation
... -- continue execution here, without references to 'x'
x.last_computed; -- now that we need the result, we may have to
-- wait for it
[...]
>
>One major problem I see with any synchronisation mechansism for Eiffel
>which tries to support internal concurrency is the conflict between
>internal concurrency and the evaluation of pre/postconditions. (What are
>the semantics for evaluating pre/postcondition when instance variables,
>which they access, are being updated by a thread executing an operation
>of the object?) From my reading, it seems that CEiffel doesn't address
>this issue. (I haven't read the paper by Karaorman & Bruno so I don't
>know if they have a solution for this.)
>
Regarding the pre- and post-conditions, I thought of the following way
of dealing with this problem.
You can divide features of a class into "querries" and "commands".
Querries only read the object's attributes and return some value.
Commands modify the object.
So, multiple querries can run at the same time and the pre- and post-
conditions will be fine. However, commands can only be executed one at
a time.
This is very similar to the idea of locks in a database. When an
object in a database is "read" locked many people can read it at the
same time. But to modify the object, you have to get an exclusive
"write" lock.
...richie
--
* Richie Bielak (212)-815-3072 | *
* Internet: ric...@bony.com | Rule #1: Don't sweat the small stuff. *
* Bang {uupsi,uunet}!bony1!richieb | Rule #2: It's all small stuff. *
* - Strictly my opinions - | *
Matt Kennel
: In article <TMB.92Se...@arolla.idiap.ch> t...@idiap.ch writes:
: > In article <1992Sep28.0...@actrix.gen.nz> Des....@bbs.actrix.gen.nz writes:
: >
: > But C++ is a poor compromise at best.
: > It is not real OO.
: >
: > I'm really glad that C++ is a compromise between OO and non-OO
: > facilities. If it weren't, it would be much less expressive and much
: > less useful.
: >
: You need to make up your mind. Do you want to use the OO approach
: or not.
This is unnecessarily dogmatic.
: If you do then in my opinion Eiffel is the most advanced
: OO language.
Well, maybe "Eiffel is the most object-oriented advanced language".
: If you want to allow free state access style programming that is a different
: issue. The Eiffel approach is to separate these two paradigms.
: In traditional procedural style programming you have global states
: which are accesible from any module, a module can not protect itself
: from the incursions of other modules.
:
: The OO approach is quite different. Each object/module is responsible
: for the access and management of its own state. No other object can
: get in and alter its states without permission. At least this is the case
: in Eiffel. It is not true in CLOS and it is only partially true in
: Smalltalk, you may be surprised to hear ( a subclass may access the
: state of a parent class) and it is arbitray in C++.
:
: In C++ you have a confusion of these diametrically opposing state
: management philosophies. Some variables may be global while others
: may be protected by methods. This is not a clean state of affairs.
Real life isn't always clean.
The real question, does it help me write good programs? Does it help
my successor change my programs?
Sometimes you need to change somebody's state. If it can be done,
it will be done, but if your language is anal-retentive, you'll have to
fight it to do what needs to be done.
You'll end up either creating a useless dummy object, just so that you
can call one of its methods, even though the object itself has no meaning,
or you'll end up creating useless methods that you only use in one
place somewhere totally different in the code. You end up creating
spurious new names and complexity that can only clutter up your overworked
and undercaffeinated brain. (:-))
I *hate* it when I have to fight the language to do something simple.
(For example, if you want to return multiple values in most langauges,
for example in C, you end up having to create a structure whose purpose
in life is only to encapsulate all the return values in a single bundle,
but which otherwise has no purpose. That's needless confusion and
complexity).
: It is a confusion of responsibility. The whole philosophy of OO
: is to place responsibility for each module's state in the hands
: of the module itself. There is a new autonomy and independence
: given to modules. They can get on with their own job without
: worrying that other modules can come along and mess in their state
: of affairs.
I agree that this is often beneficial.
But why should this one thing be the cornerstone of modern programming?
I think there are other issues. Such as making things clear, simple, and work.
:
: So we are not just talking about minor syntax issues.
: This is a major change in th philosophy and politics of
: software modules. You may not like this. You may think that
: there are some areas of OO that are dubious, still under research
: etc. Which I may even agree with you in some specific cases.
:
: But the central policy of OO is tha assignment of responsibility
: of state management to each object/module and no other module should burgle
: its way in to change states by avoiding method interfaces.
: This is what OO is really all about.
:
: In C++ in it is quite simple to violate this basic cornerstone of
: OO. In Eiffel it is totally impossible to violate it.
The bigger problem with C++ is more the C problem, that pointers can point
anywhere, and trash anything.
:
: The Eiffel approach is better. If you want to mix modules from
: these different paradigms, or other paradigms like logic programming
: or some other approach, then you call such modules from Eiffel.
: But they are treated as another world which this particular application has
: a need to communicate with.
:
: So you can call C from Eiffel ( and Eiffel from C ) for example.
: Such external modules are considered to be part of the implementation rather
: than the specification of an Eiffel class. You may chose to replace an
: external module with a new one, a better algorithm for example. Such
: an implementation change has no impact on the specification/interface of a
: class at all. From a point of view of large scale systems such isolation
: from localised change is a major improvement in the stability of an
: industrial system. You can not guarantee such a robust evolution
: of change with C++ because it is not a 100% OO. There is global data,
: states can be altered by other modules without permission of the
: owner of the state. It is a philosophical and political confusion.
Yes, but this is overblown. What ends up happening is that you end
up creating methods that alter the such and such state.
Then the problems just devolves into "Well who called that method when
i wasn't looking". Same basic problem, but now it's been laundered into
something virutous by a function call. BFD.
In sum, I think programming languages should help programmers first, and not
be a philosophical manifesto. (Is this a subject-oriented language?)
By the way, I guess I must be somewhat of an Eiffel fan, because I hate
C++, and am getting more and more pleased with Sather. I haven't yet
written a single kludge in it yet, but i'm sure the time will be coming
at some point.
: Regards
: --Des Kenny
: Objective Methods Ltd
--
-Matt Kennel m...@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-*** lyapunov.ucsd.edu, username "anonymous".
Nadja Adolf
But the byte codes must be interpreted if they aren't in the cache.
This still adds overhead over complete compilation. But there are also
C++ implementations that use some level of interpretation. I tend to
avoid them.
Admittedly, the caching does make it faster than complete interpretation,
but it is still significantly slower than a compiled language. The more
complex the program, the greater the difference.
Richard Bielak
[...]
> I happen to agree that Smalltalk is a higher risk language for
> industrial applications. There is no static type checking. I do not want to
> find out at run time that there are type errors in the system!
> There are enough other types of errors to contend with, not to mention
> budget and time constraints, without having to deal with highly confused
> users confronted with a type error and some wierd system message
> that terrifies them that they just lost a days work!
>
What about C or COBOL? I would say that the risk in using those is
greater in using than in using SmallTalk. Is "segmentation fault" a
friendlier message? :-)
[...]
>
> Before this capability Smalltalk had some advantage over Eiffel in the speed
> of the turn around from change to testing.
One thing that I like in Smalltalk that is not present in Eiffel is
the ability to treat code (i.e. blocks) as objects.
[...]
>
> Eiffel does not deny the right of the older style to exist.
> It simply treats it as a separate world. This is much cleaner
> and easier to comprehend, learn and manage. Eiffel can call external
> C/C++ modules. Also Eiffel objects can be called from C and I guess
> from C++. So we have a neat path for evolution into a new paradigm
> The old C/C++ code can be reused as long as it is useful by encapsulating
> it with Eiffel classes.
Well, I'm not so sure it's that easy to call C++ from Eiffel. First of
all you'd need to find out all those mangled names of C++ routines,
never mind the setup that the C++ compiler does before invoking the
main. This is not just a problem with Eiffel, you'd have the same
problem if you were using C.
I guess a solution would be to use a C++ compiler on the output of
Eiffel compiler.
The other directions work fine (i.e. call Eiffel from C++ or C).
Larry Smith
>In article <1992Sep28.0...@actrix.gen.nz> Des....@bbs.actrix.gen.nz writes:
>>died in the wool C programmers who are scared to
>>venture to far from the nice little C hole they have
>>dug theselves.
>Yeah, I just spend all day cringing in my office, uh, hole, praying
>I will never have to learn anything or have an original thought again.
>Pssst. Don't tell my management.
Don't be so quick to be so sarcastic, Garry, you may well be an exception.
I've worked with oo systems for years and have dealt with (and implemented)
a number of oo languages, but my bread-and-butter is C++ and I've seen it
up close and personal in several environments, and I have to agree with Kenny's
opinion. C++ _does_ permit programmers to be lazy with respect to designing
object-oriented systems, and although it is possible to write clean, modern,
object-oriented systems in C++ I've yet to see anyone do so. The reason is,
I believe, because too many people just see it as an extended C, and refuse to
make that paradigm shift to object-oriented thinking. A great many programmers
_don't_ have original thoughts, and _are_ scared to venture into new territory.
That's is normal human nature, and it occurs in programmers quite a lot more
than we like to admit.
I've even seen piles of code written using C++ object which was "object
oriented" only by courtesy - the objects were not well thought out, the
hierarchies were a bad joke and the objects kept mutating for revision after
revision. Now, a lot of this is just plain bad design in general - but it is
certainly true that permitting good design is not the same as encouraging it.
C++ provides little encourgement to move to modern software design, and I've
see retread C coders to terrible things with it.
John Reekie
>
> For example at Advanced Robotics Research Limited in U.K. they
> are building this mobile Robot , weighing 1/3 of a ton.
> The response time has to be of the order of 20 ms.
>
> Clearly it is safety critical.
> So they are not using the general run of the mill hardware
> or even OS.
> They are using Transputers and fast data paths ( 200 MB/S).
> The application programming is being done in Eiffel.
I'm curious about how exactly Eiffel fits into the transputer
environment. Since Eiffel does not (yet) support concurrency
directly in the language, is multi-tasking achieved by using
explicit process creation and communications calls to the underlying
hardware? Is there a Transputer-specific Eiffel, or is the output
from a UNIX or PC implementation compiled on a Transputer
C compiler?
Regards
John Reekie
Nadja Adolf
>In article <1992Oct1.0...@jetsun.weitek.COM> na...@jetsun.weitek.COM (Nadja Adolf) writes:
>>In article <khaw.71...@parcplace.com> kh...@parcplace.com (Mike Khaw) writes:
>>>
>>>Ahem. One more time: compiled vs. interpreted is no more a language
>>But the byte codes must be interpreted if they aren't in the cache.
>>This still adds overhead over complete compilation. But there are also
>>...... other stuff ...
>>Admittedly, the caching does make it faster than complete interpretation,
>>but it is still significantly slower than a compiled language. The more
>>complex the program, the greater the difference.
>Two of the biggest knocks on smalltalk are speed and size. These are
>real concerns in real business situations and get right to the heart of
>cost per seat. In large organizations this will make a difference.
Amen. That's why I note that the caching is faster than complete interpreta-
tion, but is still slower. And that and the size make it unusable for
what I am trying to do.
>IMHO the cache scheme of Parc may be overblown as a real world speed up.
>It will depend on the application.
Yep.
>In looking at smalltalk code I can readily see many areas that need rework
>in the basic classes. Many of the methods in smalltalk are
>implemented in an inefficient manner that impacts iterative use.
Yep. I'd also like to see some easy look and feel kits so that smalltalk
applications could look 'native.'
> Craig
>
>--
>Craig Shaver (csh...@informix.com for now) (415)390-0654 (415)926-6407
>Productivity Group POB 60458 Sunnyvale, CA 94088
Des....@bbs.actrix.gen.nz
> In article <1992Oct1.0...@jetsun.weitek.COM> na...@jetsun.weitek.COM (Nadja Adolf) writes:
> >>
> >>Ahem. One more time: compiled vs. interpreted is no more a language
> >
> >But the byte codes must be interpreted if they aren't in the cache.
> >This still adds overhead over complete compilation. But there are also
> >Admittedly, the caching does make it faster than complete interpretation,
> >but it is still significantly slower than a compiled language. The more
> >complex the program, the greater the difference.
> >
> real concerns in real business situations and get right to the heart of
> cost per seat. In large organizations this will make a difference.
>
> It will depend on the application.
>
> in the basic classes. Many of the methods in smalltalk are
> implemented in an inefficient manner that impacts iterative use.
>
in this context.
In addition to the time it takes to edit a module of an application
and test the result. There are also other important software engineering
issues for large systems in industry to consider.
In ISE Eiffel 3 we still have static type checking even with an
interpreter/compiler mix. This may be more important for the quality
of a system in the longer term. Rapid development of modules with
no static type checking may risk type failure in production. So what
is really rapid about having to fix type errors at the production stage?
I am sure there are some Smalltalk developers who rarely allow type
errors into production. But is it not better to let these errors be
eliminated by the development tool before production? I prefer the
environment to help me as much as possible with quality assurance
as early as possible in the lifecycle.
Stefan Monnier
object-orient.. Thomas M. Breuel@arolla. (3014)
> What you are arguing for is opacity. Opacity can be achieved in many
> programming languages, including C and C++, without even ever using
> any OO techniques. That is, you can define a datatype in C/C++ such
> that you are guaranteed that no user of that datatype manipulates it
> without going through the interface that has been provided by the
> author of the datatype.
Sorry, it must be an error:
You seriously mean you can write code so that noone can use your datatype
directly ?
Show me how !
> Thomas.
Stefan
-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
nicholas.hounsome
stuff deleted
>>
>> Eiffel does not deny the right of the older style to exist.
>> It simply treats it as a separate world. This is much cleaner
>> and easier to comprehend, learn and manage. Eiffel can call external
>> C/C++ modules. Also Eiffel objects can be called from C and I guess
>> from C++. So we have a neat path for evolution into a new paradigm
>> The old C/C++ code can be reused as long as it is useful by encapsulating
>> it with Eiffel classes.
>
> Well, I'm not so sure it's that easy to call C++ from Eiffel. First of
> all you'd need to find out all those mangled names of C++ routines,
> never mind the setup that the C++ compiler does before invoking the
> main. This is not just a problem with Eiffel, you'd have the same
> problem if you were using C.
>
> I guess a solution would be to use a C++ compiler on the output of
> Eiffel compiler.
>
Anything that can call C can call C++ because C++ provides a mechanism
for defeating its mangling system ( extern "C" ). The only drawback
being that C++ will always look like C to Eiffel i.e. There is no way that
it can handle C++ objects or call their methods directly.
>
> The other directions work fine (i.e. call Eiffel from C++ or C).
>
>
> ...richie
>
>
>
> --
> * Richie Bielak (212)-815-3072 | *
> * Internet: ric...@bony.com | Rule #1: Don't sweat the small stuff. *
> * Bang {uupsi,uunet}!bony1!richieb | Rule #2: It's all small stuff. *
> * - Strictly my opinions - | *
Nick Hounsome
AT&T Network Systems UK
Eric Nedervold
>In article <1992Sep29....@actrix.gen.nz> Des....@bbs.actrix.gen.nz
writes:
>One thing that I like in Smalltalk that is not present in Eiffel is
>the ability to treat code (i.e. blocks) as objects.
I'm only an Eiffel and Smalltalk fan, never having gotten my hands on a
system for either, but it seems that there are a number of situations where
a CodeObject would be useful in Eiffel (simulating procedure-valued variables
in Modula-2, etc.). It seems easy to construct: a virtual class with a
single feature Do. This defines the abstract class and to instantiate it,
you build subclasses. It *is* grungier than just putting brackets around
the code like Smalltalk, but it seems equally functional.
Is it just the grunginess that is the problem, or does my lack of Smalltalk
experience cause me to miss a more subtle issue?
--Eric
Bill Maniatty
|> Excerpts from netnews.comp.lang.eiffel: 2-Oct-92 Re: comparing
|> object-orient.. Des....@bbs.actrix.gen (2292)
|> > I guess we are talking about specific implementations of a language
|> > in this context.
|>
|> > In addition to the time it takes to edit a module of an application
|> > and test the result. There are also other important software engineering
|> > issues for large systems in industry to consider.
|>
|> > In ISE Eiffel 3 we still have static type checking even with an
|> > interpreter/compiler mix. This may be more important for the quality
|> > of a system in the longer term. Rapid development of modules with
|> > no static type checking may risk type failure in production. So what
|> > is really rapid about having to fix type errors at the production stage?
|> > I am sure there are some Smalltalk developers who rarely allow type
|> > errors into production. But is it not better to let these errors be
|> > eliminated by the development tool before production? I prefer the
|> > environment to help me as much as possible with quality assurance
|> > as early as possible in the lifecycle.
|>
|>
|> done for pleasure: customer generally wants to see a working
|> prototype of the application to be sure it can be done, to see how
|> it's gonna work and so on.
|> Static type checking makes it harder to develop code in limited
|> time (prototype doesn't have to be bug free, nor fast, nor complete)
We have a trade off between quick turnaround and correct implementation.
I suspect correct implementation is much more important, as most
software costs are fixing design and implementation errors.
Do you realize how disasterous it is to have a prototype crash in front
of the customer? A prototype must be sufficiently robust to gain the
customer's confidence in the developer. (Of course demo for insiders is
much more relaxed, but it is still quite embarassing).
|>
|> What is needed is a language that permits you to write 'free code'
|> (without too much verification done by the language) to start
|> fast and get a working prototype in very short time. And then
|> add type constraints (etc...) to get to a 'bug-free' (grin) stable
|> application.
When the programmer makes type errors, there is a serious semantic error
in the source code. The whole point behind a rigorous type checking system
is that the programmer is notified immediately about the semantic errors, and
can fix them on the spot, rather than at some convenient time like, ... never.
Please consider the rate of turnover of programmers, and that even if the
programmer that originally wrote the code is the one to fix it, that most people
cannot remember details for any length of time. It is much more costly to
fix things later in the development cycle. Also remember that while the error
is waiting to be fixed, other code has been built which might integrate
with the damaged software.
|>
|> Sure debugging is easier with static type checking, but this help
|> sometimes turns out to be a hassle: it should be possible to turn
|> it off (completely or partly)
Early detection of errors in the development cycle reduces the number of reworks,
and the cost of reworks.
|>
|> I'm sure this kind of Smallfel (or is it Eifftalk ?) is coming
|> and will be very nice (I like to dream, you know)
I strongly suspect that rigorous type checking at compile time is the way
to go. Of course, life is full of exceptions, so there should be a way
to explicitly disable the type checker for small regions of code.
|>
|> Stefan
Bill
--
|
| mani...@cs.rpi.edu - in real life Bill Maniatty
|
Stefan Monnier
object-orient.. Des....@bbs.actrix.gen (2292)
> in this context.
> In addition to the time it takes to edit a module of an application
> and test the result. There are also other important software engineering
> issues for large systems in industry to consider.
> In ISE Eiffel 3 we still have static type checking even with an
> interpreter/compiler mix. This may be more important for the quality
> of a system in the longer term. Rapid development of modules with
> no static type checking may risk type failure in production. So what
> is really rapid about having to fix type errors at the production stage?
> I am sure there are some Smalltalk developers who rarely allow type
> errors into production. But is it not better to let these errors be
> eliminated by the development tool before production? I prefer the
> environment to help me as much as possible with quality assurance
> as early as possible in the lifecycle.
Getting a working application in a limited time is not just
done for pleasure: customer generally wants to see a working
prototype of the application to be sure it can be done, to see how
it's gonna work and so on.
Static type checking makes it harder to develop code in limited
time (prototype doesn't have to be bug free, nor fast, nor complete)
What is needed is a language that permits you to write 'free code'
(without too much verification done by the language) to start
fast and get a working prototype in very short time. And then
add type constraints (etc...) to get to a 'bug-free' (grin) stable
application.
Sure debugging is easier with static type checking, but this help
sometimes turns out to be a hassle: it should be possible to turn
it off (completely or partly)
I'm sure this kind of Smallfel (or is it Eifftalk ?) is coming
and will be very nice (I like to dream, you know)
Stefan
Joshua Levy
>> What you are arguing for is opacity. Opacity can be achieved in many
>> programming languages, including C and C++,
Stefan Monnier <osoelga...@CMU.EDU> replied:
>Sorry, it must be an error:
>You seriously mean you can write code so that noone can use your datatype
>directly ?
Its easy to do. Usually, you lie. You define a structure in a .h file,
called for example stack_t. But you give everyone else a different .h
file which defines stack_t to be void, or an array of characters, or
something else which does not describe the inside structure. The only
way to manipulate the data is by calling the routines you have written
with your (real) .h file.
BTW: I've used this in a commercial product (at a different company).
I'm not saying this is a good idea. It defininately messes up debugging,
and you need to be careful how you compile and link various parts of
your code. But it can work.
Joshua Levy (jos...@veritas.com)
Thomas M. Breuel
Excerpts from netnews.comp.lang.eiffel: 1-Oct-92 Re: comparing
object-orient.. Thomas M. Breuel@arolla. (3014)
> What you are arguing for is opacity. Opacity can be achieved in many
> programming languages, including C and C++, without even ever using
> any OO techniques. That is, you can define a datatype in C/C++ such
> that you are guaranteed that no user of that datatype manipulates it
> without going through the interface that has been provided by the
> author of the datatype.
Sorry, it must be an error: You seriously mean you can write code
so that noone can use your datatype directly ? Show me how !
Usual C approach (frob.h):
typedef struct _frob *frob;
frob frob_make();
void frob_destroy(frob);
int frob_extract_some_field(frob);
void frob_add_something(frob,int);
Note that there is no definition for "struct _frob" around. In fact,
the only place that definition would be given would be inside the
file(s) that define the above functions. Without knowing the actual
definition, you can't access the internal representation of a "frob".
Usual FORTRAN approach (albeit, also written in C):
typedef int frob;
frob frob_make();
void frob_destroy(frob);
int frob_extract_some_field(frob);
void frob_add_something(frob,int);
Essentially, a "frob" is an offset to some internal table inside the
"frob" library. This absolutely guarantees that you can't get at the
representation of a "frob" without going through the defined
interface; not even guessing and casting will help you. Sadly, you
lose static type checking this way. On the other hand, this kind of
interface is easier to use if you mix languages.
Thomas.
PS: Some people like to quibble that the "C" approach lets you get at
the bits of a frob via casting. Note that this is not a problem with
the "FORTRAN" approach. If you absolutely want to make sure that
casting doesn't work _and_ you want static type checking, you can
combine the two and have "struct _frob" contain an internal offset.
Nadja Adolf
>Excerpts from netnews.comp.lang.eiffel: 2-Oct-92 Re: comparing
>object-orient.. Des....@bbs.actrix.gen (2292)
>> In ISE Eiffel 3 we still have static type checking even with an
>> interpreter/compiler mix. This may be more important for the quality
>> of a system in the longer term. Rapid development of modules with
>> no static type checking may risk type failure in production. So what
>> is really rapid about having to fix type errors at the production stage?
>> I am sure there are some Smalltalk developers who rarely allow type
>> errors into production. But is it not better to let these errors be
>> eliminated by the development tool before production? I prefer the
>> environment to help me as much as possible with quality assurance
>> as early as possible in the lifecycle.
>Static type checking makes it harder to develop code in limited
>time (prototype doesn't have to be bug free, nor fast, nor complete)
The prototype should at least be stable and predictable. In my experience
code that does not have strict type checking can be prototyped very
quickly. Then one can spend years trying to stabilize it, since 'free
code' bugs can be hard to isolate.
IMNHAAO, the absence of type checking does not lead to faster product
development. The time saved in getting the prototype up is more than
counterbalanced by the time required to stabilize the product.
>What is needed is a language that permits you to write 'free code'
>(without too much verification done by the language) to start
>fast and get a working prototype in very short time. And then
>add type constraints (etc...) to get to a 'bug-free' (grin) stable
>application.
A stable application is far from a bug free application. Unless you
have exhaustively designed regressions from the moment you began to
code, the process of debugging and correcting the program is going
to be very time consuming. If one intends to set type constraints later,
one should consider setting them initially. If one does not, then both
the regression code and the product must essentially be rewritten.
>Sure debugging is easier with static type checking, but this help
>sometimes turns out to be a hassle: it should be possible to turn
>it off (completely or partly)
>
>I'm sure this kind of Smallfel (or is it Eifftalk ?) is coming
>and will be very nice (I like to dream, you know)
>
> Stefan
>
>-----------------------------------------------------
>-- On the average, people seem to be acting normal --
>-----------------------------------------------------
Thomas M. Breuel
>Static type checking makes it harder to develop code in limited
>time (prototype doesn't have to be bug free, nor fast, nor complete)
In my experience, static type checking _in a polymorphic type system
with type inference_ makes it easier and faster to get code working;
it doesn't make it harder. As an added bonus, it does help reduce the
frequency of bugs, and it does help make your code run faster.
If you don't have a polymorphic type system with type inference, then
I agree that static type checking is a bother.
Thomas.
John MAX Skaller
>but it is still significantly slower than a compiled language. The more
>complex the program, the greater the difference.
This need not be the case. The small code sizes may reduce
the overheads of loading machine code from virtual memory if the byte
codes are interpreted.
Secondly, delayed binding can be delayed even further in
interpreted systems than compiled ones (even if this isnt the case
in Smalltalk, it certainly is in other interpreted languages
like Postscript and TeX) and the mechanism to implement the
same functionality in the compiled system may be just an
expanded version of the same thing---which might even run slower
as well, being compiled by an 'optimising' compiler instead
of executed by a hand crafted interpreter.
The IBM PL/1 compiler used to use a hybrid compiled/interpreted
scheme I believe. I think some of the IO operations, and some
of the picture formating was interpreted.
--
;----------------------------------------------------------------------
JOHN (MAX) SKALLER, max...@extro.ucc.su.oz.au
Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Ralf Jungclaus
>Getting a working application in a limited time is not just
>done for pleasure: customer generally wants to see a working
>prototype of the application to be sure it can be done, to see how
>it's gonna work and so on.
>Static type checking makes it harder to develop code in limited
>time (prototype doesn't have to be bug free, nor fast, nor complete)
>
As I understand the process of software development in practice, the
prototype (having been validated by the customer) is taken and you put
some nice user interface on top of it and that's it. Do you really
want a prototype to have severe errors when it is presented to the
customer with such a perspective in mind?? I wouldn't want to.
>What is needed is a language that permits you to write 'free code'
>(without too much verification done by the language) to start
>fast and get a working prototype in very short time. And then
>add type constraints (etc...) to get to a 'bug-free' (grin) stable
>application.
>
OK, that really might help in some cases. But it should be an
*exception*, not the usual case, and thus there shouldn't be a
compiler option but a language feature to turn it off for just an
exceptional case ...
BUT anyway, prototyping should take place on a very high level of
abstraction, i.e.\ we should take a conceptual model or an
object-oriented *specification* and prototype it. If you have to
prototype a program, then it's either too late or you didn't invest
much work in the analysis and design phase --- but that's *absolutely
essential*!!
>Sure debugging is easier with static type checking, but this help
>sometimes turns out to be a hassle: it should be possible to turn
>it off (completely or partly)
And if you have some tool that supports the generation of code from a
specification, then you (hopefully) do not have to debug at all ....
(a bit idealistic, I know, but we're working on it ...)
Ralf
--
Ralf Jungclaus
Abt. Datenbanken | INTERNET: jung...@idb.cs.tu-bs.de
TU Braunschweig, P.O.Box 3329 | Voice: (..49/0)531-391-7443 or -7442
D-3300 Braunschweig, Germany | FAX: (..49/0)531-391-3298
David Quarrie
In article <1992Sep29.2...@actrix.gen.nz>,
Much as I'd like to agree with the above, I think I should point out that the
real-time aspects of the above system are not written in Eiffel. We did do some
studies to show that we could cross-develop Eiffel applications running on our
VxWorks real-time nodes involved in the actual data acquisition data flow, but
finally decided not to do the implementation using that technique. Thus Eiffel
is used only for the non time-critical sections (controlling the data
acquisition,
downloading modules and monitoring the status of the experiment and
accelerator)
but is not involved with actually moving the data through the system.
Our reasons
for not using Eiffel were basically concerns about garbage collection
with the
sometimes very limited physical memory in some of the readout
controllers and
maintenance of the cross-development environment (which involved
redefining the
C_COMPILER environment variable to point to the 68k cross-compiler and a
parallel
Eiffel installation etc.).
Given our successful experience using Eiffel for the non time-critical
sections,
we're re-evaluating that decision and might redo things so that only the
actual
readout of the hardware and RPC handling is in C. One factor in that
decision
will be the licencing policy for the Eiffel run-time library for a
cross-developed
target (which I believe will be different under Eiffel 3 than it was
under 2.3).
-------------------------------------------------------------------------------
David Quarrie CEBAF MS 12H
12000 Jefferson Ave
Internet: qua...@cebaf.gov Newport News VA 23606
DECnet : cebaf::quarrie Tel: (804) 249-7562
BITNET : quarrie@cebaf Fax: (804) 249-7363
Larry Smith
>You seriously mean you can write code so that noone can use your datatype
>directly ?
>Show me how !
It's not obvious, but it's pretty easy. To take a trivial example:
foo.h:
#ifndef FOO_H
#define FOO_H
#define FOO struct foo
FOO *init_foo(char *some_init_params); /* constructor */
void nuke_foo(FOO *foo_thing); /* destructor */
long inq_foo(FOO *foo_thing); /* various methods... */
void set_foo_name(FOO *foo_thing, char *name);
char *get_foo_name(FOO *foo_thing);
void do_foo_thing(FOO *foo_thing, char *some_arg);
#endif
That's all that goes in the header. Now the rest of it can go in the .c,
foo.c
#include "foo.h"
/* reveal data type */
FOO {
char *foo_name;
long foo_count;
char *mysterious_foo_thing;
} foo;
static global_foo_count = 0;
/* end reveal */
FOO *init_foo(char *some_init_params) {
FOO *result;
result = (FOO *)malloc(sizeof(FOO));
result->foo_count = global_foo_count++;
result->foo_name = 0;
result->mysterious_foo_thing = some_init_params;
return result;
}
void nuke_foo(FOO *foo_thing) {
if(foo_thing->mysterious_foo_thing) free(foo_thing->mysterious_foo_thing);
if(foo_thing->name) free(foo_thing->name);
free(foo_thing);
}
long inq_foo(FOO *foo_thing){
return foo_thing->foo_count;
}
void set_foo_name(FOO *foo_thing, char *name) {
if(foo_thing->name) free(foo_thing->name);
foo_thing->name = strdup(name);
}
char *get_foo_name(FOO *foo_thing) {
return foo_thing->name);
}
void do_foo_thing(FOO *foo_thing, char *some_arg) {
foo_thing->mysterious_foo_thing = some_arg;
}
If you don't want to be required to define all the methods of the data type
in the same .c file, abstract out the reveal data type and put it in an
_internal_header - I'd call it foo.i, and foo.i is included into all .c files
that define foo, but it is _not_ part of the .h interface to the foo module.
As I said, it's a fairly simple scheme, giving you most of the functionality
of objects without much overhead. The actual mechanism is one I learned using
Modula2 and is called _opaque_types_, as the original poster mentioned. One
advantage of learning lots of programming languages is that each one has it's
little schticks and little tricks, and the germ of these ideas can frequently
be transported to another language. After I learned Modula2, it became quite
obvious how to do the same idea in C.
John Nagle
>There have been a number of Real time systems produced using
>Smalltalk for instance. Real time does not imply no garbage
>collection but if you actually mean safety critical then that might
>be a different issue.
I saw a review of a protocol analyzer (a standalone hardware test
instrument) which used a Smalltalk implementation inside. The reviewer
found the notion of a test instrument which periodically stalled for
garbage collection very strange, and probably unacceptable. One didn't
lose data during garbage collection, but the keyboard and screen went dead.
John Nagle
Richard Bielak
[...]
>
>
>Getting a working application in a limited time is not just
>done for pleasure: customer generally wants to see a working
>prototype of the application to be sure it can be done, to see how
>it's gonna work and so on.
>Static type checking makes it harder to develop code in limited
>time (prototype doesn't have to be bug free, nor fast, nor complete)
>
>What is needed is a language that permits you to write 'free code'
>(without too much verification done by the language) to start
>fast and get a working prototype in very short time. And then
>add type constraints (etc...) to get to a 'bug-free' (grin) stable
>application.
>
I strongly disagree with the above philosophy. I think that static
type checking helps you to build programs faster, because the compiler
catches all those stupid errors right at the start.
I also don't believe that "prototype now, debug later" is a good
approach to writing software.
As a book on time management said:
"If you don't have time to do it right,
when will you have time to do it over."
Ciaran McHale
(Richard Bielak) writes:
>cjmc...@dsg.cs.tcd.ie (Ciaran McHale) writes:
>>Of the proposals I have seen for synchronisation mechanisms, for
>>whatever language, none are perfect. We (people doing research in this
>>area) have been making great progress over the last few years but don't
>>expect any OO language, Eiffel included, to have a wonderful
>>synchronisation mechanism "real soon now."
Just in case people have misunderstood me, I'll try to clarify what I
said previously.
There has been a lot of progress made in the area of
synchronisation mechanisms over the last few years. I am *not*
knocking the progress that has been made. All I am saying is
that there is still a lot more which needs to be done before we
will have something which is "up to scratch."
By "up to scratch" I mean a synchronisation mechanism which is (i)
powerful in its own right and (ii) integrates cleanly with other
language constructs/concepts.
>One very neat idea for synchronization was proposed by D. Caromel. He
>called it "wait-by-necessity" (also called "lazy wait").
Wait-by-necessity has some semantics which I think are a bit strange.
For example, to quote from page 17 of [Caromel-1] (ref at the end of
this email):
res := ob1.op1;
res := ob2.op2;
<use of res>
In this situation, the first result (from obj1 or obj2) is
[assigned] to res... If the second result comes back... it is
lost. This asynchrony allows Project Team resolution.
Those semantics are different from the semantics you would expect in a
purely sequential language. I don't like the subtle difference. (I guess
that one person's neat idea is another's unsafe optimisation:-)
>>One major problem I see with any synchronisation mechansism for Eiffel
>>which tries to support internal concurrency is the conflict between
>>internal concurrency and the evaluation of pre/postconditions. (What are
>>the semantics for evaluating pre/postcondition when instance variables,
>>which they access, are being updated by a thread executing an operation
>>of the object?)
>
>Regarding the pre- and post-conditions, I thought of the following way
>of dealing with this problem.
>
>You can divide features of a class into "querries" and "commands".
>Querries only read the object's attributes and return some value.
>Commands modify the object.
Indeed, that is one way to handle it. But it has some limitations:
o The readers/writer (queries/commands as you call them) policy
may be artifically constraining the potential for concurrency.
o Most likely it would be the programmer's responsibility to
take the pre-/post-conditions into account when writing the
synchronisation code for the object. I think this gives
programmers more than enough rope to hang themselves with.
Another possibility (as taken by Caromel) is for the language to
disallow internal concurrency within objects (but to allow for
concurrency between objects).
@article{Caromel-1,
author = "Denis Caromel",
title = "{Service, Asynchrony, and Wait-By-Necessity}",
journal = "Journal of Object Orientated Programming (JOOP)",
year = "1989",
pages = "12--22",
month = nov
}
Ciaran.
--
Ciaran McHale ----
Department of Computer Science, Trinity College, Dublin 2, Ireland. \bi/
Telephone: +353-1-7021539 FAX: +353-1-772204 email: cjmc...@dsg.cs.tcd.ie \/
Richard Harter
>As I understand the process of software development in practice, the
>prototype (having been validated by the customer) is taken and you put
>some nice user interface on top of it and that's it. Do you really
>want a prototype to have severe errors when it is presented to the
>customer with such a perspective in mind?? I wouldn't want to.
Depends on what you are doing. Quite often the situation is exactly
the reverse. In real life the neither the user nor the developer knows
what's really needed by the user or what the interface should really be
like. In this sort of situation one of the major objectives of proto-
typing is to discover what the specifications should be.
--
Richard Harter: SMDS Inc. Net address: r...@smds.com Phone: 508-369-7398
US Mail: SMDS Inc., PO Box 555, Concord MA 01742. Fax: 508-369-8272
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
Ralf Jungclaus
>
>I strongly disagree with the above philosophy. I think that static
>type checking helps you to build programs faster, because the compiler
>catches all those stupid errors right at the start.
>
>I also don't believe that "prototype now, debug later" is a good
>approach to writing software.
>
>As a book on time management said:
>
> "If you don't have time to do it right,
> when will you have time to do it over."
>
>
>...richie
... who could not agree..????
Richard Bielak
[...]
>>
>>You can divide features of a class into "querries" and "commands".
>>Querries only read the object's attributes and return some value.
>>Commands modify the object.
>
>Indeed, that is one way to handle it. But it has some limitations:
>
> o The readers/writer (queries/commands as you call them) policy
> may be artifically constraining the potential for
concurrency.
Since objects contain data and concurrent objects contain data shared
by many threads, so the concurrency *must* be constrained.
Because we discussing programming languages, it seems that we're
thinking of making code concurrent. But to have concurrent objects, we
also need to make data acccess concurrent - just like in a database.
> o Most likely it would be the programmer's responsibility to
> take the pre-/post-conditions into account when writing the
> synchronisation code for the object. I think this gives
> programmers more than enough rope to hang themselves with.
>
By default all routines could be "readers" (querries). Additional
keyword be needed for routines that are "writers" (commands).
>Another possibility (as taken by Caromel) is for the language to
>disallow internal concurrency within objects (but to allow for
>concurrency between objects).
>
Right. This is even more restrictive. However, this type of
concurrency is easy to implement via a library, without having to
change the language.
Ciaran McHale
>>>Ciaran writes:
>>>>[can pre-/post-conditions be evaluated safely in the face of concurrent
>>>>executions?]
>>>You can divide features of a class into "querries" and "commands".
>>>Querries only read the object's attributes and return some value.
>>>Commands modify the object.
>>
>>Indeed, that is one way to handle it. But it has some limitations:
>>
>> o The readers/writer (queries/commands as you call them) policy
>> may be artifically constraining the potential for
> concurrency.
>
>Since objects contain data and concurrent objects contain data shared
>by many threads, so the concurrency *must* be constrained.
I didn't express myself clearly in my previous posting. I'll try again.
Consider the following class:
Class Foo
"declare instance variables"
A(...)
{
something := x;
}
B(...)
{
y := ...;
}
end Foo;
Basically, B is a writer on one part of the object (the variable "y")
and A is an reader on a _different_ part of the object (the variable
"x"). So, if concurreny is allowed, the synchronisation constraints on
A and B might state that:
1. B cannot execute if B is already executing (i.e., mutex with
respect to itself)
2. There is no restriction on invocations of A.
Notice that the potential concurrency is greater than than allowed by
labeling everything as either a "(whole object) reader" or "(whole
object) writer". By recognising that some operations only read/write
sub-parts of an object, while other operations read/write other
sub-parts we can have more potential for concurrency.
Now let us consider how certain pre-conditions may restrict the
potential concurrency of the object. In particular, consider the
following which attaches a precondion on A.
Class Bar
"declare instance variables"
A(...)
precondition: y > 10;
{
something := x;
}
B(...)
{
y := ...;
}
end Bar;
A's precondition reads the value of "y", which is updated in B. Thus,
the synchronisation constraints on the object might be:
1. as stated previously.
2. as stated previously.
3. A's precondition may not be evaluated while B is executing
(and visa versa).
Because there is a strong link between the evaluation of A's
precondition and the execution of A, it is tempting to lump them
together; doing so allows us to simplify the above synchronisation
constraints into:
1. B cannot execute if A or B is executing.
2. A cannot execute if B is executing.
While this is certainly a possible solution, it is constricting the
potential concurrency of the object (as can be seen if you compare these
synchronisation constraints to the original ones I specified).
That's what I tried (but failed:-) to say in my previous posting.
I agree with Richard that:
>Since objects contain data and concurrent objects contain data shared
>by many threads, so the concurrency *must* be constrained.
However, unfortunately, pre-/post-conditions seem to reduce the
potential for concurrency within an object. This is _not_ to say that
pre-/post-conditions are a bad idea; only that more work needs to be
done to integrate them with synchronisation mechanisms.
BTW, Maurice Herlihy holds a rather different opinion on concurrency
control (reference at end of this posting).
>> o Most likely it would be the programmer's responsibility to
>> take the pre-/post-conditions into account when writing the
>> synchronisation code for the object. I think this gives
>> programmers more than enough rope to hang themselves with.
>
>By default all routines could be "readers" (querries). Additional
>keyword be needed for routines that are "writers" (commands).
What I meant by that comment is that programmers know they have to look
at the code bodies of operations when they are deciding on a
synchronisation policy for the object, but they may fail to _also_ take
pre-/post-conditions into account when doing this. I think this issue
is independant of whether one expresses synchronisation constraints in
terms of guards, path expressions or keywords such as
"reader"/"writer".
@article{Misc-11,
author = "Maurice Herlihy",
title = "{A Methodology for Implementing Highly Concurrent Data
Structures}",
journal = "SIGPLAN Notices",
year = "1990",
volume = "25",
number = "3",
pages = "197--206",
month = mar,
note = "Special Issue: Second ACM SIGPLAN Synmposium on
Principles \& Practice of Parallel Programming
(PPOPP)",
abstract = "A {\em concurrent object\/} is a data structure shared
by concurrent processes. Conventional techniques for
implementing concurrent objects typically rely on
{\em critical sections\/}: ensuring that only one
process at a time can operate on the object.
Nevertheless, critical sections are poorly suited for
asynchronous systems: If one process is halted or
delayed in a critical section, other, non-faulty
processes will be unable to progress. By contrast, a
concurrent object implementation is
{\em non-blocking\/} is it always guarantees that some
process will complete an operation in a finite number
of steps, and it is wait-free if it guarantees that
{\em each\/} process will complete an operation in a
finite number of steps. This paper proposes a new
methodology for constructing non-blocking and wait-free
implementations of concurrent objects. The object's
representation and operations are written as stylised
sequential programs, with no explicit synchronisation.
Each sequential operation will is automatically
transformed into a non-blocking or wait-free operation
using novel synchronisation and memory management
algorithms. These algorithms are presented for a
multiple instruction/multiple data (MIMD) architecture
in which $n$ processes communicate by applying
{\em read}, {\em write}, and {\em compare\&swap\/}
operations to a shared memory.",
annote = "I can't seem to grasp all of this paper. However, what
I do understand is that this is important research.
Hopefully in a few years the ideas in this paper will
have matured a bit more and will be more accessable."
Caromel Denis
cjmc...@dsg.cs.tcd.ie (Ciaran McHale) writes:
>>One very neat idea for synchronization was proposed by D. Caromel. He
>>called it "wait-by-necessity" (also called "lazy wait").
>Wait-by-necessity has some semantics which I think are a bit strange.
>For example, to quote from page 17 of [Caromel-1] (ref at the end of
>this email):
>
> res := ob1.op1;
> res := ob2.op2;
> <use of res>
>
> In this situation, the first result (from obj1 or obj2) is
> [assigned] to res... If the second result comes back... it is
> lost. This asynchrony allows Project Team resolution.
>Those semantics are different from the semantics you would expect in a
>purely sequential language. I don't like the subtle difference. (I guess
>that one person's neat idea is another's unsafe optimisation:-)
Ciaram Mchale is right, but references a paper which is quite old now.
The semantics for "wait-by-necessity" we actually adopted is:
whatever the result which comes back first, the variable "res"
contains the result of the "ob2.op2" call.
Whatever the speed of the two asynchronous calls, you get in "res"
the value you would get in with the sequential system.
Of course, the idea is to preserve the semantics when transforming a
sequential system into a parallel one. Much recent papers describing
wait-by-necessity are in refs.
BTW, I don't think wait-by-necessity should be called "lazy wait"
since it is confusing. The semantics of the functional "lazy evaluation"
implies that we do the evaluation only if we need the value. In the
wait-by-necessity, we do the asynchronous call, the evaluation, in any case.
Denis
--
Denis Caromel - I3S
Universite de Nice Sophia Antipolis - C.N.R.S. U.R.A. 1376 - France
Mail: I3S, Bat. 4 Avenue Einstein, Sophia Antipolis, F-06560 Valbonne
Ph.: (33) 92 94 26 25, Fax: (33) 92 94 28 98,
E-Mail: car...@mimosa.unice.fr, Telex: GRP 970 006
References:
Caromel, D.
``Concurrency and Reusability: From Sequential to Parallel''
Journal of Object-Oriented Programming, 3(3), September 1990.
Caromel, D.
``Concurrency: an Object-Oriented Approach'',
TOOLS'90, Paris, 1990.
Caromel, D.
"Programming abstractions for concurrent programming"
TOOLS PACIFIC'90, Sydney, Australia, November 1990.
Caromel, D.
``Programmation Parall`ele Asynchrone et Imp'erative,: Etudes et Propositions'',
Th`ese de Doctorat de l'Universit'e de Nancy I, France. February 1991.
Caromel, D., Rebuffel M.
"Ten Language Features to Achieve Reuse",
Workshop on Object-Based Concurrency and Reuse,
ECOOP'92, Utrecht, The Netherlands.
Richard Bielak
[...descriptions of querries and commands removed...]
>
>I didn't express myself clearly in my previous posting. I'll try again.
>Consider the following class:
>
> Class Foo
> "declare instance variables"
>
> A(...)
> {
> something := x;
> }
>
> B(...)
> {
> y := ...;
> }
> end Foo;
>
>Basically, B is a writer on one part of the object (the variable "y")
>and A is an reader on a _different_ part of the object (the variable
>"x"). So, if concurreny is allowed, the synchronisation constraints on
>A and B might state that:
>
> 1. B cannot execute if B is already executing (i.e., mutex with
> respect to itself)
> 2. There is no restriction on invocations of A.
>
>Notice that the potential concurrency is greater than than allowed by
>labeling everything as either a "(whole object) reader" or "(whole
>object) writer". By recognising that some operations only read/write
>sub-parts of an object, while other operations read/write other
>sub-parts we can have more potential for concurrency.
>
I guess the question is, whether this is an "object-oriented" way to
introduce concurrency into OOPLs. I'm not sure *what* the
object-oriented way to add concurrency is, but your proposal doesn't
feel right to me.
Is a thread-of-control an object?
[...an explanation of how pre- post- conditions reduce possible
concurrency removed ...]
>
>What I meant by that comment is that programmers know they have to look
>at the code bodies of operations when they are deciding on a
>synchronisation policy for the object, but they may fail to _also_ take
>pre-/post-conditions into account when doing this. I think this issue
>is independant of whether one expresses synchronisation constraints in
>terms of guards, path expressions or keywords such as
>"reader"/"writer".
>
I'll have to think more about this :-).
...richie
P.S. Did you see the paper in Tools '92 "Concurrency Annotations
Improve Reusibility", by Klaus-Peter Lohr.
Norman Diamond
>Is a thread-of-control an object?
I vote yes. And even more strongly, I would assert that a continuation
is an object. A server or a "manager" (delegator) should be able to
hand off a continuation to another server, for eventual resumption when
its request has been served.
--
Norman Diamond dia...@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring. That was probably it. Very bad."