TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: Simon Wright <[log in to unmask]>
Date: Fri, 6 Dec 2002 22:19:18 GMT
Reply-To: Simon Wright <[log in to unmask]>
Parts/Attachments: text/plain (67 lines)
> From: "Alexandre E. Kopilovitch" <[log in to unmask]>

> Well, I'll try. The difficulty is that I can't, in principle,
> present a concrete example. If a problem has good description then
> of course, Ada is better, safer etc. language for it then C++. And
> if you believe that programming always follows satisfactory
> description of the problem then you surely will not see my
> point. But in my experience, in many real cases programmers aren't
> provided with such a description, and are forced to explore the
> domain area themselves, and at the same time they must demonstrate
> their progress in coding.

Strange definition of progress, since they have no real idea which way
they should be going. So they may be proceeding in the wrong direction
..

>   In that situation, C++ is better both pragmatically and
> theoretically. The pragmatic benefits are, I think, quite obvious;
> but the theoretical difference needs an explanation, I agree. In my
> opinion, the difference is in that C++'s basic paradigm is
> class/object, which is an adequate notion for direct simulation.  We
> can simply model every visible real entity kind with a class, and
> then play with those classes/objects. It is important that we may
> freely add new classes to our pyramid, inherit from them, make
> "friends", etc. In other words, we can go ahead, "make progress". As
> partial description of the problem becomes available, we may (and
> usually do) reflect our acquired knowledge in some "design", but
> anyway we may go ahead.

>   But with Ada the picture is rather different. The strength of Ada
> typing system is useless because we know too little about the types
> we need in near future. And what is Ada package - which real thing
> it corresponds? So, if we don't know enough about the problem then
> all Ada's major tools become useless.  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++.

> I think that most people (concerned with the choice) intuitively
> feel that Ada isn't a proper tool for programming in high
> uncertainity within a problem statement, and do not even try - so
> there should not be failures caused by Ada.

This may be the real world as you see it, but it seems quite bizarre
to me.

If you don't understand your problem domain, the last thing you should
be doing is writing any sort of code at all. You should be standing
round whiteboards deciding, preferably with customer help, what the
problem actually is. Write tech notes. Talk. Argue. When you find you
were wrong, wipe the whiteboard and start over.

After a while you may know enough for it to be worth doing some
relatively formal modelling. Nowadays you'll probably use UML, but
still it's not worth filling in all details until your understanding
grows. By now you shouldn't need to wipe the whole model, but there
will certainly be mistakes.

After that, get coding! (if you care to, you can make the UML models
precise enough to generate code from, your choice).

All the time, the level of formality and investment should match the
degree of certainty. Even the laziest C++ program or Perl script needs
too much investment for your managers to be willing to throw it away;
so don't write them.

ATOM RSS1 RSS2