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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38fc011071df5a27 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-12 22:41:21 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: 18k11tm001@sneakemail.com (Russ) Newsgroups: comp.lang.ada Subject: Re: Ideas for Ada 200X Date: 12 Jun 2003 22:41:20 -0700 Organization: http://groups.google.com/ Message-ID: References: <6a90b886.0305262344.1d558079@posting.google.com> <3EE7CC70.E1FD3A67@adaworks.com> <3EE90854.6456A81E@adaworks.com> NNTP-Posting-Host: 63.194.87.148 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1055482881 30748 127.0.0.1 (13 Jun 2003 05:41:21 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 13 Jun 2003 05:41:21 GMT Xref: archiver1.google.com comp.lang.ada:39080 Date: 2003-06-13T05:41:21+00:00 List-Id: Richard Riehle wrote in message news:<3EE90854.6456A81E@adaworks.com>... > Russ wrote: > > > Richard Riehle wrote in message > > > In the end, the argument boils down to the issue of making one language look > > > like another, and benefits seem marginal, at best. I have yet to see anyone > > > cite the benefits for this addition to the language. > > > > Then apparently you did not read this entire thread, so let me briefly > > restate the benefits as I see them. > > I have read your explanation (below) and I am not fully persuaded > of the virtues of this. You are suggesting that the += syntax would > make Ada more writeable, and that has never been a goal of Ada. > Rather, Ada's goal has been to more readable, as well as more reliable. I appreciate your position, but I respectfully disagree. > Therefore, we must ask the question, "Does this syntax, however widespead > it may be, achieve anything beyond making the code more writeable?" We > must examine this question in two parts. > > First, "Does the code become more readable?" For those familiar with > the C family of languages and its derivatives, there is temptation to answer, > "Yes." Upon deeper reflection, one finds that these constructs in the > language of origin do not make the code more readable. I have experienced > many programmers, fluent in C, who find themselves mentally re-phrasing > something such as "a += 5" as "a = a + 5." This is even more frequent, > I suspect, with "a *= 5". So, even though the shortcut is more writeable, it > adds nothing to readability. The assignment operators do make a language more easily "writable," but I fail to see how they detract from readability. Yes, I understand that people might find them slightly counterintuitive at first, but certainly no good programmer will have trouble with them for long. I don't recall ever having trouble with += myself (but then perhaps I just forgot). My six-year-old boy still adds with his fingers, but I certainly hope he is not constrained by that way of thinking for long. > Second, "Is the code more reliable?" This question requires that we revisit > the goals I stated in my earlier post. > > A language design that enables a compiler to detect and report > on the maximum number of errors as early in the development > process as possible. > > Is there some way this syntax improves the compiler's ability to catch > errors early? Or, does this syntax make it more difficult for the compiler > to catch errors early? Another way of asking this is, "Does this syntax > contribute to more errors or less?" > > I am not sure of the answer to that question. Perhaps others with more > experience using the syntax might be able to say something about it. I > do wonder whether there are situations where an accidental misuse > could cause an undetectable error. Suppose I wrote, "a += 5" when > I intended, "a := 5". This is quite easy to do because the + and the = > are both on the same key on my keyboard. It would be a serious error, > and the compiler would not be able to detect it. Such errors are one > reason why people writing code in the C family of languages find > themselves so dependent on debuggers. Well, ... I think you're reaching a bit on that one. Anyone who can't readily tell += from := needs a stronger pair of reading glasses. And it seems to me they could just as easily confuse + with *, l with 1, or 0 with O. > Ada is designed to limit opportunities for syntactic mistyping, not > to increase those opportunities. Unless there is some way for the > compiler to unfailingly distinguish between := and +=, I would be > opposed to introducing a potentially ambiguous feature into the > language. > > Ada is not intended to be like other languages. Its syntax, structure, > and semantics are carefully reasoned to support the above stated > goals. This is not the case with more popular languages. I think > that adopting a syntax from those other languages to make Ada > more popular at the expense of the underlying goals of the language > would be a step backward, not forward. But I think it would help the popularity of Ada without any significant deleterous effect on the underlying goals. And I remind you that Ada is completely useless when it is not used. > Any new feature in the language must conform to the fundamental > goals of the language. This language is intended to be used for > software that involves a high degree of safety. From time to > time I have come up with ideas I thought were brilliant and should > be added to the language only to discover, after dialogue with > my colleagues, that this little flash of brilliance was incompatible > with the underlying goals of the language. On such occasions, I > simply admit that I was wrong. Admit I'm wrong? That'll be the day. Just ask my wife how often I do that! > A final point with regard to this syntax. How often do we use this > in an actual program? Is the increased danger worth the frequency > of its usage? I would offer that it is not. You didn't even address the issue of overloaded vector/matrix operations. I'm sure you're an expert programmer, software engineer, and more, but I think your intense focus on safety has made you just a bit too conservative and risk averse. That's just my impression. Then again, I could be wrong. (How much do you want to bet some smart-ass posts a reply agreeing with that?)