* Re: Why C++ is successful
1998-07-29 0:00 ` Dave Martin
@ 1998-07-29 0:00 ` Pat Rogers
1998-07-29 0:00 ` Juan Carlos Gil Montoro
1998-07-29 0:00 ` Brian Rogoff
1998-07-29 0:00 ` John McCabe
` (2 subsequent siblings)
3 siblings, 2 replies; 43+ messages in thread
From: Pat Rogers @ 1998-07-29 0:00 UTC (permalink / raw)
Dave Martin wrote in message <35bebe5f.95187031@netnews.msn.com>...
>I certainly wasn't trying to attack ada and I hope it didn't come off
>that way. I was just relating the experiences that I had. Its true
>that many people use Ada and are quite happy to do so; and Ada-95 has
>added a lot to the language in an O-O context.
I think it is laudable that you have said the above; your earlier post did
indeed come off (to me, anyway) as spreading uninformed and out-of-date
hearsay (not heresy :).
>We are surrounded by many DOD installations around here, and Ada usage
>was mandated by the DOD until recently. Many of the people I know
>were upset because they were told "you will use Ada" and many
>obviously biased studies were bandied about (the kind where it was
>obvious that the people conducting the study were told what result to
>come up with before they started the study). I'm sure you can find
>many such "studies" on just about any topic.
Ah, "the Mandate". Imagine you work in a building that uses approximately
450 different kinds of electrical outlet. Now imagine moving your office
equipment from one office to another; sure would be nice if all the outlets
were compatible, because the equipment can't be used in the new office.
That's the position the DoD found itself in, when they decided maybe a
standard programming languages was a good idea. (Approximately 450
different languages and dialects of languages were in use in embedded
systems, the domain in which DoD was spending the most money.) Too bad they
didn't follow through with what they got, because it was very good; not for
everything, but certainly for embedded systems (warts and all).
I've been involved with Ada since 1980, and have often had to convince my
DoD customers that Ada was the way to go, but they were never sorry in the
end. For the commercial stuff, we don't have to convince anybody because it
isn't an issue.
>I personally haven't learned Ada (83/95) yet, so I hesitate to say
>anything one way or the other about it, though I will admit to being
>influenced by my friends occasionally on the subject. I know many
>people who hate Ada, and I know there are many others who swear by it.
I'll bet the used an inferior compiler, or had poor/no training. Anyway, if
they took the attitude of being forced to do it, how successful could they
have been?
>I'm not sure I'll ever get around to learning Ada; Eiffel is my
>current "education" project. I just hope that people using whatever
>language for some project are using them from an informed position and
>choice; and not for "religious" reasons. I know someone who refused
>to move from C to C++ because of all that ickyness C++ added to C.
>sigh. I once got him to (reluctantly) admit that prototypes were a
>good thing, but thats about as far as he'll go. He also generally
>hates what ANSI/ISO did to C.
>
>Personally, for the last several years i've been trying to detect my
>own hidden assumptions and biases, and nullify them. I never want to
>turn into the old dog who can't learn new tricks or becomes closed-
>minded to something simply because its different. Unfortunately I
>haven't always been successful, but i'm trying.
That's why I'm learning Java now, and Eiffel and C++ in the past. They all
contribute something to make one a better developer. I need to take another
look at Fortran, because it sure isn't the Fortran IV I used in the old
days!
Since the Ada model of OO is just enough different to have some advantages,
why not learn a little about Ada? The language Rationale can be downloaded
for free. Plus there's built-in tasking, support for deterministic
real-time programming, distribution, and a host of other things you won't
see elsewhere.
-- pat
Patrick Rogers
progers@acm.org
http://www.neosoft.com/~progers
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Why C++ is successful
1998-07-29 0:00 ` Pat Rogers
@ 1998-07-29 0:00 ` Juan Carlos Gil Montoro
1998-07-29 0:00 ` Pat Rogers
1998-07-29 0:00 ` Brian Rogoff
1 sibling, 1 reply; 43+ messages in thread
From: Juan Carlos Gil Montoro @ 1998-07-29 0:00 UTC (permalink / raw)
Pat Rogers wrote:
>
> [Big Snip]
>
> That's why I'm learning Java now, and Eiffel and C++ in the past. They all
> contribute something to make one a better developer. I need to take another
> look at Fortran, because it sure isn't the Fortran IV I used in the old
> days!
>
You'll be happy you did.
Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
their niche.
Juan Carlos---
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Juan Carlos Gil Montoro
@ 1998-07-29 0:00 ` Pat Rogers
1998-07-29 0:00 ` Jay Martin
1998-07-30 0:00 ` Ell
0 siblings, 2 replies; 43+ messages in thread
From: Pat Rogers @ 1998-07-29 0:00 UTC (permalink / raw)
Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
>Pat Rogers wrote:
>>
>> [Big Snip]
>>
>> That's why I'm learning Java now, and Eiffel and C++ in the past. They all
>> contribute something to make one a better developer. I need to take another
>> look at Fortran, because it sure isn't the Fortran IV I used in the old
>> days!
>>
>
> You'll be happy you did.
> Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
>their niche.
Since you mention it, what would you say is Fortran's niche that the language is
unbeatable in filling? (Serious request for opinion, not yet another language
flame war ignition.)
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Pat Rogers
@ 1998-07-29 0:00 ` Jay Martin
1998-07-30 0:00 ` dennison
1998-07-30 0:00 ` Ell
1 sibling, 1 reply; 43+ messages in thread
From: Jay Martin @ 1998-07-29 0:00 UTC (permalink / raw)
Pat Rogers wrote:
>
> Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
> >Pat Rogers wrote:
> >>
> >> [Big Snip]
> >>
> >> That's why I'm learning Java now, and Eiffel and C++ in the past. They all
> >> contribute something to make one a better developer. I need to take another
> >> look at Fortran, because it sure isn't the Fortran IV I used in the old
> >> days!
> >>
> >
> > You'll be happy you did.
> > Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
> >their niche.
>
> Since you mention it, what would you say is Fortran's niche that the language is
> unbeatable in filling? (Serious request for opinion, not yet another language
> flame war ignition.)
I believe Fortran (i.e. High Performance Fortran) is king for
scientific array calculations on massively parallel
machines. These compilers will take a program
that does calculations on arrays and generate code
that distributes the arrays across all the processors
and efficiently schedules data communication between
the processors. I don't know if there is a
viable "High Performance C/C++" in the market yet.
Jay
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Jay Martin
@ 1998-07-30 0:00 ` dennison
0 siblings, 0 replies; 43+ messages in thread
From: dennison @ 1998-07-30 0:00 UTC (permalink / raw)
In article <35C00670.56E78687@earthlink.net>,
Jay Martin <jaymmartin@earthlink.net> wrote:
> Pat Rogers wrote:
> > Since you mention it, what would you say is Fortran's niche that the
language is
> > unbeatable in filling? (Serious request for opinion, not yet another
language
> > flame war ignition.)
>
> I believe Fortran (i.e. High Performance Fortran) is king for
> scientific array calculations on massively parallel
> machines. These compilers will take a program
> that does calculations on arrays and generate code
> that distributes the arrays across all the processors
> and efficiently schedules data communication between
> the processors. I don't know if there is a
> viable "High Performance C/C++" in the market yet.
I just finished a graduate-level course in compiler optimizations on
concurrent architectures. There is a large amount of research being poured
into getting Fortran compilers to optimize code on vector and multiprocessor
machines. This has little to do with the suitability of Fortran, but is
mostly due to the fact that the purchasers of these machines have lots of
Fortran code they want to run.
HPF has special loop constructs that map directly to "do this instruction on
every processor in parallel" and "do this instruction across the whole array
at once as a vector". These allows the s/w developer to explicitly code
parallelsim that he knows his hardware supports. Of course the coder has to
be able to think in these terms, which takes some getting used to.
That being said, I noticed two things wrt supporting other languages on these
platforms. First, because of C's universal reliance on pointers, just about
every loop optimization that we studied would have to be disabled in a C
compiler. Safely doing most optimizations would entail very complicated alias
analisis, usually going across compilation units.
Secondly, because of Ada's parameter passing rules and static type checking,
an Ada compiler would actually have to do LESS work than the HPF compiler to
optimize the same algorithm. The entire semester I found myself asking the
instructor, "Gee, you wouldn't have to do any of this work you just spent
half the class going over if the language was defined to (insert Ada language
rule here), would you?" Of course Ada does support pointers, but dosen't have
C's aliasing problem since aliased variables are much rarer, and have to be
clearly marked as such in the source code.
Of course language suitability is only part of the picture. If all the
purchasers of these machines have Fortran code they want to run on them, a
really great Ada or C compiler won't do them much good.
T.E.D.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Pat Rogers
1998-07-29 0:00 ` Jay Martin
@ 1998-07-30 0:00 ` Ell
1998-07-29 0:00 ` Larry Elmore
1998-07-29 0:00 ` Pat Rogers
1 sibling, 2 replies; 43+ messages in thread
From: Ell @ 1998-07-30 0:00 UTC (permalink / raw)
"Pat Rogers" <progers@acm.org> wrote:
>Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
>>Pat Rogers wrote:
>>>
>>> [Big Snip]
>>>
>>> That's why I'm learning Java now, and Eiffel and C++ in the past. They all
>>> contribute something to make one a better developer. I need to take another
>>> look at Fortran, because it sure isn't the Fortran IV I used in the old
>>> days!
>>>
>>
>> You'll be happy you did.
>> Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
>>their niche.
>
>
>Since you mention it, what would you say is Fortran's niche that the language is
>unbeatable in filling? (Serious request for opinion, not yet another language
>flame war ignition.)
Mathematical calculations. The science, engineering, business, and
other groups requiring large amounts of efficient math processing have
overwhelmingly adopted Fortran for decades.
Elliott
--
:=***=: Objective * Pre-code Modelling * Holistic :=***=:
Hallmarks of the best SW Engineering
"The domain object model is the foundation of OOD."
Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
Copyright 1998 Elliott. exclusive of others' writing. may be copied
without permission only in the comp.* usenet and bitnet groups.
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Why C++ is successful
1998-07-30 0:00 ` Ell
@ 1998-07-29 0:00 ` Larry Elmore
1998-07-30 0:00 ` Ell
1998-07-30 0:00 ` Jeffrey C. Dege
1998-07-29 0:00 ` Pat Rogers
1 sibling, 2 replies; 43+ messages in thread
From: Larry Elmore @ 1998-07-29 0:00 UTC (permalink / raw)
Ell wrote in message <35c0edf6.9796817@news.erols.com>...
>"Pat Rogers" <progers@acm.org> wrote:
>
>>Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
>>>Pat Rogers wrote:
>>>>
>>>> That's why I'm learning Java now, and Eiffel and C++ in the past. They
all
>>>> contribute something to make one a better developer. I need to take
another
>>>> look at Fortran, because it sure isn't the Fortran IV I used in the old
>>>> days!
>>>
>>> You'll be happy you did.
>>> Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
>>>their niche.
>>
>>
>>Since you mention it, what would you say is Fortran's niche that the
language is
>>unbeatable in filling? (Serious request for opinion, not yet another
language
>>flame war ignition.)
>
>Mathematical calculations. The science, engineering, business, and
>other groups requiring large amounts of efficient math processing have
>overwhelmingly adopted Fortran for decades.
But isn't this largely due to a combination of inertia, legacy code,
existing libraries plus compilers that are very, very good at optimizing
that kind of code (they've certainly had enough time to get them working
right!), rather than anything to do with the language itself?
Larry
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Larry Elmore
@ 1998-07-30 0:00 ` Ell
1998-07-30 0:00 ` Jeffrey C. Dege
1 sibling, 0 replies; 43+ messages in thread
From: Ell @ 1998-07-30 0:00 UTC (permalink / raw)
In comp.object Larry Elmore <ljelmore@montana.campus.mci.net> wrote:
: Ell wrote in message <35c0edf6.9796817@news.erols.com>...
:>"Pat Rogers" <progers@acm.org> wrote:
:>
:>>Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
:>>>Pat Rogers wrote:
:>>>> That's why I'm learning Java now, and Eiffel and C++ in the past. They
: all
:>>>> contribute something to make one a better developer. I need to take
: another
:>>>> look at Fortran, because it sure isn't the Fortran IV I used in the old
:>>>> days!
:>>> You'll be happy you did.
:>>> Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
:>>>their niche.
:>>Since you mention it, what would you say is Fortran's niche that the
: language is
:>>unbeatable in filling?
:>Mathematical calculations. The science, engineering, business, and
:>other groups requiring large amounts of efficient math processing have
:>overwhelmingly adopted Fortran for decades.
: But isn't this largely due to a combination of inertia, legacy code,
: existing libraries plus compilers that are very, very good at optimizing
: that kind of code (they've certainly had enough time to get them working
: right!), rather than anything to do with the language itself?
Fortran has been one of, if the best overall best language for math
calculation since it appeared in the '50's. It was the 1st high level
language suitable for complex math. It's 3 or 4 the revision allowed
asssembler to be easily mixed into its source, and it had nicely optimized
compiler's which produced efficient code. For fast, complex math I still
think it outshines the other--especially amongst most widely used, well
known languages.
Elliott
--
:=***=: Objective * Pre-code Modelling * Holistic :=***=:
Hallmarks of the best SW Engineering
"The domain object model is the foundation of OOD."
Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
Copyright 1998 Elliott. exclusive of others' writing. may be copied
without permission only in the comp.* usenet and bitnet groups.
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Why C++ is successful
1998-07-29 0:00 ` Larry Elmore
1998-07-30 0:00 ` Ell
@ 1998-07-30 0:00 ` Jeffrey C. Dege
1998-08-01 0:00 ` Robert Dewar
1 sibling, 1 reply; 43+ messages in thread
From: Jeffrey C. Dege @ 1998-07-30 0:00 UTC (permalink / raw)
On Wed, 29 Jul 1998 23:24:18 -0600, Larry Elmore <ljelmore@montana.campus.mci.net> wrote:
>Ell wrote in message <35c0edf6.9796817@news.erols.com>...
>>
>>Mathematical calculations. The science, engineering, business, and
>>other groups requiring large amounts of efficient math processing have
>>overwhelmingly adopted Fortran for decades.
>
>But isn't this largely due to a combination of inertia, legacy code,
>existing libraries plus compilers that are very, very good at optimizing
>that kind of code (they've certainly had enough time to get them working
>right!), rather than anything to do with the language itself?
Partly, but Fortran also has the advantage of lacking pointers. The fact
that C/C++ allow you to modify a variable through pointers in non-obvious
ways put real limits on what sort of optimizations the compiler can safely
make. Fortran back when I used it was also strictly a static language
i.e., all local variables were, in C terms, statically allocated, out
of BSS, not allocated off the stack on function entry, and all arguments
were pass-by-reference. This made function entry and exit much faster.
(no stack frames to release, no copying of pass-by-value arguments, etc.)
Of course, this also meant no recursive function calls.
Again, this lead to simplified variable access patterns, as compared to
C/C++, which meant more aggressive optimization was possible without
the risk of breaking legal code.
--
First twenty-one new features that somehow we must add in.
Then thirty-seven changes show up much to our chagrin.
And this thing's just inadequate, and that one's just plain wrong.
And by the way your schedule is about three months too long.
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Why C++ is successful
1998-07-30 0:00 ` Jeffrey C. Dege
@ 1998-08-01 0:00 ` Robert Dewar
0 siblings, 0 replies; 43+ messages in thread
From: Robert Dewar @ 1998-08-01 0:00 UTC (permalink / raw)
Jeffrey said
<<Partly, but Fortran also has the advantage of lacking pointers. The fact
that C/C++ allow you to modify a variable through pointers in non-obvious
ways put real limits on what sort of optimizations the compiler can safely
make. Fortran back when I used it was also strictly a static language
i.e., all local variables were, in C terms, statically allocated, out
of BSS, not allocated off the stack on function entry, and all arguments
were pass-by-reference. This made function entry and exit much faster.
(no stack frames to release, no copying of pass-by-value arguments, etc.)
Of course, this also meant no recursive function calls.
>>
This is old fashioned thinking, on modern processors, the normal situation
is that accessing static global memory is more expensive than accessing
local stack storage.
Note incidentally that Fortran is carefully designed to give the implementor
the choice between using static and stack storage (i.e. the characterization
of "strictly static" applies to the *implementation* not the *language*)
It is also not at all the case that passing by reference is necessarily
faster than passing by copy, and many Fortran compilers use pass by
copy for simple variables.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-30 0:00 ` Ell
1998-07-29 0:00 ` Larry Elmore
@ 1998-07-29 0:00 ` Pat Rogers
1998-07-30 0:00 ` Ell
1998-07-30 0:00 ` Ell
1 sibling, 2 replies; 43+ messages in thread
From: Pat Rogers @ 1998-07-29 0:00 UTC (permalink / raw)
Ell wrote in message <35c0edf6.9796817@news.erols.com>...
>"Pat Rogers" <progers@acm.org> wrote:
>
>>Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
<snip>
>>> You'll be happy you did.
>>> Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
>>>their niche.
>>
>>
>>Since you mention it, what would you say is Fortran's niche that the language
is
>>unbeatable in filling? (Serious request for opinion, not yet another language
>>flame war ignition.)
>
>Mathematical calculations. The science, engineering, business, and
>other groups requiring large amounts of efficient math processing have
>overwhelmingly adopted Fortran for decades.
Gee, thanks. I didn't know that.
Sigh. I suppose I didn't ask it well -- I meant " what is it about Fortran that
makes it unbeatable as a language for the niche *Juan Carlos* considers it to
fill?"
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Pat Rogers
@ 1998-07-30 0:00 ` Ell
1998-07-30 0:00 ` Ell
1 sibling, 0 replies; 43+ messages in thread
From: Ell @ 1998-07-30 0:00 UTC (permalink / raw)
"Pat Rogers" <progers@acm.org> wrote:
>
>Ell wrote in message <35c0edf6.9796817@news.erols.com>...
>>"Pat Rogers" <progers@acm.org> wrote:
>>
>>>Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
>
><snip>
>>>> You'll be happy you did.
>>>> Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
>>>>their niche.
>>>
>>>
>>>Since you mention it, what would you say is Fortran's niche that the language
>is
>>>unbeatable in filling? (Serious request for opinion, not yet another language
>>>flame war ignition.)
>>
>>Mathematical calculations. The science, engineering, business, and
>>other groups requiring large amounts of efficient math processing have
>>overwhelmingly adopted Fortran for decades.
>
>
>Gee, thanks. I didn't know that.
Next time don't ask.
Elliott
--
:=***=: Objective * Pre-code Modelling * Holistic :=***=:
Hallmarks of the best SW Engineering
"The domain object model is the foundation of OOD."
Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
Copyright 1998 Elliott. exclusive of others' writing. may be copied
without permission only in the comp.* usenet and bitnet groups.
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Why C++ is successful
1998-07-29 0:00 ` Pat Rogers
1998-07-30 0:00 ` Ell
@ 1998-07-30 0:00 ` Ell
1 sibling, 0 replies; 43+ messages in thread
From: Ell @ 1998-07-30 0:00 UTC (permalink / raw)
"Pat Rogers" <progers@acm.org> wrote:
>
>Ell wrote in message <35c0edf6.9796817@news.erols.com>...
>>"Pat Rogers" <progers@acm.org> wrote:
>>
>>>Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
>
><snip>
>>>> You'll be happy you did.
>>>> Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
>>>>their niche.
>>>
>>>
>>>Since you mention it, what would you say is Fortran's niche that the language
>is
>>>unbeatable in filling? (Serious request for opinion, not yet another language
>>>flame war ignition.)
>>
>>Mathematical calculations. The science, engineering, business, and
>>other groups requiring large amounts of efficient math processing have
>>overwhelmingly adopted Fortran for decades.
>
>
>Gee, thanks. I didn't know that.
>
>Sigh. I suppose I didn't ask it well -- I meant " what is it about Fortran that
>makes it unbeatable as a language for the niche *Juan Carlos* considers it to
>fill?"
Do you think he was talking about any niche other than mathematical
calculations, if you knew that was the thing Fortran was great at?
Please don't give me an ignorant attitude for the obvious, if you have
some other dumb motivation for being a pain.
Elliott
--
:=***=: Objective * Pre-code Modelling * Holistic :=***=:
Hallmarks of the best SW Engineering
"The domain object model is the foundation of OOD."
Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
Copyright 1998 Elliott. exclusive of others' writing. may be copied
without permission only in the comp.* usenet and bitnet groups.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Pat Rogers
1998-07-29 0:00 ` Juan Carlos Gil Montoro
@ 1998-07-29 0:00 ` Brian Rogoff
1998-07-29 0:00 ` Charles Hixson
1998-07-29 0:00 ` John McCabe
1 sibling, 2 replies; 43+ messages in thread
From: Brian Rogoff @ 1998-07-29 0:00 UTC (permalink / raw)
On Wed, 29 Jul 1998, Pat Rogers wrote:
> Dave Martin wrote:
... snip ...
> >
> >Personally, for the last several years i've been trying to detect my
> >own hidden assumptions and biases, and nullify them. I never want to
> >turn into the old dog who can't learn new tricks or becomes closed-
> >minded to something simply because its different. Unfortunately I
> >haven't always been successful, but i'm trying.
>
> That's why I'm learning Java now, and Eiffel and C++ in the past. They all
> contribute something to make one a better developer. I need to take another
> look at Fortran, because it sure isn't the Fortran IV I used in the old
> days!
I don't want to discourage anyone from learning new things, but IMO Java,
Ada, C++, and Eiffel are not really all that different, I'd even say they
are pretty close in the whole space of programming languages. Why not try
a few really different languages, like:
(1) A logic language, like Prolog or Mercury
(2) A functional language, like OCaml, Haskell, or Scheme
(3) An OO language with multimethods, like Common Lisp
(4) Any of a number of interesting other languages, like Forth, Icon, ...
This isn't meant as a disagreement with Pat Rogers. I actually like Ada
and think it is worth knowing, just that if you want to stretch your mind
and are not solely interested in getting a job using some particular
language, it might be worth it to you to consider a wider range.
-- Brian
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Brian Rogoff
@ 1998-07-29 0:00 ` Charles Hixson
1998-07-29 0:00 ` falis
` (2 more replies)
1998-07-29 0:00 ` John McCabe
1 sibling, 3 replies; 43+ messages in thread
From: Charles Hixson @ 1998-07-29 0:00 UTC (permalink / raw)
To: Brian Rogoff
But what Ada REALLY needs is a good garbage collection mechanism. And
saying "Do it by hand" doesn't qualify as good!
Brian Rogoff wrote:
>
> On Wed, 29 Jul 1998, Pat Rogers wrote:
> > Dave Martin wrote:
> ... snip ...
> > >
> > >Personally, for the last several years i've been trying to detect my
> > >own hidden assumptions and biases, and nullify them. I never want to
> > >turn into the old dog who can't learn new tricks or becomes closed-
> > >minded to something simply because its different. Unfortunately I
> > >haven't always been successful, but i'm trying.
> >
> > That's why I'm learning Java now, and Eiffel and C++ in the past. They all
> > contribute something to make one a better developer. I need to take another
> > look at Fortran, because it sure isn't the Fortran IV I used in the old
> > days!
>
> I don't want to discourage anyone from learning new things, but IMO Java,
> Ada, C++, and Eiffel are not really all that different, I'd even say they
> are pretty close in the whole space of programming languages. Why not try
> a few really different languages, like:
>
> (1) A logic language, like Prolog or Mercury
> (2) A functional language, like OCaml, Haskell, or Scheme
> (3) An OO language with multimethods, like Common Lisp
> (4) Any of a number of interesting other languages, like Forth, Icon, ...
>
> This isn't meant as a disagreement with Pat Rogers. I actually like Ada
> and think it is worth knowing, just that if you want to stretch your mind
> and are not solely interested in getting a job using some particular
> language, it might be worth it to you to consider a wider range.
>
> -- Brian
--
Charles Hixson charleshixson@earthling.net
(510) 464-7733 or chixso@mtc.dst.ca.us
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Why C++ is successful
1998-07-29 0:00 ` Charles Hixson
@ 1998-07-29 0:00 ` falis
1998-07-30 0:00 ` Robert I. Eachus
1998-08-01 0:00 ` Jay Martin
2 siblings, 0 replies; 43+ messages in thread
From: falis @ 1998-07-29 0:00 UTC (permalink / raw)
> But what Ada REALLY needs is a good garbage collection
mechanism. And
> saying "Do it by hand" doesn't qualify as good!
>
For the Ada to JVM target, it comes with the JVM.
For UNIX and Windows targets, our product, ObjectAda works
with Geodesic Systems Great Circle garbage collector - just link
with a Great Circle object module and appropriate library.
- Ed Falis
Aonix
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Charles Hixson
1998-07-29 0:00 ` falis
@ 1998-07-30 0:00 ` Robert I. Eachus
1998-07-31 0:00 ` Charles Hixson
1998-08-01 0:00 ` Jay Martin
2 siblings, 1 reply; 43+ messages in thread
From: Robert I. Eachus @ 1998-07-30 0:00 UTC (permalink / raw)
In article <35BF49E8.136D75C2@earthling.net> Charles Hixson <charleshixson@earthling.net> writes:
> But what Ada REALLY needs is a good garbage collection mechanism. And
> saying "Do it by hand" doesn't qualify as good!
The Ada philosophy is to give the programmer the tools he needs and
to allow him the freedom to create types (classes) that do what is
required for that type. Of course there are also predefined types and
where appropriate there are directions given to the compiler writers
about those types:
A.4.4(106):
Implementation Advice
Bounded string objects should not be implemented by implicit
pointers and dynamic allocation.
A.4.5(88):
Implementation Requirements
No storage associated with an Unbounded_String object shall be lost
upon assignment or scope exit.
Now if you are creating a type that needs special storage
management, my experience is that it requires about six lines. If you
are creating something more ordinary, just use components of
predefined types like Unbounded_String, and don't worry about garbage
collection.
Yes, it is possible to write code in Ada that leaks
memory absent garbage collection, but is well behaved if garbage
collection is provided, as it is by some implementations. But such
programs are rare. For the large majority of Ada programs, memory
management is not an issue. (Or at least, it isn't an issue if there
ISN'T a garbage collector.) For a much smaller set, but probably much
larger than the set where general garbage collection is helpful, you
do need to put in some storage management code. But with Ada 95, the
most I have ever had to do was about one page of code. (Create a type
descended from Controlled that cleans itself up when no longer visible
by calling Unchecked_Deallocation. These objects are often used for
communication between tasks where a simple protected type won't
do. However, I'd say that 90% of such cases all you have to do is use
Unbounded_Strings.)
I'll post a very useful example to comp.lang.ada soon.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Why C++ is successful
1998-07-30 0:00 ` Robert I. Eachus
@ 1998-07-31 0:00 ` Charles Hixson
0 siblings, 0 replies; 43+ messages in thread
From: Charles Hixson @ 1998-07-31 0:00 UTC (permalink / raw)
Yes, I know what the current Ada spec is on this. I was also informed
(forget which book) that routines in library units are not guaranteed to
ever clean themselves up (during the life of the program). Annoying.
And, yes, I know that those compilers that host themselves on JVM's make
use of the embedded garbage collector, but there doesn't seem to be any
syntax, and certainly no standard syntax, to control it. At least Java
lets you ASK the gc to start. It doesn't have to do it, but you can
ask.
Basically, I'm very attracted to Ada95. But there are these few little
problems: no standard screen controls (need to use some other standard
language for that, I guess). No standard gc (yes, I do need to look
into descendants of controlled, but the examples that I've seen so far
haven't left me feeling optomistic -- basically, if I have a structure
with multiple pointers, say a balanced tree with some cursors, there
doesn't seem to be any safe way to determine when I can free the node,
without a WHOLE LOT of hand waving (sentinals, freeable storage lists,
synchronization flags, etc.), so how do I balance the tree? I know in
Java that there's a huge amount of *stuff* going on in the background,
and it would be v. nice to eliminate this on structures that don't need
it. Especially on arrays, etc., of "homogenous type". But I wonder if
the gain of eliminating the overhead (and for getting those VERY USEFUL
type checks and range types) pays for the cost of user maintained
dynamic types. This is the second time I have devoted a month or two to
Ada95, because it seems to be SO desireable. Then I hit one of these
bottlenecks, estimate the amount of time it will take to implement the
feature I'm looking at, and back off again.
But if a standard approach were defined, then even if the particular
compiler that I was using didn't implement it (i.e., optional annex), at
least I would know what syntax my solution should use, so as to be
maximally portable.
I don't want to build in storage leaks, assuming a garbage collector,
when most implementations don't have one.
Robert I. Eachus wrote:
>
> In article <35BF49E8.136D75C2@earthling.net> Charles Hixson <charleshixson@earthling.net> writes:
>
> > But what Ada REALLY needs is a good garbage collection mechanism. And
> > saying "Do it by hand" doesn't qualify as good!
>
> The Ada philosophy is to give the programmer the tools he needs and
> to allow him the freedom to create types (classes) that do what is
> required for that type. Of course there are also predefined types and
> where appropriate there are directions given to the compiler writers
> about those types:
/* snip */
> do need to put in some storage management code. But with Ada 95, the
> most I have ever had to do was about one page of code. (Create a type
> descended from Controlled that cleans itself up when no longer visible
> by calling Unchecked_Deallocation. These objects are often used for
> communication between tasks where a simple protected type won't
> do. However, I'd say that 90% of such cases all you have to do is use
> Unbounded_Strings.)
>
> I'll post a very useful example to comp.lang.ada soon.
> --
>
> Robert I. Eachus
>
> with Standard_Disclaimer;
> use Standard_Disclaimer;
> function Message (Text: in Clever_Ideas) return Better_Ideas is...
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Charles Hixson
1998-07-29 0:00 ` falis
1998-07-30 0:00 ` Robert I. Eachus
@ 1998-08-01 0:00 ` Jay Martin
1998-08-02 0:00 ` Robert Dewar
2 siblings, 1 reply; 43+ messages in thread
From: Jay Martin @ 1998-08-01 0:00 UTC (permalink / raw)
Charles Hixson wrote:
>
> But what Ada REALLY needs is a good garbage collection mechanism. And
> saying "Do it by hand" doesn't qualify as good!
Actually, I am pretty sure Ada83 that was supposed to have garbage collection
in non-embedded environments as there were official features to turn "automatic
storage reclaimation" off. Unfortunately, it wasn't a hard implementation
requirement and in the DOD world of $5000 toilet seats.... This is another
example of DOD mismanagement of Ada and its sad to admit in retrospect
that the Ada scoffers were right (DOD and competent language management
do not mix). Russia leaving the cold war business didn't help Ada either.
Oh well, the time to get on the Ada bandwagon was 15 years ago.
Jay
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-08-01 0:00 ` Jay Martin
@ 1998-08-02 0:00 ` Robert Dewar
1998-08-01 0:00 ` Jay Martin
0 siblings, 1 reply; 43+ messages in thread
From: Robert Dewar @ 1998-08-02 0:00 UTC (permalink / raw)
Jay says
<<Actually, I am pretty sure Ada83 that was supposed to have garbage collection
in non-embedded environments as there were official features to turn "automatic
storage reclaimation" off. Unfortunately, it wasn't a hard implementation
requirement and in the DOD world of $5000 toilet seats.... This is another
example of DOD mismanagement of Ada and its sad to admit in retrospect
that the Ada scoffers were right (DOD and competent language management
do not mix). Russia leaving the cold war business didn't help Ada either.
Oh well, the time to get on the Ada bandwagon was 15 years ago.
>>
No, that is wrong, Ada83 was not "supposed" to have GC, it was supposed to
ensure that GC was practical if it was needed. As for DoD mismanagement,
this is a truly peculiar statement. Any Ada vendor would have been happy
to provide GC to a customer who wanted it and was willing to pay. In fact
my memory at ALsys was we never had EVEN ONE customer who was interested
enough in GC to even ask about it. The same is true in our experience with
GNAT.
No customer has ever asked for GC, and they certainly have asked for many
other things.
You can of course use conservative GC's of various varieties with most
Ada 83 and Ada 95 compilers. I never bumped into an Ada application that
took advantage of this possibility.
I think that the DoD would have been way out of line dictating what particular
implementation characteristics were needed in implementations of Ada, instead
of leaving this up to the individual projects.
The fact that users of Ada did not ask for Jay's pet-feature-of-the-day has
nothing to do with mismanagement, and everything to do with actual requirements.
Please note that, as you of course know, I have always considered GC a
very important feature in high level languages. I find it disappointing
that it has been impossible to interest either Ada users or the Ada 9X
design process in GC, but that's the way it was. I had hoped to get GC as
at least a recommended part of the IS annex, but even there, I found zero
support on the relevant committee, and indeed, seeing the lack of interest
in GC among Ada users, I think the Ada 9X design had the right idea. Enable
GC at the design level, but do not attempt to impose it.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-08-02 0:00 ` Robert Dewar
@ 1998-08-01 0:00 ` Jay Martin
1998-08-02 0:00 ` Matthew Heaney
1998-08-02 0:00 ` Matthew Heaney
0 siblings, 2 replies; 43+ messages in thread
From: Jay Martin @ 1998-08-01 0:00 UTC (permalink / raw)
Robert Dewar wrote:
>
> Jay says
>
> <<Actually, I am pretty sure Ada83 that was supposed to have garbage collection
> in non-embedded environments as there were official features to turn "automatic
> storage reclaimation" off. Unfortunately, it wasn't a hard implementation
> requirement and in the DOD world of $5000 toilet seats.... This is another
> example of DOD mismanagement of Ada and its sad to admit in retrospect
> that the Ada scoffers were right (DOD and competent language management
> do not mix). Russia leaving the cold war business didn't help Ada either.
> Oh well, the time to get on the Ada bandwagon was 15 years ago.
> >>
>
> No, that is wrong, Ada83 was not "supposed" to have GC, it was supposed to
> ensure that GC was practical if it was needed. As for DoD mismanagement,
> this is a truly peculiar statement. Any Ada vendor would have been happy
> to provide GC to a customer who wanted it and was willing to pay. In fact
> my memory at ALsys was we never had EVEN ONE customer who was interested
> enough in GC to even ask about it. The same is true in our experience with
> GNAT.
> No customer has ever asked for GC, and they certainly have asked for many
> other things.
If you are doing embedded systems, then you can't use GC. Unfortunately,
this dooms Ada to that niche.
Go to the source, what does Ichbiah say? Hey Ichy, did you expect
(in 1983) for Ada83 systems for doing non-embedded applications, say business
apps, to have GC? I would be amazed if he says no. Look at the
Ada Booch components, not a single "free" in the whole library.
Surely, he Booch was expecting GC.
>
> You can of course use conservative GC's of various varieties with most
> Ada 83 and Ada 95 compilers. I never bumped into an Ada application that
> took advantage of this possibility.
>
> I think that the DoD would have been way out of line dictating what particular
> implementation characteristics were needed in implementations of Ada, instead
> of leaving this up to the individual projects.
They can turn off the GC. I don't see what your problem with having a
GC requirement on a Ada83 for a business system.
IMHO, the DOD free market Ada compiler experiment was a complete failure.
Free markets don't work in the defense field. The should have paid a
set of Ada vendors whatever $$$ it took (maybe you) back in early 80's to
build and maintain a suite of Ada compilers and then gave them all away
for massive number of system configurations. Heh, there should have been
GCC_Ada1, GCC_Ada2 and GCC_Ada3. Then they should have paid massive bucks
to these venders to have every system library known to man to have an Ada
version almost immediately. How many billions would it have taken for success?
>
> The fact that users of Ada did not ask for Jay's pet-feature-of-the-day has
> nothing to do with mismanagement, and everything to do with actual requirements.
The mismanagement is that the DOD did not push Ada beyond the immediate
requirements of defense embedded systems. Its a chicken or the egg
situation: You can't portably rely on GC until a good number of compilers
support it, so nobody uses it and thus there is no pressing demand for it.
This is where management needs to step in and break the cycle.
Jay
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-08-01 0:00 ` Jay Martin
@ 1998-08-02 0:00 ` Matthew Heaney
1998-08-02 0:00 ` Lars Farm
1998-08-02 0:00 ` Matthew Heaney
1 sibling, 1 reply; 43+ messages in thread
From: Matthew Heaney @ 1998-08-02 0:00 UTC (permalink / raw)
Jay Martin <jaymmartin@earthlink.net> writes:
> The mismanagement is that the DOD did not push Ada beyond the immediate
> requirements of defense embedded systems.
This statement is a bit ironic, since you often hear the opposite
complaint: that Ada (83) went too far in trying to be an all-purpose
language, and that the DoD should have settled for a _smaller_ language,
with only the features specifically required for "defense embedded
systems."
It was during his Turing Award speech that Tony Hoare warned that "the
fate of mankind" was a stake because Ada included ... exceptions!
Imagine what he'd say about a language that mandated garbage collection.
The perception in the software community (largely due to Hoare's speech)
was that Ada was "too large and complex." You would never have sold the
language had it thrown in a garbage collector too.
And as Robert has pointed out in this and other threads, GNAT customers
aren't much interested in GC.
Matt
P.S. The debate about languages being "complex" vs "feature-rich" was
debated a few weeks back on comp.object. Get thee to dejanews for the
gory details. (Hint: Ada is a large language, but not "complex" in the
sense that is usually bandied about.)
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-08-02 0:00 ` Matthew Heaney
@ 1998-08-02 0:00 ` Lars Farm
1998-08-02 0:00 ` Matthew Heaney
1998-08-10 0:00 ` Robert I. Eachus
0 siblings, 2 replies; 43+ messages in thread
From: Lars Farm @ 1998-08-02 0:00 UTC (permalink / raw)
Matthew Heaney <matthew_heaney@acm.org> wrote:
> It was during his Turing Award speech that Tony Hoare warned that "the
> fate of mankind" was a stake because Ada included ... exceptions!
> Imagine what he'd say about a language that mandated garbage collection.
Are you saying tht GC would introduce a larger risk for incorrect
programs than exceptions? If so, why?
--
Lars Farm; lars.farm@ite.mh.se - Limt/Channelmatic: lars.farm@limt.se
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-08-02 0:00 ` Lars Farm
@ 1998-08-02 0:00 ` Matthew Heaney
1998-08-02 0:00 ` Lars Farm
1998-08-10 0:00 ` Robert I. Eachus
1 sibling, 1 reply; 43+ messages in thread
From: Matthew Heaney @ 1998-08-02 0:00 UTC (permalink / raw)
lars.farm@ite.mh.se (Lars Farm) writes:
> Matthew Heaney <matthew_heaney@acm.org> wrote:
>
> > It was during his Turing Award speech that Tony Hoare warned that "the
> > fate of mankind" was a stake because Ada included ... exceptions!
> > Imagine what he'd say about a language that mandated garbage collection.
>
> Are you saying tht GC would introduce a larger risk for incorrect
> programs than exceptions? If so, why?
What I was trying to say is that Hoare objected to the size of the
langauge. Mandating garbage collection would only have made the
language larger.
I'm only guessing what Tony would think. Maybe he'd actually like
having a garbage collector.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-08-02 0:00 ` Matthew Heaney
@ 1998-08-02 0:00 ` Lars Farm
0 siblings, 0 replies; 43+ messages in thread
From: Lars Farm @ 1998-08-02 0:00 UTC (permalink / raw)
Matthew Heaney <matthew_heaney@acm.org> wrote:
> What I was trying to say is that Hoare objected to the size of the
> langauge. Mandating garbage collection would only have made the
> language larger.
Wouldn't GC make the language smaller? For instance in C++ you could
remove delete and delete[] without adding any syntax at all. One might
perhaps even argue about the value of destructors other constructs if
there was mandatory GC. As far as I can see GC would simplify a
language. Definitely from the users point of view. Perhaps not as seen
by a compiler writer. OTOH the reason we have higher level languages
must be to simplify for those using the language, rather than those
implementing the compilers so I think "smaller" must be taken in the
users context.
> I'm only guessing what Tony would think. Maybe he'd actually like
> having a garbage collector.
One data point is a text he wrote with Dahl in Dahl, Dijkstra, Hoare:
Structured Programming, 1972. They talk about OOP using Simula and argue
that GC is a requirement (p179).
--
Lars Farm; lars.farm@ite.mh.se - Limt/Channelmatic: lars.farm@limt.se
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-08-02 0:00 ` Lars Farm
1998-08-02 0:00 ` Matthew Heaney
@ 1998-08-10 0:00 ` Robert I. Eachus
1 sibling, 0 replies; 43+ messages in thread
From: Robert I. Eachus @ 1998-08-10 0:00 UTC (permalink / raw)
In article <1dd4w22.16p27c7en0bswN@dialup119-1-10.swipnet.se> lars.farm@ite.mh.se (Lars Farm) writes:
> Are you saying tht GC would introduce a larger risk for incorrect
> programs than exceptions? If so, why?
When I write software in Ada that requires storage management, part
of the testing is that 1) all storage that is allocated is later
freed, and 2) it is possible to characterize a limit on maximum memory
usage in terms of user understandable parameters.
The amount of effort to do this is relatively trivial, or has been
every time I have had to consider the issue. Occaisonally I have
found "errors" in the form of unrecoverd memory, and that always
resulted from an obscure bug such as simultaneous updates where one
process violated locking conventions. (In Ada 83, in Ada 95 protected
objects seem to have eliminated that type of bug...)
If garbage collection was implemented, checking heap usage before
and after the program was run would be useless.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-08-01 0:00 ` Jay Martin
1998-08-02 0:00 ` Matthew Heaney
@ 1998-08-02 0:00 ` Matthew Heaney
1998-08-02 0:00 ` Jay Martin
1 sibling, 1 reply; 43+ messages in thread
From: Matthew Heaney @ 1998-08-02 0:00 UTC (permalink / raw)
Jay Martin <jaymmartin@earthlink.net> writes:
> Look at the Ada Booch components, not a single "free" in the whole
> library. Surely, he Booch was expecting GC.
This is incorrect.
His reason for not using Free is NOT because he was "expecting GC." He
explains in his book that he didn't use Unchecked_Deallocation because
it is non-portable.
The Booch components had a very specific taxonomy. Only "unmanaged"
components expect a garbage collector. The "managed" forms do their own
garbage collection (using a storage manager, another component).
In practice, for a data structures library, a garbage collector is NOT
necessary. Ada 95 gives you all the tools you need to implement memory
reclaimation yourself, very simply.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-08-02 0:00 ` Matthew Heaney
@ 1998-08-02 0:00 ` Jay Martin
1998-08-02 0:00 ` Matthew Heaney
0 siblings, 1 reply; 43+ messages in thread
From: Jay Martin @ 1998-08-02 0:00 UTC (permalink / raw)
Matthew Heaney wrote:
>
> Jay Martin <jaymmartin@earthlink.net> writes:
>
> > Look at the Ada Booch components, not a single "free" in the whole
> > library. Surely, he Booch was expecting GC.
>
> This is incorrect.
Booch did expect GC:
"Unmanaged -> Automatic garbage collection is the responsibility
of the underlying run time system and compiler."
> His reason for not using Free is NOT because he was "expecting GC." He
> explains in his book that he didn't use Unchecked_Deallocation because
> it is non-portable.
Which turned out to be a technical mistake, because
I didn't remember a (non-embedded system) Ada compiler that did
not implement "Unchecked_Deallocation". Imagine
the ridicule from C programmers: "You can call malloc
but you can't even call free!."
> The Booch components had a very specific taxonomy. Only "unmanaged"
> components expect a garbage collector. The "managed" forms do their own
> garbage collection (using a storage manager, another component).
Which excepting multi-tasking and fixed sized forms, made up for
roughly half the Booch components, over a 100
component permutation banking on GC.
Jay
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-08-02 0:00 ` Jay Martin
@ 1998-08-02 0:00 ` Matthew Heaney
0 siblings, 0 replies; 43+ messages in thread
From: Matthew Heaney @ 1998-08-02 0:00 UTC (permalink / raw)
Jay Martin <jaymmartin@earthlink.net> writes:
> Which turned out to be a technical mistake, because
> I didn't remember a (non-embedded system) Ada compiler that did
> not implement "Unchecked_Deallocation". Imagine
> the ridicule from C programmers: "You can call malloc
> but you can't even call free!."
It was probably too conservative, since the RM recommends that an
implementation really support UC. And all implementations of Ada really
do support UC.
But even if he did use UC in the implementation of his unmanaged forms,
this isn't good enough, since the client would still have to explicitly
Clear the structure prior to exiting the scope of its declaration.
Otherwise a memory leak would occur. This is what you have to do in the
managed forms too.
I've written an Ada95 data structures library very much like what Booch
provided, that does automatic garbage collection. It wasn't that hard.
> > The Booch components had a very specific taxonomy. Only "unmanaged"
> > components expect a garbage collector. The "managed" forms do their own
> > garbage collection (using a storage manager, another component).
>
> Which excepting multi-tasking and fixed sized forms, made up for
> roughly half the Booch components, over a 100
> component permutation banking on GC.
His taxonomy provides a menu from which you choose the forms that apply
to your situation. You are not expected to use all the forms.
The functionality is the same in both the managed and unmanaged forms.
Just stick to the managed forms, and no GC is necessary.
That "roughly half" of his library "banks on GC" in a weak argument,
because you never use that half of the library.
If the fact that half the library goes unused upsets you, then just go
the the directory where you keep the components, and delete the
unmanaged forms. After you do that, then _none_ of the library will
depend on GC. And you'll have lots of extra disk space too!
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Brian Rogoff
1998-07-29 0:00 ` Charles Hixson
@ 1998-07-29 0:00 ` John McCabe
1 sibling, 0 replies; 43+ messages in thread
From: John McCabe @ 1998-07-29 0:00 UTC (permalink / raw)
Brian Rogoff <bpr@shell5.ba.best.com> wrote:
>This isn't meant as a disagreement with Pat Rogers. I actually like Ada
>and think it is worth knowing, just that if you want to stretch your mind
>and are not solely interested in getting a job using some particular
>language, it might be worth it to you to consider a wider range.
Alternatively, if you want to earn lots of money from a dead language,
learn Occam and move to the UK as a software contractor. I've had a few
calls about Occam jobs, there are a few legacy apps out there that can't
move away from Occam, but I'm not prepared to risk it.
--
Best Regards
John McCabe
=====================================================================
Not necessarily my company or service providers opinions.
=====================================================================
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Dave Martin
1998-07-29 0:00 ` Pat Rogers
@ 1998-07-29 0:00 ` John McCabe
1998-07-29 0:00 ` nabbasi
1998-07-29 0:00 ` Rakesh Malhotra
1998-07-29 0:00 ` Jean-Pierre Rosen
3 siblings, 1 reply; 43+ messages in thread
From: John McCabe @ 1998-07-29 0:00 UTC (permalink / raw)
Just for the sake of interest, when I first started watching this
newsgroup (comp.lang.ada) around 3.5 years ago, it was very much from the
point of view of wanting to convince people that Ada is not worth the
effort any more. Looking back, I found that there were a few, let�s say,
inadequacies in Ada 83 that, in my view, let down the whole language.
Also at the time I much preferred the C language (actually I liked Occam
even better, but it never really caught on!), and hated the idea that I
was being forced to use Ada against what I considered to be my better
judgement.
My views on Ada have completely changed since then. It was pointed out by
a number of very helpful people around here that there were reasons and
workarounds for the �inadequacies� I mentioned, but also that some of
them at least had been addressed in Ada 95 and so were not relevant any
more, however the main turning point came when I got gold of the GNAT
compiler just to write a fairly noddy program which would hopefully run
on both a PC and Sun Workstation. Normally I would have knocked this up
in C and spent some time debugging it. This time I decided to try Ada and
found that once I�d managed to get the program to compile, it pretty much
did what I had wanted (apart from a few very trivial, and very easy to
find bugs). When I ported it across to Solaris, and recompiled with GNAT
for Solaris, it worked first time!
This would never have happened if I�d written it in C.
As far as C++ is concerned, I spent a long time trying to persuade my
boss to let me go on a C++ course. I never got it as there was apparently
no need for it (despite the fact that even Ada contract software guys are
now getting the opportunity to learn C++ in that department!! - I left 1
year ago). My view now is that I would still like to learn C++, but only
really for interest, from what I know of Ada 95 and C++, Ada 95 certainly
seems to be the more understandable language and, with the increasing
size and complexity of software systems which require maintenance, I know
what I�d rather maintain.
--
Best Regards
John McCabe
=====================================================================
Not necessarily my company or service providers opinions.
=====================================================================
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` John McCabe
@ 1998-07-29 0:00 ` nabbasi
1998-08-08 0:00 ` Michael Young
0 siblings, 1 reply; 43+ messages in thread
From: nabbasi @ 1998-07-29 0:00 UTC (permalink / raw)
In article <6pmmd7$5t7@gcsin3.geccs.gecm.com>, John says...
> My view now is that I would still like to learn C++, but only
>really for interest, from what I know of Ada 95 and C++, Ada 95 certainly
>seems to be the more understandable language and, with the increasing
>size and complexity of software systems which require maintenance, I know
>what I d rather maintain.
>
you might be interested in this C++ critque (sp?) :
http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html
in particular this section:
http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3/sect3/
Nasser
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Why C++ is successful
1998-07-29 0:00 ` nabbasi
@ 1998-08-08 0:00 ` Michael Young
0 siblings, 0 replies; 43+ messages in thread
From: Michael Young @ 1998-08-08 0:00 UTC (permalink / raw)
That's a particularly unfortunate citation. The author, Ian Joyner,
demonstrates small understanding of OOP and C++. We can discuss each of
his points one by one, if you like, but I believe you'll agree after a
cursory reading.
Michael.
nabbasi@earthlink.net wrote:
>
> In article <6pmmd7$5t7@gcsin3.geccs.gecm.com>, John says...
>
> > My view now is that I would still like to learn C++, but only
> >really for interest, from what I know of Ada 95 and C++, Ada 95 certainly
> >seems to be the more understandable language and, with the increasing
> >size and complexity of software systems which require maintenance, I know
> >what I d rather maintain.
> >
>
> you might be interested in this C++ critque (sp?) :
>
> http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html
>
> in particular this section:
>
> http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3/sect3/
>
> Nasser
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Dave Martin
1998-07-29 0:00 ` Pat Rogers
1998-07-29 0:00 ` John McCabe
@ 1998-07-29 0:00 ` Rakesh Malhotra
1998-07-29 0:00 ` Jean-Pierre Rosen
3 siblings, 0 replies; 43+ messages in thread
From: Rakesh Malhotra @ 1998-07-29 0:00 UTC (permalink / raw)
Dave Martin wrote:
>
> I certainly wasn't trying to attack ada and I hope it didn't come off
> that way. I was just relating the experiences that I had. Its true
[stuff deleted]
Nope, I certainly did not feel that you were attacking Ada (or any other
language, for that matter). Your post was just about what you went
through/are going through in learning different languages.
The only reason I bothered to reply was for the benefit of those who may
have read your post and arrived at uninformed conclusions about Ada.
Incidentally, if you decide to get on the Java bandwagon, there have
been Ada to Java-byte code compilers available for some time. These
give you the benefit of programming in Ada while being able to use all
the Java API's.
Thanks
--
Rakesh
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Why C++ is successful
1998-07-29 0:00 ` Dave Martin
` (2 preceding siblings ...)
1998-07-29 0:00 ` Rakesh Malhotra
@ 1998-07-29 0:00 ` Jean-Pierre Rosen
3 siblings, 0 replies; 43+ messages in thread
From: Jean-Pierre Rosen @ 1998-07-29 0:00 UTC (permalink / raw)
Dave Martin a �crit dans le message <35bebe5f.95187031@netnews.msn.com>...
>I personally haven't learned Ada (83/95) yet, so I hesitate to say
>anything one way or the other about it, though I will admit to being
>influenced by my friends occasionally on the subject. I know many
>people who hate Ada, and I know there are many others who swear by it.
>
A short comment on this from someone who has been teaching/consulting in Ada
since 1980 (no typo here!)
I too have met people who hated Ada (no need to comment on the other ones
:-). Most of the time, it was either because of 1) problems with compilers
or 2) improper training.
As far as 1) is concerned, people see the language through the compiler. If
the compiler is poor, they have a feeling that the language is poor. The
strange thing is that quite often, they refuse to change compiler, and would
rather change language instead. Fortunately, current compilers are much
better, so we can expect this reason to vanish in the future.
As for 2), "Ada is more than just another programming language". Although it
syntactically looks like an enhanced Pascal, programming in Ada requires a
different state of mind. You don't program a computer, you design an
application, the compiler is in charge of bridging the gap between your high
level description and the machine level. People who were not properly
trained often do not understand this different approach, and get very poor
results, with a feeling that strong typing "gets in the way". As Booch
pointed out: "Give a power drill to a carpenter who has never heard of
electricity, and he'll use it as a hammer. He'll bend a few nails and smash
his fingers, because a power drill make a lousy hammer".
I can tell from experience that *very often*, my students tell me a the end
of the course that the language they have discovered was completely
different from what they had heard about it...
--
----------------------------------------------------------------------------
J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog
^ permalink raw reply [flat|nested] 43+ messages in thread