Ada / C++ comparison paper

Ada / C++ comparison paper

[Martin Dowie]

Does anyone have a copy of

"Cplpl2Ada.html Contrast to C++ by Edmond Schonberg"

TIA

Re: Ada / C++ comparison paper

[Frode Tenneboe]

Martin Dowie <martin.dowie@nospam.baesystems.com> wrote:
> Does anyone have a copy of
> "Cplpl2Ada.html Contrast to C++ by Edmond Schonberg"

Is this the one you are looking for?

http://www.informatik.uni-stuttgart.de//ifi/ps/AdaBasis/pal_1195/ada/ajpo/flyers/9x-cplus.txt

 -Frode


-- 
^ Frode Tenneb�                    | email: ft@edh.ericsson.se      ^
| Ericsson Radar AS. N-1788 Halden |                                |
| Phone: +47 69 21 41 47           | Frode@IRC                      |
| with Standard.Disclaimer; use Standard.Disclaimer;                |

Re: Ada / C++ comparison paper

[Hyman Rosen]

"Frode Tenneboe" <ft@alne.edh.ericsson.se> wrote in message
news:1008601517.470745@edh3...
>
http://www.informatik.uni-stuttgart.de//ifi/ps/AdaBasis/pal_1195/ada/ajpo/fl
yers/9x-cplus.txt

Just be aware when reading this paper that it's approaching ten years of
age,
and is full of the typical lies, half-truths, and drive-by shootings that
frustrated
Ada advocates always promulgate against C++.

Re: Ada / C++ comparison paper

[David C. Hoos]

Agreed that the cited paper is approaching ten years of age --
but would you do the kind service to the community of
pointing out just which are the "typical lies, half-truths, and
drive-by shootings" of which this paper is "full?"

I, for one, do not wish to repeat "typical lies, half-truths,
and drive-by shootings" in my advocacy of Ada.

Thank you, sincerely

----- Original Message -----
From: "Hyman Rosen" <hyrosen@mail.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Monday, December 17, 2001 4:07 PM
Subject: Re: Ada / C++ comparison paper


> "Frode Tenneboe" <ft@alne.edh.ericsson.se> wrote in message
> news:1008601517.470745@edh3...
> >
>
http://www.informatik.uni-stuttgart.de//ifi/ps/AdaBasis/pal_1195/ada/ajpo/fl
> yers/9x-cplus.txt
>
> Just be aware when reading this paper that it's approaching ten years of
> age,
> and is full of the typical lies, half-truths, and drive-by shootings that
> frustrated
> Ada advocates always promulgate against C++.
>
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: Ada / C++ comparison paper

[Marin David Condic]

I read the paper - that sounds maybe a tad harsh as criticism might go. Yes,
its old and certainly written from a perspective of advocacy, but it didn't
seem to be out *slandering* C++. The author(s) definitely have a bias, but
that isn't necessarily bad so long as they don't start spreading rumors
about C++ having illigitimate children and a bad drug habbit. :-) (Of
course, these days, that would probably just mean that C++ was some
Hollywood celebrity - and it wouldn't be rumor, but rather, a direct quote
from its autobiography. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1008626816.690418@master.nyc.kbcfp.com...
>
> Just be aware when reading this paper that it's approaching ten years of
> age,
> and is full of the typical lies, half-truths, and drive-by shootings that
> frustrated
> Ada advocates always promulgate against C++.
>
>
>

Re: Ada / C++ comparison paper

[Ed Falis]

Marin David Condic wrote:

> I read the paper - that sounds maybe a tad harsh as criticism might go. Yes,
> its old and certainly written from a perspective of advocacy, but it didn't
> seem to be out *slandering* C++. The author(s) definitely have a bias, but
> that isn't necessarily bad so long as they don't start spreading rumors
> about C++ having illigitimate children and a bad drug habbit. :-) (Of
> course, these days, that would probably just mean that C++ was some
> Hollywood celebrity - and it wouldn't be rumor, but rather, a direct quote
> from its autobiography. :-)


Course, if you want to pick up a real C++ slammer, try Objects 
Unencapsulated by Ian Joyner.  I guarantee that whatever Ed wrote will 
be completely eclipsed. ;-)

- Ed

Re: Ada / C++ comparison paper

[martin.m.dowie]

"Ed Falis" <efalis@mediaone.net> wrote in message
news:3C1E941C.5010402@mediaone.net...
> Marin David Condic wrote:
>
> Course, if you want to pick up a real C++ slammer, try Objects
> Unencapsulated by Ian Joyner.  I guarantee that whatever Ed wrote will
> be completely eclipsed. ;-)

Just in case anyone hasn't read that paper, here's a link

http://www.elj.com/cppcv3/

(it is one of the most thought out papers I've come across)

Re: Ada / C++ comparison paper

[Marin David Condic]

I could only get the TOC and Abstract to come up. Everything else seemed to
be unavailable. It could be my server - or their server - or have the guts
of the paper been removed? Can anyone else get to it?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:P2ET7.25032$4e3.3277598@news6-win.server.ntlworld.com...
> "Ed Falis" <efalis@mediaone.net> wrote in message
> news:3C1E941C.5010402@mediaone.net...
>
> Just in case anyone hasn't read that paper, here's a link
>
> http://www.elj.com/cppcv3/
>

Re: Ada / C++ comparison paper

[Hyman Rosen]

"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:P2ET7.25032$4e3.3277598@news6-win.server.ntlworld.com...
> "Ed Falis" <efalis@mediaone.net> wrote in message
> news:3C1E941C.5010402@mediaone.net...
> > Marin David Condic wrote:
> >
> > Course, if you want to pick up a real C++ slammer, try Objects
> > Unencapsulated by Ian Joyner.  I guarantee that whatever Ed wrote will
> > be completely eclipsed. ;-)
>
> Just in case anyone hasn't read that paper, here's a link
>
> http://www.elj.com/cppcv3/
>
> (it is one of the most thought out papers I've come across)

I was immediately drawn to section 3.2, where the author argues
for whole-program type analysis. In a world of dynamic libraries
and run-time code module loading, this is a futile hope. The author
is an Eiffel advocate, and the need for whole-program analysis is
entirely because of Eiffel's misbegotten feature of allowing a derived
class to inherit its parents' methods but to restrict the parameter
types, so that the child is not substitutable for its parent.

Eiffel is less used than Ada, so I suppose the flop sweat is greater.
Anyway, as this is neither a C++ nor an Eiffel group, I will refrain
from further criticism of this paper.

Re: Ada / C++ comparison paper

[Greg C]

"Hyman Rosen" <hyrosen@mail.com> wrote in message news:<1008697855.857274@master.nyc.kbcfp.com>...
[...]
 The author
> is an Eiffel advocate, and the need for whole-program analysis is
> entirely because of Eiffel's misbegotten feature of allowing a derived
> class to inherit its parents' methods but to restrict the parameter
> types, so that the child is not substitutable for its parent.
> 

Actually, this is not true. In Eiffel the parent's methods can declare
parameter types such that child classes can be substituted.

See for an example the discussion on anchored types, section 16.7 of
"Object-Oriented Software Construction" 2nd Ed.

Greg

Re: Ada / C++ comparison paper

[Hyman Rosen]

"Greg C" <gmc444@yahoo.com> wrote in message
news:62340e2a.0112190810.16f029ff@posting.google.com...
> Actually, this is not true. In Eiffel the parent's methods can declare
> parameter types such that child classes can be substituted.

"Can" but not "must". In C++ terms, Eiffel allows this:

struct a { virtual void f(const a &p_a) const; };
struct b : a { virtual void f(const b &p_b) const; };

with b::f considered the overrider of a::f. Now, suppose
I have this function:

void apply(const a &a1, const a &a2) { a1.f(a2); }

Even though this compiles without any problem, I have
no assurance that it will not fail at runtime, because it's
possible for a1 to refer to a "b" object while a2 refers
to an "a" object. Eiffel advocates hope for whole-program
analysis to save them from this by trying to track whether
such a case actually arises. Feh.

Re: Ada / C++ comparison paper

[Greg C]

"Hyman Rosen" <hyrosen@mail.com> wrote in message news:<1008859296.991767@master.nyc.kbcfp.com>...
> "Greg C" <gmc444@yahoo.com> wrote in message
> news:62340e2a.0112190810.16f029ff@posting.google.com...
> > Actually, this is not true. In Eiffel the parent's methods can declare
> > parameter types such that child classes can be substituted.
> 
> "Can" but not "must". In C++ terms, Eiffel allows this:
> 
> struct a { virtual void f(const a &p_a) const; };
> struct b : a { virtual void f(const b &p_b) const; };
> 
> with b::f considered the overrider of a::f. Now, suppose
> I have this function:
> 
> void apply(const a &a1, const a &a2) { a1.f(a2); }
> 
> Even though this compiles without any problem, I have
> no assurance that it will not fail at runtime, because it's
> possible for a1 to refer to a "b" object while a2 refers
> to an "a" object. Eiffel advocates hope for whole-program
> analysis to save them from this by trying to track whether
> such a case actually arises. Feh.

Well, this is getting way off-topic for comp.lang.ada, but here
is an Eiffel version of what you sketched out above, compiled
and executed with the SmallEiffel compiler
(http://smalleiffel.loria.fr)

The compiler doesn't catch B referencing an A object at compile time,
but it the error can be trapped at runtime with an assertion declared
in A. Even though class B redefines "foo" the redefined version still
has to conform to A's contract, and indeed, the violation you talk
about is detected.

I think the notion that these violations can be found at compile time
is an ideal , but Eiffel compiler writers understand that this is an
ideal only and so there are facilities to detect these kinds of
problems at runtime.

Greg

------------
class A creation make
feature 
   make is do end 

   foo(in: like Current) is 
      require 
         in.conforms_to(Current)
      do  
         print("Foo of A%N")
      end 
end -- A
-----
class B
inherit A redefine foo end; 
creation make

feature 
   foo(in: B) is 
      do  
         print("foo B%N")
      end 
end -- B
--------
class TEST
creation make
feature 
   make is 
      local a, ab: A;
      do  
         create a.make;
         create {B} ab.make;
         apply(a,a);
         apply(a,ab);
         apply(ab,ab);
         apply(ab,a)  -- Assertion violation
      end 
feature 
   apply(one, two: A) is 
      do  
         one.foo(two)
      end 
end -- TEST

------------- output
Foo of A
Foo of A
foo B
Line : 7 column 15 in .\a.e.
*** Error at Run Time *** :
   Target is not valid (not the good type).
   Expected: "B", Actual: "A".

Re: Ada / C++ comparison paper

[Wes Groleau]

Hyman Rosen wrote:
> > > Marin David Condic wrote:
> > >
> > > Course, if you want to pick up a real C++ slammer, try Objects
> > > Unencapsulated by Ian Joyner.  I guarantee that whatever Ed wrote will
> > > be completely eclipsed. ;-)
> 
> Eiffel is less used than Ada, so I suppose the flop sweat is greater.
> Anyway, as this is neither a C++ nor an Eiffel group, I will refrain
> from further criticism of this paper.

Would be interesting to see what Joyner has to say about Ada.
If he knows anything about it, that is.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Ada / C++ comparison paper

[Ed Falis]

> Would be interesting to see what Joyner has to say about Ada.
> If he knows anything about it, that is.


I believe he has no particular opinion, since he's not familiar with it. 
  I think I remember him saying at one time that he'd be interested in 
knowing more.  In looking at the book version of the paper, I'd say he'd 
be critical of some aspects of the language, but more favorable than he 
is to C++ or Java.

- Ed

 

Re: Ada / C++ comparison paper

[Ted Dennison]

In article <3C20FD90.1020100@mediaone.net>, Ed Falis says...
>
>> Would be interesting to see what Joyner has to say about Ada.
>> If he knows anything about it, that is.
>
>
>I believe he has no particular opinion, since he's not familiar with it. 
>  I think I remember him saying at one time that he'd be interested in 
>knowing more.  In looking at the book version of the paper, I'd say he'd 

From the Conclusion (section 5) we have this:

"Ada 95 is certainly aimed at serious software engineering."

That's about the entire extent of his Ada coverage, after about 4 paragraphs on
how Eiffel and Java should be used instead. For someone so harsh on the C++
community for not doing their homework on other languages, I found this a bit
striking.



>be critical of some aspects of the language, but more favorable than he 
>is to C++ or Java.
>
>- Ed
>
> 
>
>

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada / C++ comparison paper

[Richard Riehle]

Ed Falis wrote:

> > Would be interesting to see what Joyner has to say about Ada.
> > If he knows anything about it, that is.
>
> I believe he has no particular opinion, since he's not familiar with it.
>   I think I remember him saying at one time that he'd be interested in
> knowing more.  In looking at the book version of the paper, I'd say he'd
> be critical of some aspects of the language, but more favorable than he
> is to C++ or Java.

I have sat with Ian on many occasions and chatted with him about Ada.
He does have a few things to say about it in the most recent version of his
book.   Ian is, as noted earlier, more favorably inclined toward Eiffel, so
he would not be an Ada advocate.   However, he is not as critical of Ada
as he is of C++.

He has noted, as have many others in the Eiffel community, that Ada has
much to recommend it.   They don't like what they see as the complexity
of having a package enclose the type/class,  the absence of assertions,
the need for much of the syntactical sugar,  the requirement for a private
part of a class/package, and lots of other little things that
Ada and C++ have in common.

As with many Eiffel advocates, Ian has expressed some surprise that Ada
does not have an assertion model.   I have never heard him express an
unfair opinion about Ada.   He is simply more interested in Eiffel.  He is
rather negative about C++, but that comes from his having used both
languages a lot and getting annoyed by the idiosyncrasies and suprises
that seem so common in developing with C++.  I think the ease of use and
lack of suprises that charcterize Eiffel are features (no pun intended)
that former C++ users like about programming in it.

Richard Riehle

Re: Ada / C++ comparison paper

[Larry Kilgallen]

In article <9vls3v$en1$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> I read the paper - that sounds maybe a tad harsh as criticism might go. Yes,
> its old and certainly written from a perspective of advocacy, but it didn't
> seem to be out *slandering* C++. The author(s) definitely have a bias, but
> that isn't necessarily bad so long as they don't start spreading rumors
> about C++ having illigitimate children and a bad drug habbit. :-) (Of
                                                        ^^^^^^
Shouldn't that be "hobbit" ? :-)

Re: Ada / C++ comparison paper

[Matthew Heaney]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1008626816.690418@master.nyc.kbcfp.com...
> Just be aware when reading this paper that it's approaching ten years of
> age, and is full of the typical lies, half-truths, and drive-by shootings
that
> frustrated Ada advocates always promulgate against C++.

Your comment would be more helpful if you could provide specific examples of
the "lies and half-truths" in the paper.

I am fluent in both languages, and I happen to like both languages.  I
haven't read Ed's paper in several years, but maybe now is a good time to
read it again.

Re: Ada / C++ comparison paper

[Hyman Rosen]

David C. Hoos wrote (in an e-mail to me):
> Agreed that the cited paper is approaching ten years of age --
> but would you do the kind service to the community of
> pointing out just which are the "typical lies, half-truths, and
> drive-by shootings" of which this paper is "full?"
>
> I, for one, do not wish to repeat "typical lies, half-truths,
> and drive-by shootings" in my advocacy of Ada.

I don't intend to do a line-by-line refutation, but I'll post a
few examples. I should state that I am not claiming that
C++ is better than Ada, and I'm even willing to entertain
the notion that Ada is better than C++. But that doesn't
mean that every Ada advocacy statement is correct.

The age of the paper makes some claims now completely
false. C++ has a standard, and exceptions and templates
are widely (universally, actually) implemented. C++'s
exception mechanism is unarguably superior to Ada's,
and its template mechanism is arguably so.

The paper claims that Ada's library mechanism is
superior to C++'s ad hocery of Makefiles, tools, and
conventions. But Ada's library mechanism is simply a
description of what depends on what, and what must be
recompiled when something changes. The actual
mechanisms used by Ada compilers are wildly different,
and must be learned anew on each platform. Pray tell,
for example, where the Ada standard mentions
"gnatchop". Indeed, for a long time some Ada library
mechanisms were notorious for "recompile the world"
problems, and programmers would go through
contortions in editing their code to avoid this.

The paper says "Many consider [C++'s friend mechanism]
unsafe, and advise against its use". This is what I mean by
a drive-by shooting, similar to "Many consider Ada's syntax
ugly and difficult to read because it lacks punctuation". In
fact, a C++ programming abstraction is typically formed by
several related classes and non-meber functions, and there
is nothing unsafe in allowing those functions access to internal
class members. Not only that, but the paper itself argues that
Ada's lack of member functions is an advantage of Ada!

The paper claims that code reuse is the critical benefit of OOP.
This is nonsense, implying, among other things, that OOP has
an "eat your spinach" flavor - that it's use in a project is primarily
for the purpose of aiding future projects. I would suggest that
OOP's critical benefit is run-time polymorphism.

Section 4 of the paper is just plain strange. It argues that if I
have a dispatching merge(x, y: parent) function then I want
inheritance to enforce same-tagness on the method which
derived classes inherit. Why? Or more precisely, sometimes
I might and sometimes I might not, but I don't see why it is
an advantage of Ada that it assumes one or the other. The
paper also says that merge defined as a member function in
C++ would take a parent parameter and not a child. But the
object structure means that a child is-a parent, so you could
pass in a child. The section also claims that it is possible in
C++ to "subvert the dispatching mechanism and to call a
dispatching operation with invalid arguments -- and unpredictable
results" but fails to give an example. The reason is that no such
subversion mechanism exists!

The paper argues that C++'s lack of a standard for multi-
tasking and real-time programming leads to the use of ad-hoc,
unportable, and incomplete libraries. It fails to mention that
Ada's lack of standard containers and algorithms leads to the
same (as witness the unending List Strawman thread).

The paper claims that C++ programs "can easily become
contaminated with environmental details". I invite you to read
http://groups.google.com/groups?hl=en&lr=lang_en&selm=7j7d4e%24hc%241%40nnrp
1.deja.com.
What prevents Ada programs from becoming contaminated
with non-standard pragmas and representation clauses?

Re: Ada / C++ comparison paper

[Pat Rogers]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1008690461.380980@master.nyc.kbcfp.com...
> David C. Hoos wrote (in an e-mail to me):
<snip>
> The paper claims that code reuse is the critical benefit of OOP.
> This is nonsense, implying, among other things, that OOP has
> an "eat your spinach" flavor - that it's use in a project is primarily
> for the purpose of aiding future projects. I would suggest that
> OOP's critical benefit is run-time polymorphism.

IMHO, the critical benefit of OOP is the supported separation of code that
will change from code that need not.  Run-time polymorphism is the means to
that end, not the end itself.

Re: Ada / C++ comparison paper

[Hyman Rosen]

"Pat Rogers" <progers@classwide.com> wrote in message
news:c1KT7.543$DR.227521653@newssvr11.news.prodigy.com...
> IMHO, the critical benefit of OOP is the supported separation of code that
> will change from code that need not.  Run-time polymorphism is the means
to
> that end, not the end itself.

I think that this completely misses the essential flavor of OOP.

Re: Ada / C++ comparison paper

[Larry Kilgallen]

In article <1008694804.340918@master.nyc.kbcfp.com>, "Hyman Rosen" <hyrosen@mail.com> writes:
> 
> "Pat Rogers" <progers@classwide.com> wrote in message
> news:c1KT7.543$DR.227521653@newssvr11.news.prodigy.com...
>> IMHO, the critical benefit of OOP is the supported separation of code that
>> will change from code that need not.  Run-time polymorphism is the means
> to
>> that end, not the end itself.
> 
> I think that this completely misses the essential flavor of OOP.

Pat said nothing about flavor -- he talked about _benefit_.

Re: Ada / C++ comparison paper

[Brian Rogoff]

On Tue, 18 Dec 2001, Pat Rogers wrote:
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> > David C. Hoos wrote (in an e-mail to me):
> <snip>
> > The paper claims that code reuse is the critical benefit of OOP.
> > This is nonsense, implying, among other things, that OOP has
> > an "eat your spinach" flavor - that it's use in a project is primarily
> > for the purpose of aiding future projects. I would suggest that
> > OOP's critical benefit is run-time polymorphism.
>
> IMHO, the critical benefit of OOP is the supported separation of code that
> will change from code that need not.  Run-time polymorphism is the means to
> that end, not the end itself.

You can get this separation with a sufficiently powerful module system,
and even Ada (95) has one. This is one of the primary benefits of using
signatures in Ada. No OOP involved.

I kind of agree with Hyman here. "Kind of", because I think that OO is
really overrated and that given a choice between an OO language, like, say
Eiffel or Java, and a powerful enough non-OO language, like SML, or OCaml
without the O, I'd much prefer to work in the latter class :-) of
language. OO is mostly a good way to make a confusing mess with open
recursion, though I have found it convenient at times, and the convenience
comes from the run time dispatching, not so much from the incremental
programming aspects.

In any case, I think Hyman is a bit oversensitive to some of the ignorant
C++ bashing in this n.g. I don't think of C++ as being "a great step
backwards" as some people here have said, and I have made the point many
times that I think some amount of inference/automatic instantiation, like
what C++ has, would be a great thing in an Ada like language. I'd also be
happy with a bit more shorthand, like +:=, and a more distinct array
accessing syntax (like []), etc. Still, its an Ada newsgroup, and I
wonder how many times Hyman has complained about anti-Ada ignorance in
the C++ world...

-- Brian

Re: Ada / C++ comparison paper

[Hyman Rosen]

"Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
news:Pine.BSF.4.40.0112181924260.32168-100000@bpr.best.vwh.net...
> I kind of agree with Hyman here. "Kind of", because I think that OO is
> really overrated ... the convenience comes from the run time dispatching,
> not so much from the incremental programming aspects.

Sure. I was talking about the "critical benefit" of OOP when it's used,
not suggesting that OOP should always be used.

> In any case, I think Hyman is a bit oversensitive to some of the ignorant
> C++ bashing in this n.g. ... Still, its an Ada newsgroup, and I wonder
> how many times Hyman has complained about anti-Ada ignorance in
> the C++ world...

Not many times I'm afraid, because Ada is hardly ever mentioned in the
C++ groups. For those who feel threatened, Ada doesn't represent the
threat. I think that's reserved for Java and C#. I try to do my part on
both sides. I have several times mentioned on the C++ groups that C++
should examine Ada's multitasking features when they finally bite the
bullet and start thinking about how to standardize this in C++. I don't
think I'm oversensitive. Ed's article really is a hatchet job. (By the way,
I actually met him about fifteen years ago, when I was working for a
compiler company.)

was Re: Ada / C++ comparison paper anymore

[Mark Lundquist]

"Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
news:Pine.BSF.4.40.0112181924260.32168-100000@bpr.best.vwh.net...

> I have made the point many
> times that I think some amount of inference/automatic instantiation, like
> what C++ has, would be a great thing in an Ada like language.

Yes.

> I'd also be
> happy with a bit more shorthand, like +:=

As long as it doesn't return a value :-)

I might prefer a more longhand shorthand :-), e.g.

    X'Increment;                        -- (X names object of integer type)
    X'Increase (By => 1.23);     -- (X names object of any numeric type,
here a FP type)
    etc...

No new syntax required...

-- mark

Re: was Re: Ada / C++ comparison paper anymore

[Brian Rogoff]

On Wed, 19 Dec 2001, Mark Lundquist wrote:
> "Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
> news:Pine.BSF.4.40.0112181924260.32168-100000@bpr.best.vwh.net...
>
> > I have made the point many
> > times that I think some amount of inference/automatic instantiation, like
> > what C++ has, would be a great thing in an Ada like language.
>
> Yes.

It's good to know that at least *one* more Ada fan likes this capability.

If I put my C++ hat on, what I'd really like over there (also highly
unlikely :-() would be a resyntaxing so that it looked something like
SPECS (?), Damien Conway's "C++ Resyntaxed" proposal. And, of course,
more nesting. In the same way that I think its unfortunate that some
people can't look past Ada syntax flaws, I think its equally sad that
people can't look past C++ syntax flaws to see some of the interesting
(I don't mean that in a pejorative sense here) features of that language.

I don't think either language is my ideal low level language, but each has
aspects worthy of taking. Note that I also consider both to be low level
languages.

> > I'd also be
> > happy with a bit more shorthand, like +:=
>
> As long as it doesn't return a value :-)

Of course!

> I might prefer a more longhand shorthand :-), e.g.
>
>     X'Increment;                        -- (X names object of integer type)
>     X'Increase (By => 1.23);     -- (X names object of any numeric type,
> here a FP type)
>     etc...

Well, you can do something pretty close now with a generic package and the
function call notation. Given that, I'd prefer operators.

I find it easier to read code with some shorthand. I think Ada goes a bit
too far in not having enough, and C++ goes a bit too far in having some
bad syntax and overloaded names. It's easier to forgive C++ here, since it
is supposed to be as compatible with C as possible. I guess the real
mistake in Ada was the requirement about the restricted character set.

Stroustrup made some comment, I forget where, that he wished he could have
started with Algol-68 as a base instead of C, but that obviously that
would have gone nowhere. Sigh. Now that would have been an amazing
language.

-- Brian

Re: was Re: Ada / C++ comparison paper anymore

[Mark Lundquist]

(gee I wonder what happened to the Subject: line... looks like I slipped
with the "paste" shortcut :-)

"Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
news:Pine.BSF.4.40.0112190135400.32168-100000@bpr.best.vwh.net...
> On Wed, 19 Dec 2001, Mark Lundquist wrote:
> > "Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
> > news:Pine.BSF.4.40.0112181924260.32168-100000@bpr.best.vwh.net...
> >
> > > I have made the point many
> > > times that I think some amount of inference/automatic instantiation,
like
> > > what C++ has, would be a great thing in an Ada like language.
> >
> > Yes.
>
> It's good to know that at least *one* more Ada fan likes this capability.

For generic subprograms, it would be _really_ nice.  I'd like to be able to
write this:

        -- An ordinary generic subprogram
        --
        generic
            type T (<>) is private;
            with function F (X  : T);
        function Thunk return T;
        .
        .
        .
        -- Another ordinary generic subprogram
        --
        generic
            type T (<>) is private;
            with function F return T;
        procedure Do_Something;
        .
        .
        .
        -- a call
        --
        Do_Something (Thunk (Some_Function (Some_Object)));

Note:
    (a) the instantiations are implicit (no "new" required);
    (b) the instantiations are anonymous; and
    (c) the actuals to formal type T are inferred

This is just scratching the surface of what could be done, but you get the
idea... Just to play around with, I wrote a package of generics for
functional programming, including a bunch of Thunks, Predicates and logical
operations on the predicates, and composition and identity functions.  It's
fun, but the syntactic overhead of building up the instantiations for any
call is way too heavy.  Plus I have to use crappy names because generics
aren't overloadable (the subject of another thread).  It could be much
more elegant.

There's a suite of enhancements to generics that I plan to write up as a
proposal... sometime before 2005 :-)

>
> > I might prefer a more longhand shorthand :-), e.g.
> >
> >     X'Increment;                        -- (X names object of integer
type)
> >     X'Increase (By => 1.23);     -- (X names object of any numeric type,
> > here a FP type)
> >     etc...
>
> Well, you can do something pretty close now with a generic package and the
> function call notation.

Been there, done that :-)... but I'd rather they were intrinsic.  In a
revised Ada, I'd still prefer the attribute notation over new operators, but
that's just my own taste...

Cheers,
-- mark

-------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting

Re: was Re: Ada / C++ comparison paper anymore

[Patrick Hohmeyer]

Mark Lundquist wrote :

> 
> For generic subprograms, it would be _really_ nice.  I'd like to be able
> to write this:
> 
[snip code]
> 
> Note:
>     (a) the instantiations are implicit (no "new" required);

NOOOOOOOOOOOOOO
Everything automatic (auto-cast, auto-instantiations, etc)
is the root of all bugs.

I consider it one of Ada's greatest *strength* that there is no
auto-instantiation.

Because you can write :

type T1 is //whatever
type T2 is new T1;

procedure P1 is new P_Base(T1); //P_Base is generic

now T1 and T2 have the same content, but different behavior.
And you can be sure that the P1 procedure cant be called
with a T2 variable as parameter.
(Except explicit casting : P1(T1(Variable_Of_T2)); )

If you allow auto-instantiation, this strength of Ada vanishs.

BTW : I would vote for an increment operator too.
I love shortcuts, as long as they dont do things automatic.

-- 
Patrick Hohmeyer

Re: was Re: Ada / C++ comparison paper anymore

[Mark Lundquist]

"Patrick Hohmeyer" <pi3_1415926536@yahoo.ca> wrote in message
news:jG5U7.24823$Yq5.2595738@news20.bellglobal.com...

>
> I consider it one of Ada's greatest *strength* that there is no
> auto-instantiation.
>
> Because you can write :
>
> type T1 is //whatever
> type T2 is new T1;
>
> procedure P1 is new P_Base(T1); //P_Base is generic
>
> now T1 and T2 have the same content, but different behavior.
> And you can be sure that the P1 procedure cant be called
> with a T2 variable as parameter.

No, but if I want to write

    procedure P2 is new P_Base (T2);

I can certainly do that, right?  And while P1 is primitive to T1 and P2 is
not necessarily primitive to T2 (depending on the scope of the
instantiation), an implicit instantiation is obviously not primitive either.
I'm not seeing how my scheme weakens anything at all...  It just results in
a lighter syntax.  Can you please be more specific about *exactly* what
problems you see it causing, and how?  I would be genuinely interested to
know...

-- mark

Re: was Re: Ada / C++ comparison paper anymore

[Patrick Hohmeyer]

Mark Lundquist wrote :

> No, but if I want to write
> 
>     procedure P2 is new P_Base (T2);
> 
> I can certainly do that, right?  And while P1 is primitive to T1 and P2 is
> not necessarily primitive to T2 (depending on the scope of the
> instantiation), an implicit instantiation is obviously not primitive
> either.
> I'm not seeing how my scheme weakens anything at all...  It just results
> in
> a lighter syntax.  Can you please be more specific about *exactly* what
> problems you see it causing, and how?  I would be genuinely interested to
> know...
> 

Ok, an exemple :

procedure X is

   generic
      type Number is range <>;
      type Num_Arr is array (Integer range <>) of Number;
   function Mean(A : Num_Arr) return Number;

   function Mean(A : Num_Arr) return Number is
      Sum : Integer := 0;
   begin
      for I in A'Range loop
         Sum := Sum + Integer(A(I));
      end loop;
      return Number(Sum/A'Length);
   end Mean;


type T_Employes is array(Integer range <>) of Natural;  -- employe numbers
type T_Employe_S is array(Integer range <>) of Natural; -- employe salaries

function Sal_Mean is new Mean(Natural,T_Employe_S);

Employes  : T_Employes(1..1000);
Employe_S : T_Employe_S(1..1000);
Mean_Sal  : Natural;

begin
   Mean_Sal := Sal_Mean(Employe_S); -- line 1
   Mean_Sal := Sal_Mean(Employes);   -- line 2
end X;

--end code -----------------------

First, I know that identifiers as similiar as Employes and
Employe_S are bad.
You can easly mix them and thats exactly the point here.

Line 1 is correct, we calculate the mean salary of our employes.
But Line 2 calculates the mean of the employe numbers.
This makes no sense, and thanks to Ada this dont even compile,
as I haven't defined the Mean function for the employe numbers.

But with your auto-instanciation, I simply would write Mean
and nobody catched the error. It compiles and even *runs* fine,
only the results are completly nonsense.

That's why I'm against auto-instantiations.

People make bugs. And everything that is transformed auto-magicly
helps bugs to survive longer.

-- 
Patrick Hohmeyer

Re: was Re: Ada / C++ comparison paper anymore

[Brian Rogoff]

To which I reply "Don't do that!".

It's quite easy to create similar contrived bug scenarios in Ada without
automatic instantiation of generics using overloading, and, in fact, many
very smart language designers believe that overloading is awful. I
disagree, and think that by applying a bit of intelligence and good taste
overloading makes programs more readable.

To avoid this particular problem, I would avoid the automatic instantiation
by not with-ing the generic unit and instantiating the subprograms that I
want elsewhere and with-ing those. Pretty simple, huh?

-- Brian


On Wed, 19 Dec 2001, Patrick Hohmeyer wrote:
> Mark Lundquist wrote :
>> ... pushing for automatic instantiation of generics, bless you Mark! ...
> Ok, an exemple :
>
> procedure X is
>
>    generic
>       type Number is range <>;
>       type Num_Arr is array (Integer range <>) of Number;
>    function Mean(A : Num_Arr) return Number;
>
>    function Mean(A : Num_Arr) return Number is
>       Sum : Integer := 0;
>    begin
>       for I in A'Range loop
>          Sum := Sum + Integer(A(I));
>       end loop;
>       return Number(Sum/A'Length);
>    end Mean;
>
>
> type T_Employes is array(Integer range <>) of Natural;  -- employe numbers
> type T_Employe_S is array(Integer range <>) of Natural; -- employe salaries
>
> function Sal_Mean is new Mean(Natural,T_Employe_S);
>
> Employes  : T_Employes(1..1000);
> Employe_S : T_Employe_S(1..1000);
> Mean_Sal  : Natural;
>
> begin
>    Mean_Sal := Sal_Mean(Employe_S); -- line 1
>    Mean_Sal := Sal_Mean(Employes);   -- line 2
> end X;
>
> --end code -----------------------
>
> First, I know that identifiers as similiar as Employes and
> Employe_S are bad.
> You can easly mix them and thats exactly the point here.
>
> Line 1 is correct, we calculate the mean salary of our employes.
> But Line 2 calculates the mean of the employe numbers.
> This makes no sense, and thanks to Ada this dont even compile,
> as I haven't defined the Mean function for the employe numbers.
>
> But with your auto-instanciation, I simply would write Mean
> and nobody catched the error. It compiles and even *runs* fine,
> only the results are completly nonsense.
>
> That's why I'm against auto-instantiations.
>
> People make bugs. And everything that is transformed auto-magicly
> helps bugs to survive longer.
>
> --
> Patrick Hohmeyer
>

Re: was Re: Ada / C++ comparison paper anymore

[Patrick Hohmeyer]

Brian Rogoff wrote :

> To which I reply "Don't do that!".
> 
> It's quite easy to create similar contrived bug scenarios in Ada without
> automatic instantiation of generics using overloading, and, in fact, many
> very smart language designers believe that overloading is awful. I
> disagree, and think that by applying a bit of intelligence and good taste
> overloading makes programs more readable.
> 
> To avoid this particular problem, I would avoid the automatic
> instantiation by not with-ing the generic unit and instantiating the
> subprograms that I want elsewhere and with-ing those. Pretty simple, huh?
> 

But this is the C way of doing things :
Let's give the programmer all the possibilities
and it's up to him to use them wisely.

Ada is based on the concept that the language should prevent bugs,
even if this limits the programmer sometimes.

I dont say that the C way is wrong,
but if I want a language that gives me all the possibilities
I wont use Ada, not even a modified Ada, but I'll use C.

Ada should not try to become C with words instead of brackets,
but it should stay with it's "fail-fast" philosophy.
If Ada wants to compete it has to offer something that C hasn't,
and that's the safety of catching of most bugs either at compilation
or at runtime at the line they are produced.
And this even if the programmer is unwise.

So IMO, whatever we change in Ada0x it shouldn't reduce the
ability of the compiler to catch bugs.

-- 
Patrick Hohmeyer

Re: was Re: Ada / C++ comparison paper anymore

[Brian Rogoff]

Well, I hope you don't use

(1) use clauses
(2) overloading (didn't reply to that point, eh?)
(3) tagged types

at all in your Ada programming, since these features are all prone to
misuse, and reduce the ability of the compiler and reader to catch bugs.

Saying something is "the C way" is just a silly form of argumentation.
Ada now allows aliased local variables too, even though Ada 83 didn't
have this feature. Ada also has access parameters, and even access to
subprogram. Lots of Ada features can be abused. Your example is a bit
contrived, and its clear to me (maybe to Mark too) that some amount of
automatic instantiation leads to more readable code.

Ada is just another programming language to me, better than its competitors
as a systems programming language IMO, but far from ideal.

-- Brian

On Thu, 20 Dec 2001, Patrick Hohmeyer wrote:

> Brian Rogoff wrote :
>
> > To which I reply "Don't do that!".
> >
> > It's quite easy to create similar contrived bug scenarios in Ada without
> > automatic instantiation of generics using overloading, and, in fact, many
> > very smart language designers believe that overloading is awful. I
> > disagree, and think that by applying a bit of intelligence and good taste
> > overloading makes programs more readable.
> >
> > To avoid this particular problem, I would avoid the automatic
> > instantiation by not with-ing the generic unit and instantiating the
> > subprograms that I want elsewhere and with-ing those. Pretty simple, huh?
> >
>
> But this is the C way of doing things :
> Let's give the programmer all the possibilities
> and it's up to him to use them wisely.
>
> Ada is based on the concept that the language should prevent bugs,
> even if this limits the programmer sometimes.
>
> I dont say that the C way is wrong,
> but if I want a language that gives me all the possibilities
> I wont use Ada, not even a modified Ada, but I'll use C.
>
> Ada should not try to become C with words instead of brackets,
> but it should stay with it's "fail-fast" philosophy.
> If Ada wants to compete it has to offer something that C hasn't,
> and that's the safety of catching of most bugs either at compilation
> or at runtime at the line they are produced.
> And this even if the programmer is unwise.
>
> So IMO, whatever we change in Ada0x it shouldn't reduce the
> ability of the compiler to catch bugs.
>
> --
> Patrick Hohmeyer
>

Implicit instantiation (was Re: Ada / C++ comparison paper anymore)

[Mark Lundquist]

"Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
news:Pine.BSF.4.40.0112201911250.42005-100000@bpr.best.vwh.net...

> Your example is a bit
> contrived,

A lot contrived, I'd say (no offense to the Patrick H. intended)...

> and its clear to me (maybe to Mark too) that some amount of
> automatic instantiation leads to more readable code.

My only concern right now is whether the inference aspect introduces any
Beaujolais effects.  I haven't thought it through enough to know for sure...

Implicit instantiation (was Re: was Re: Ada / C++ comparison paper anymore)

[Mark Lundquist]

"Patrick Hohmeyer" <pi3_1415926536@yahoo.ca> wrote in message
news:o0qU7.21560$J%2.3180364@news20.bellglobal.com...
>
> But this is the C way of doing things :
> Let's give the programmer all the possibilities
> and it's up to him to use them wisely.
>

Well, let's look at that statement:

    "Let's give the programmer all the possibilities, and it's up to him to
use them wisely."

What is wrong with that?  On the face of it, that actually looks pretty
good.  It seems like the appropriate thing to say to grownups.

So how is that "the C way of doing things"?  What do you really mean?

The problem with C (and C++)  is that to use the language safely, you must:

1) Have command of a large knowledge base of "pitfalls" and "gotchas".  For
C++ this is a special trouble because so many of the pitfalls seem to
involve rather advanced concepts in the language that nonetheless come into
play in rather simple code.

2) Be extra-careful, and

3) Adopt various "defensive programming" practices to protect your code
against others (and yourself, in case (2) fails).


It's that kind of situation that Ada was engineered to avoid.  Not
protecting people from themselves who insist on criminally negligent
programming.  What you want is not "safety scissors", but a powerful tool
with a sharp cutting edge, that is safe when used responsibly.

My suggestion is not "the C way of doing things".

Some language features cause problems in other languages, but the problems
aren't due to the general concept itself (e.g. implicit instantiation), but
to the form it takes in the language and especially in the context of the
general foundation provided by the rest of the language.  So if you start
with a language that has a weak type system and a weak module system, it
makes a minefield of the language and of course the specific features (e.g.
genericity) are going to manifest the problems caused by the underlying
weakness.  Not recognizing this leads to prejudice and FUD about language
features.

By the way, there is no "slippery slope" here.  It's not a case of "oh sure,
today implicit instantiation, tomorrow who-knows-what".  That would be a
very bogus, straw-man argument.

Implicit instantiation would not make Ada into "C without brackets".  That
is just plain silly.

-- mark

Implicit instantiation (was Re: was Re: Ada / C++ comparison paper anymore)

[Mark Lundquist]

"Patrick Hohmeyer" <pi3_1415926536@yahoo.ca> wrote in message
news:DK6U7.24955$Yq5.2627743@news20.bellglobal.com...
>
> Ok, an exemple :
>
> procedure X is
>
>    generic
>       type Number is range <>;
>       type Num_Arr is array (Integer range <>) of Number;
>    function Mean(A : Num_Arr) return Number;
>
>    function Mean(A : Num_Arr) return Number is
>       Sum : Integer := 0;
>    begin
>       for I in A'Range loop
>          Sum := Sum + Integer(A(I));
>       end loop;
>       return Number(Sum/A'Length);
>    end Mean;
>
>
> type T_Employes is array(Integer range <>) of Natural;  -- employe numbers
> type T_Employe_S is array(Integer range <>) of Natural; -- employe
salaries
>
> function Sal_Mean is new Mean(Natural,T_Employe_S);
>
> Employes  : T_Employes(1..1000);
> Employe_S : T_Employe_S(1..1000);
> Mean_Sal  : Natural;
>
> begin
>    Mean_Sal := Sal_Mean(Employe_S); -- line 1
>    Mean_Sal := Sal_Mean(Employes);   -- line 2
> end X;
>
> --end code -----------------------
>
> First, I know that identifiers as similiar as Employes and
> Employe_S are bad.
> You can easly mix them and thats exactly the point here.
>
> Line 1 is correct, we calculate the mean salary of our employes.
> But Line 2 calculates the mean of the employe numbers.
> This makes no sense, and thanks to Ada this dont even compile,
> as I haven't defined the Mean function for the employe numbers

The real problem there is that the programmer made a conscious choice to use
the same type (Natural) for two unrelated abstractions.

Next, they put themselves in the way of trouble by a deliberate
choice of extremely error-prone names.

And your point is that they are still protected, because to make it past the
compiler they would have to screw it up in two places (the instantiation and
the call) instead of just one.

Look, your moron of a programmer now already has about a hundred ways to
hose
him/herself; what's the harm of letting them have one more, if that were
the price of a much more powerful language for the rest of us?  Your example
code is a grenade with the pin pulled, with or without implicit
instantiation.  (I trust I don't need to give an example here...)

I would not consider it a "great strength of Ada" for me to have to deal
with labor-intenstive generics for the sake of a check that benefits only
people who go out of their way to program badly.  Ada is engineered for
safety against normal human error, not error compounded by inexcusably lame
programming practice.

Best Regards,
-- mark

Re: was Re: Ada / C++ comparison paper anymore

[Ted Dennison]

In article <_xRT7.4398$xl6.682759@rwcrnsc54>, Mark Lundquist says...
>"Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
>news:Pine.BSF.4.40.0112181924260.32168-100000@bpr.best.vwh.net...
>
>> happy with a bit more shorthand, like +:=
>
>As long as it doesn't return a value :-)
>
>I might prefer a more longhand shorthand :-), e.g.
>
>    X'Increment;                        -- (X names object of integer type)
>    X'Increase (By => 1.23);     -- (X names object of any numeric type,
>here a FP type)
>    etc...

Actually, 'Succ already does this, but it is a function and doesn't have an
amount. Perhaps if it took an amount, this would be sufficient? But then again,
'Succ works on enumerated types too, which would have us use something
nonsensical like "Month'Succ (Current_Month, February)" to bump the value by 2
enumerations.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: was Re: Ada / C++ comparison paper anymore

[Marin David Condic]

Seems like a lot of complexity and work to get something that doesn't have
much nutritional value anyway. I just barely find it sometimes more useful
to say: "X := Integer'Succ (X);" than to say: "X := X + 1;" and I don't
think it contributes that much to readability, reliability or anything else.
Being able to say: "X := Integer'Succ (X, 2);" doesn't seem to have hardly
any value at all and would make ridiculous looking thing such as you cite
possible.

I just can't remember the last time I wanted to increment by something other
than one where a feature like this would be at all useful. Most cases would
degenerate into something more generally mathematical anyway. Even in
developing C code, I don't find many instances where it is useful to use the
"+=" operator to think that somehow my life would be so much easier if only
I had something similar in Ada.

Why put the compiler writers through all that effort (time that could be
spent incorporating a standard container library? :-) unless there's some
glaring hole that needs to be filled? When talking about language extensions
we probably should remember that the vendor's time can only go so far & we
ought to think in terms of priorities so we get the most additional benefit
from that time.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:sMrU7.5902$XC5.7817@www.newsranger.com...
>
> Actually, 'Succ already does this, but it is a function and doesn't have
an
> amount. Perhaps if it took an amount, this would be sufficient? But then
again,
> 'Succ works on enumerated types too, which would have us use something
> nonsensical like "Month'Succ (Current_Month, February)" to bump the value
by 2
> enumerations.
>

Re: was Re: Ada / C++ comparison paper anymore

[Richard Riehle]

> In article <_xRT7.4398$xl6.682759@rwcrnsc54>, Mark Lundquist says...
> >"Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
> >news:Pine.BSF.4.40.0112181924260.32168-100000@bpr.best.vwh.net...
> >
> >> happy with a bit more shorthand, like +:=
> >
> >As long as it doesn't return a value :-)
> >
> >I might prefer a more longhand shorthand :-), e.g.
> >
> >    X'Increment;                        -- (X names object of integer type)
> >    X'Increase (By => 1.23);     -- (X names object of any numeric type,
> >here a FP type)
> >    etc...

I recall seeing something like this in a program written at one of our client
sites.

            package Counter is
                 type Count is private;
                 function Inc   (Data : Count) return Count;
                 function Dec (Data : Count) return Count;
                 procedure Set_Increment (Data : in out Integer);
                 Overflow, Underflow : exception;
           private
                type Count is ...
           end Counter;

One could easily envision the functions as:

                function Inc   (Data : Count; By : Integer) return Count;
                function Dec (Data : Count; By : Integer) return Count;

It may seem like a little bit of overkill, but worked out quite well
for the problem at hand.   It was useful all through the project
when some kind of counter was needed.   It was easy to abuse
its behavior.  This is not the kind of shorthand that a += might provide,
but it was no hardship for those using it.

Of course, there is no possible Beaujolais effect either.  :-)

Richard Riehle

Re: was Re: Ada / C++ comparison paper anymore

[Marin David Condic]

One excuse for this sort of counter package would be if you need to control
the behavior of the counter's math. Maybe the only good excuse I can think
of is if you want the counters to saturate at some min/max level. Back in
Ada83, it would have made sense if you wanted wraparound semantics for the
counter. (Of course, now that we have unsigned integers, this is not such a
big deal.)

Otherwise, it would seem to me that it is overkill. And if Ada0x creates
some saturated math numeric types, we could get rid of the above case as
well... :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C2374EE.956EF43B@adaworks.com...
>
> It may seem like a little bit of overkill, but worked out quite well
> for the problem at hand.   It was useful all through the project
> when some kind of counter was needed.   It was easy to abuse
> its behavior.  This is not the kind of shorthand that a += might provide,
> but it was no hardship for those using it.
>

Re: Ada / C++ comparison paper

[Mark Lundquist]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1008690461.380980@master.nyc.kbcfp.com...
>[snip...]
> The paper argues that C++'s lack of a standard for multi-
> tasking and real-time programming leads to the use of ad-hoc,
> unportable, and incomplete libraries. It fails to mention that
> Ada's lack of standard containers and algorithms leads to the
> same (as witness the unending List Strawman thread).

That's a cheap shot! :-)  It's too early to say that that thread is
"unending" (sort of like the halting problem :-).

But I agree (and I've made this point in the past), a fair comparison must
consider the whole package: core language + standard libraries.

Re: Ada / C++ comparison paper

[Ted Dennison]

In article <_T4U7.8959$xl6.991260@rwcrnsc54>, Mark Lundquist says...
>
>
>"Hyman Rosen" <hyrosen@mail.com> wrote in message
>news:1008690461.380980@master.nyc.kbcfp.com...
>>[snip...]
>> The paper argues that C++'s lack of a standard for multi-
>> tasking and real-time programming leads to the use of ad-hoc,
>> unportable, and incomplete libraries. It fails to mention that
>> Ada's lack of standard containers and algorithms leads to the
>> same (as witness the unending List Strawman thread).
>
>That's a cheap shot! :-)  It's too early to say that that thread is
>"unending" (sort of like the halting problem :-).

But its a fair one, in that his point was that this stuff is *already* standard
in C++. You'd be hard-pressed to prove that concurrency is more important to the
average developer than containers.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada / C++ comparison paper

[Marin David Condic]

Are you saying its fair to criticize lack of a library or fair to criticize
the "unending" aspect of the List Strawman thread? I'd agree with the former
and disagree with the latter - although it is rapidly approaching time to
shoot the engineers and go into production. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:tQrU7.5909$XC5.7898@www.newsranger.com...
>
> But its a fair one, in that his point was that this stuff is *already*
standard
> in C++. You'd be hard-pressed to prove that concurrency is more important
to the
> average developer than containers.
>

Re: Ada / C++ comparison paper

[Ted Dennison]

In article <9vtjg5$ke0$1@nh.pace.co.uk>, Marin David Condic says...
>and disagree with the latter - although it is rapidly approaching time to
>shoot the engineers and go into production. :-)

Well, I asked if we were at that point a week ago, and I have to say the
response has been quite underwhelming. I think I got one yes and one (emphatic)
no.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada / C++ comparison paper

[Marin David Condic]

Then make it one yes, one emphatic yes and one no.

I see no reason not to start implementing some of the basic features. We may
yet argue about a few names or the addition/deletion of a few subprograms,
but so what? Seems to me we're at a point where we could put some guts
beneath it and start writing a few small demo programs to see how it works.

(BTW - catch me off-line if you can. Thanks.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:vEHU7.6773$XC5.8825@www.newsranger.com...
>
> Well, I asked if we were at that point a week ago, and I have to say the
> response has been quite underwhelming. I think I got one yes and one
(emphatic)
> no.
>

Re: Ada / C++ comparison paper

[Jean-Marc Bourguet]

Ted Dennison<dennison@telepath.com> writes:

> In article <9vtjg5$ke0$1@nh.pace.co.uk>, Marin David Condic says...
> >and disagree with the latter - although it is rapidly approaching time to
> >shoot the engineers and go into production. :-)
> 
> Well, I asked if we were at that point a week ago, and I have to say the
> response has been quite underwhelming. I think I got one yes and one (emphatic)
> no.

One more yes.  Emphatic is you want.

-- 
Jean-Marc

Re: Ada / C++ comparison paper

[tmoran]

> You'd be hard-pressed to prove that concurrency is more important to the
> average developer than containers.
  I'd a whole lot rather have to roll my own container than multi-tasking
system.  And in "average developer" do you include VB programmers, or
are you thinking of embedded/real time programmers?

Re: Ada / C++ comparison paper

[Marin David Condic]

True. Its easier to implement containers than it is to implement
multitasking. But in most kinds of development, tasking is a rarity, but
lists & maps are not. When you need tasks, you *really* need them. But I'd
bet that most programmers go through the bulk of their professional careers
and never write a multitasking app...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


<tmoran@acm.org> wrote in message news:KDtU7.15328$NM4.3204983@rwcrnsc53...
> > You'd be hard-pressed to prove that concurrency is more important to the
> > average developer than containers.
>   I'd a whole lot rather have to roll my own container than multi-tasking
> system.  And in "average developer" do you include VB programmers, or
> are you thinking of embedded/real time programmers?

Re: Ada / C++ comparison paper

[Ted Dennison]

In article <KDtU7.15328$NM4.3204983@rwcrnsc53>, tmoran@acm.org says...
>
>> You'd be hard-pressed to prove that concurrency is more important to the
>> average developer than containers.
>  I'd a whole lot rather have to roll my own container than multi-tasking
>system.  And in "average developer" do you include VB programmers, or
>are you thinking of embedded/real time programmers?

I'm thinking of anyone who would consider using a compiled systems programming
language. For embedded/real time programmers, you have your best case for
concurrency being more important, but you might still have an argument on your
hands. After all, real-time apps have queues and lists all over the place too,
and not every embedded app even has multiple threads.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada / C++ comparison paper

[tmoran]

>>> You'd be hard-pressed to prove that concurrency is more important to the
>>> average developer than containers.
> After all, real-time apps have queues and lists all over the place too,
  It's really easy to roll your own bounded queue.

Re: Ada / C++ comparison paper

[Ted Dennison]

In article <fsLU7.2473$b_.5802@rwcrnsc51.ops.asp.att.net>, tmoran@acm.org
says...
>
>>>> You'd be hard-pressed to prove that concurrency is more important to the
>>>> average developer than containers.
>> After all, real-time apps have queues and lists all over the place too,
>  It's really easy to roll your own bounded queue.

Quite true. On those occasions where you do need standard concurrency support,
you *really* need it.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada / C++ comparison paper

[Mark Lundquist]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:tQrU7.5909$XC5.7898@www.newsranger.com...
> In article <_T4U7.8959$xl6.991260@rwcrnsc54>, Mark Lundquist says...
> >
> >
> >"Hyman Rosen" <hyrosen@mail.com> wrote in message
> >news:1008690461.380980@master.nyc.kbcfp.com...
> >>[snip...]
> >> The paper argues that C++'s lack of a standard for multi-
> >> tasking and real-time programming leads to the use of ad-hoc,
> >> unportable, and incomplete libraries. It fails to mention that
> >> Ada's lack of standard containers and algorithms leads to the
> >> same (as witness the unending List Strawman thread).
> >
> >That's a cheap shot! :-)  It's too early to say that that thread is
> >"unending" (sort of like the halting problem :-).
>
> But its a fair one, in that his point was that this stuff is *already*
standard
> in C++. You'd be hard-pressed to prove that concurrency is more important
to the
> average developer than containers.

No, it's the "undending" part I was referring to...

The point you make above is one that I agree with -- in fact, in the posting
of mine that you quote from, I made exactly that point (in the next
paragraph).

-- mark

Re: Ada / C++ comparison paper

[Ted Dennison]

In article <eoxU7.17089$xl6.1197433@rwcrnsc54>, Mark Lundquist says...
>
>No, it's the "undending" part I was referring to...

Ahh. Well, I'm sure it would seem unending to someone who isn't interested in
the process and has to wade through all of those messages.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.