Re: "Subtract C, add Ada"

[weisek@source.asset.com (Kevin Weise)]

In article <862035D1F1C@annwfn.com>, Fred McCall <merlin@annwfn.com> wrote:
>In <D1Msq8.4Hs@inmet.camb.inmet.com> mg@asp.camb.inmet.com Mitch Gart writes:
>
>>Ada leaves less room for single-keystroke
>>errors, such as the common C error of using = (assignment) instead of
>>== (comparison); 
>
>I've always been curious.  Just *where* is this a "common C error"?
>I've seen lots of beginners and non-C programmers claim it is, but I
>don't recall ever hearing of anyone who knew what they were doing (and
>who was using a real tool -- say, lint -- to check their code) making
>it. 

Well, Mr. McCall, I will attempt to respond to this in a fashion that
does not violate netiquette.  However, from previous threads here on
CLA, I believe this is one of your hot buttons.  The fact is, I know
lots of C/C++ people, and quite a few of them agree that this is a
common error they make {e.g., if (var = expr), rather than 
if (var == expr)}.  These people are not beginners; but some of them are
certainly hackers.  Nonetheless, as far as I've seen, this is a
well-known recognized source of common errors.  Certainly a good lint
program will question this usage; that's not at issue.  But I believe
that = vs. == was used as an example of single character errors that
make it through the compiler; certainly it is not the only one.  

>
>>its type-abstraction facilities reduce the need for
>>error-prone pointer manipulation; 
>
>Afraid this one doesn't seem to make sense.  How does being able to
>define a dozen incompatible types of integer "reduce the need for
>error-prone pointer manipulation"?  

While I agree with you that the introduction of multiple scalar types
in Ada programs can be abused, I don't think that is what was being 
referred to.  Two examples that come to my mind are the common practice 
of equating ints with pointers (although thankfully this is becoming
less  common these days) and the practice of passing non-scalar data by 
reference with the concommitant possible type mismatch between 
subprograms.  Thus, there is a point of view that makes sense.

>
>>and its modular facilities improve
>>teams' coordination of effort.
>
>Both languages are modular.  I'm not sure how this is a 'win' unless
>we're talking about totally inexperienced teams.
>
Agreed, both languages are modular.  But I think that the author may
have meant that strong typing is too easily circumvented in C; this
degrades coordination between teams.  This is not to say that
circumventing strong typing is unnecessary; I agree that it is
necessary sometimes.  I just prefer being better able to recognize when
its being done in code that I'm reading.

>>
>>This experience, McCormick notes, "has convinced all my faculty
>>colleagues to support teaching Ada in our beginning courses.  This
>>spring semester, the first studentw with Ada as their mother tongue
>>will enroll in my course.  I can only imagine what these teams will
>>accomplish".
>
>Well, Ada is certainly a better choice than C for a beginning language
>to teach design concepts, etc. However, that isn't necessarily saying a
>whole lot, since that wasn't what C was intended for. I'm also not sure
>why that would be considered a 'plus', unless the idea behind Ada was to
>come up with a good language for beginners; that wasn't the idea behind
>it.

Well, I think it says alot.  There's a belief that the way we think
about problem solving is directly related to the language(s) we know.
This is because language provides structure to the concepts and ideas we
use for thinking.  (This belief did not come out of computer science or
engineering, either.)  It only makes sense that a programming language
that provides good direct support for design issues as well should be of
great benefit.  Projects that I've seen that used Ada & failed did so
for a variety of reasons; but a frequent one was that it was designed with
a (FORTRAN, asembly, whatever) mindset but coded in Ada.  It shouldn't
take a rocket scientist to figure out that the effect is the same if you
do a literal translation from any other natural language into English.

However, for me, what really said a lot is that *none* of the teams that
used C finished the project, whereas one half to three fourths of the
teams that used Ada did.  Undoubtedly, you are a good software developer
and/or maintainer (even designer!); but perhaps there's more to the
assertions about language problems with C than you are willing to
accept.

----------------------------------------------------------------
Kevin J. Weise			weisek@source.asset.com
COLSA Corporation		Voice - (205) 922-1512 ext. 2115
6726 Odyssey Drive		FAX   - (205) 971-0002
Huntsville, AL  35806
{Standard Disclaimers about my opinions & my employer's opinions}
{... which are in conflict often enough}
----------------------------------------------------------------
"Admire those who seek the truth;
  avoid those who find it."		Marcel Proust