From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1ba8c21ddfbe0b1e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-01-05 08:07:22 PST Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!swrinde!gatech!udel!darwin.sura.net!source.asset.com!source.asset.com!not-for-mail From: weisek@source.asset.com (Kevin Weise) Newsgroups: comp.lang.ada Subject: Re: "Subtract C, add Ada" Date: 5 Jan 1995 11:07:22 -0500 Organization: Asset Source for Software Engineering Technology Message-ID: <3eh5fq$ppv@source.asset.com> References: <862035D1F1C@annwfn.com> NNTP-Posting-Host: 530tr0 Date: 1995-01-05T11:07:22-05:00 List-Id: In article <862035D1F1C@annwfn.com>, Fred McCall wrote: >In 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