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,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-15 00:11:51 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: 18k11tm001@sneakemail.com (Russ) Newsgroups: comp.lang.ada Subject: Re: Is the Writing on the Wall for Ada? Date: 15 Sep 2003 00:11:50 -0700 Organization: http://groups.google.com/ Message-ID: References: <3F650BBE.4080107@attbi.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 1063609911 15711 127.0.0.1 (15 Sep 2003 07:11:51 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 15 Sep 2003 07:11:51 GMT Xref: archiver1.google.com comp.lang.ada:42509 Date: 2003-09-15T07:11:51+00:00 List-Id: "Robert I. Eachus" wrote in message news:<3F650BBE.4080107@attbi.com>... > Russ wrote: > > > The fact that you need five lines, a new scope, and a new variable to > > do what most programmers (C, C++, Java, Perl, and Python) can do in > > one simple line should tell you something. If that's what Ada > > programmers call "more readable," then I'll take the "less readable" > > code, thanks. > > You are being silly. Another common approach in Ada is to define a > procedure to do the work. Now I might give an example as: Mr. Eachus, you are probably a top-notch programmer and/or software engineer, but I don't think your example has much bearing on whether Ada should or should not have augmented assignment operators. Rather than getting wrapped around the axle explaining why, let me just point out that, with only slight modification, your example could have equally been used to argue against the standard arithmetic operators (+, -, *, and /). Think about it. Do you think Ada shouldn't have those operators either? I doubt it. Incrementing a variable with a long name or path is hardly the only benefit of augmented assignment. As every competent C++ programmer knows, augmented assignment also allows more efficient vector/matrix operations (for example) by eliminating the need for temporaries. This was discussed in detail on a previous thread. I was surprised at how many comp.lang.ada readers argued with me about that, but they were and still are wrong. They'll probably argue with me here again, and they will still be just as wrong. Alas, ignorance is never in short supply. It seems to me that this entire debate really boils down to a fundamental difference in how a programmers view basic arithmetic operations. If I write a = b + c, I am adding two variables and putting the result in a third. But if I write a = a + b, I am doing something different: I am incrementing the value of a and puting the result right back in the same place. That's why a += b or a :+ b is a more natural way to express the operation. It's as simple as that. And that's why the most popular programming languages have augmented assignment operators. But Ada doesn't want to be popular, I guess. Don't worry, at this rate it won't be. The question is whether it will be alive for long. > procedure Inc(X: in out Integer) is > begin X := X + 1; end Inc; > pragma Inline(Inc); > > And sometimes I have done just that. But in reality, an operation like > that is seldom on Integers, because of the almost ironclad style of for > loops in Ada. And when it does occur, I am going to think about whether > overflow can occur, and if it can what should happen on overflow. > > So in actual practice I have written lots of "little" Inc subroutines > that ended up being a package exporting an encapsulated type. Where the > package itself was several pages long including comments. Does this > mean that Ada is verbose? No. Because I only had to define what should > happen in all the exceptional cases associated with that type in one > place. For an example, if this was part of an inventory control system, > changing the count of items in stock might trigger all sorts of actions. > It might be for example that increasing the number might do a check to > see if some customer had that item on backorder, and if so generate a > shipping order. > > Similarly I have also done exactly what Matt was talking about: > > declare > N : Integer renames Item (Number).Inventory.Count; > begin > ... > N := N + 1; > ... > end; > > But I added the elipses to indicate that ususally when you do that, the > complex name would appear in several other places in that code segment, > and the declare block makes it clear that that code is operating on one > particular record. So the example might really become: > > declare > N : Integer renames Item (Number).Inventory; > begin > -- some operations on N > N.Count := N.Count + 1; > -- more operations on N > end; > > In fact, almost always when you use this idiom it is directly inside a loop: > > for Number in Item'Range loop > declare > N : Integer renames Item (Number).Inventory; > begin > -- some operations on N > N.Count := N.Count + 1; > -- more operations on N > end; > end loop;