TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To:
Stephen Leake <[log in to unmask]>
Date:
Sat, 7 Dec 2002 05:47:13 +0300
Reply-To:
"Alexandre E. Kopilovitch" <[log in to unmask]>
Subject:
From:
"Alexandre E. Kopilovitch" <[log in to unmask]>
Content-Type:
text/plain; charset=us-ascii
In-Reply-To:
<[log in to unmask]>; from Stephen Leake at 06 Dec 2002 10:52:53 -0500
Organization:
h w c employees, b f
MIME-Version:
1.0
Parts/Attachments:
text/plain (72 lines)
Stephen Leake <[log in to unmask]> wrote:

>... when I am forced to change the design, Ada finds
>all the inconsistencies for me; C++ just muddles thru, hiding the
>problems.

It's very true, but ... you may be surprised, but Ada behaviour in such a case
is not always the desired thing. I really saw (not once) the situations where
programmers were definitely preferring that "muddles thru, hiding the problems"
against frustation caused by immediate revealing of the problems.

>Ada can do class/object; it can also do other paradigms. If you like
>class/object for a particular project, go ahead and do that.
>
>Ada gives you more choice; C++ restricts your choices.

That's it. C++ explicitly provides *leading* paradigm, you are free of burden
of choice - note, that this is not a routinely choice - you have to choose a
paradigm, and that will lead to many consequences.

>On the other hand, Ada can be used in a way that is just as weakly
>typed as C++; always use Integer, etc.

I think that is almost impossible - psychologically. If you know the role
of types in Ada then you will always feel the strong temptation to introduce
distinct types. It is certainly less painful to use C/C++ in such a case.

>> And what is Ada package - which real thing it corresponds?
>
>A package with a type and operations is a class.
>
>A package with hidden state is an object.
>
>etc, etc, etc. Yes, you have to pick a paradigm to use; sometimes that
>is hard.

And this is the point. Why take such a challenge - and responsibility, when
you may switch to C++ and rely upon popular and respectable single solution?
  Well, one can say that Ada in fact has its own leading paradigm - the "package".
But that paradigm is connected more to the world of theories than to the world
of observable realities. So, if you deal with your problem through theories
then you can use the "package" paradigm effectively, and all goes fine; but my
speech is about a situation where you have no theoretical supply and therefore
you are forced to observe raw reality.

>> So, if we don't know enough about the problem then all Ada's major
>> tools become useless.
>
>Even if they are "useless", they are not "negative".

Not always. Sometimes useless things become negative - simply because of
someone's temptation for making use of them.

>> Ada facilitates stratification of the "problem space"; that is
>> strategic advantage when we have enough (perhaps, informal)
>> knowledge about the problem, but if not - then we are forced to
>> model/simulate the reality directly, and Ada do not facilitate that
>> as conveniently as C++.

>Hmm. You have not said why Ada is _worse_ than C++. Well, you did say
>"Ada doesn't do class/object", but that is not true.

I did not say "Ada doesn't do class/object" - reread please - I did say
"Ada do not facilitate that as conveniently as C++". Perhaps I'd better use
word "freely" instead of "conveniently", but for many programmers those are
the same.


Alexander Kopilovitch                      [log in to unmask]
Saint-Petersburg
Russia

ATOM RSS1 RSS2