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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c406e0c4a6eb74ed X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews2.google.com!not-for-mail From: kevin.cline@gmail.com (Kevin Cline) Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request Date: 26 Aug 2004 14:08:51 -0700 Organization: http://groups.google.com Message-ID: References: <49dc98cf.0408110556.18ae7df@posting.google.com> NNTP-Posting-Host: 170.215.188.12 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1093554531 12671 127.0.0.1 (26 Aug 2004 21:08:51 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 26 Aug 2004 21:08:51 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:3050 Date: 2004-08-26T14:08:51-07:00 List-Id: "Richard Riehle" wrote in message news:... > Fabio, > > First, yes, I am the author of Ada Distilled. Thank you > for the acknowledgement. I am working on a updated > version, but I am being delayed in its release by the press > of other concerns. Perhaps I should not spend as much > time engaged in dialogue of this sort on comp.lang.ada. :-) > > Second. People do look at issues in programming languages > differently, given the same information. While I don't agree > with their conclusions, I appreciate that they will apply > different criteria to their evaluation than I would. > > For example, when Kevin states that limited types are a > flaw in the language, I choose to accept that he is correct, > only because I realize that some people find this to be a > difficult concept. I do disagree with Kevin on this, and many > other points since limited is a powerful and effective feature > when used by a designer who understands it. Somehow I've never understood the point of making limited types a special case. Why not consider assignment as just another operation a type can support, or not, just like addition or ordered comparison? I think this is one of the fundamental errors in the Ada design -- certain operations are somehow "more equal" than others, and redefining them requires special syntax. > Syntax, in programming languages, seems to be a personal > thing. I know people who dislike the syntax of the C family > of languages as well as the Pascal family. Some of these > people are attracted to Lisp, Haskell, or Ruby, or even Smalltalk > or Eiffel. I once sat in on a meeting where, after the presentation > by a prominent speaker, the room erupted in a spirited argument > about the virtue of := versus = for assignment. Sometimes I > have seen people get so upset about the placement of the type > identifier in relationship to the variable/object that I half expect > to seem white foam drooling from the corners of their mouths. That kind of syntax I don't much care about. I care about whether I have to write 500 lines of code or 1500. As a general rule, 500 lines is better. > As to learning Ada being difficult. My own experience is quite > different, and I have taught Ada to a lot of people during the > last eighteen years. But how much of the language have your students really learned? To most programmers, all languages are essentially just FORTRAN. They store all their data in arrays and write loop upon loop ad nauseum. For such programmers, Ada is undoubtedly better than C or C++, because it has extensive facilities to support static array-based programming. However, defining or using more complex and dynamic data structures in Ada is a chore. Dynamic structures requires use of unchecked allocation and deallocation, leaving one exposed to the same sort of heap corruption errors that plagued naive C and C++ programmers. However, with the introduction of the C++ standard library, programming in C++ with advanced data structures is simple and fast, and it's easy to avoid memory leaks, null dereferences, and heap corruption. > Finally, Kevin makes his case from his own viewpoint, using > his own criteria. Oddly enough, the issues he raises are not > those that represent weaknesses vis a vis Ada. If he had > examined both languages more carefully he would have found > some really good points that show some advantages of C++ > over Ada. I wrote an Ada-83 specification parser in Ada using AYACC. That required a rather thorough examination of the language. > Most important, I continue to look for improvements in language > design, And this is what we should all do. Assuming that differing opinions have no value will not lead to progress.