NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/ada/3763

Text File | 1992-12-21 | 3.2 KB | 66 lines

Newsgroups: comp.lang.ada
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!milano!teenwolf.mcc.com!srogers
From: [e-mail] (Steve Rogers)
Subject: Re: C++ vs. Ada -- Is Ada loosing?
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: MCC, Austin, Texas
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 18 Dec 1992 14:14:48 GMT
Lines: 54

In article <[e-mail]> [e-mail] (Richard A. O'Keefe) writes:

>Just recentrly, I posted an article to comp.lang.c in which I listed a
>number of errors in a textbook.  The textbook is about data structures
>in C.  The authors understand data structures very well. . . . .

    <deleted>

>I believe that Ada is a bigger language than C.  Both languages have "dark
>corners".  But there seems to be a tradition of Ada compilers being picky
>and C compilers letting it all hang out.  With all due respect to "The
>Emperor's New Clothes", which I loved when it came out, I am now _more_
>frightened about critical software being written in C or C++ than in Ada.
>
>My current impression is that Ada textbooks tend to be more accurate in
>the claims they make about what is or is not valid Ada, and tend to have
>a higher level view of the software process, than C books.  Is this an
>illusion, due to my knowing C relatively better than I know Ada?
>

I'm not sure this is true; the Barnes Ada book has LOTS of examples that
violate the LRM.  I think perhaps it's more of a way of teaching than
a symptom of the particular language.  In my CS education, many instructors
(and books) adopted a method of presenting a narrow version of the language
as though it were the whole truth, then expanding it in steps with each
new lesson; perhaps under the theory that this would make it easier to
grasp the wider concepts.  I found it tiring after a while.  It would
go something like (exaggerated)

1. Variables are letters A-Z.  Use like A = 1.
2. Yesterday we learned variables are letters, today we will see that
   variables can have numbers appended for extra clarity.  Like A1 = 1.
3. Today we see that variables can also have multiple letters and
   underscores for even more clarity: ADD_VALUE = 1
. . . .

The frustrating thing is that they would never get around to specifying
the fundamental principle behind the concept.  Eventually you find
yourself saying: OK, OK, but what is a variable, *really*?  It
seems more natural, IMHO, to start with the broad statement, then explain
what it means with examples in various contexts; rather than assume an
inital narrow context, then try to expand to more general cases.

I would say that C instruction does this more than Ada instruction, but
by no means is it a C phenomena.  I don't know what the mistakes were
that you found, but the ones I have noticed in the Barnes book are
all due to simplification.  I attribute it to the idea (IMHO mistaken)
that a student can benefit from an example that illustrates an idea
in a very clear and simple way, but which is invalid in the full context
of the language.

--
| Steven Rogers  MCC/ESL  3500 West Balcones Drive
| Austin, Texas 78759-6509  [phone] [e-mail]