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,54889de51045a215 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-19 19:47:11 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: 18k11tm001@sneakemail.com (Russ) Newsgroups: comp.lang.ada Subject: Re: += in ada Date: 19 Oct 2003 19:47:11 -0700 Organization: http://groups.google.com Message-ID: References: <3F7316F7.219F@mail.ru> <17cd177c.0310010606.52da88f3@posting.google.com> <3F8BC74F.2CFBFF37@0.0> <1066312000.671303@master.nyc.kbcfp.com> <1066322883.139702@master.nyc.kbcfp.com> <3F8F372D.9040801@comcast.net> <3F8F4559.50306@noplace.com> <3F929FC8.9070901@noplace.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 1066618031 6998 127.0.0.1 (20 Oct 2003 02:47:11 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 20 Oct 2003 02:47:11 +0000 (UTC) Xref: archiver1.google.com comp.lang.ada:1164 Date: 2003-10-19T19:47:11-07:00 List-Id: Marin David Condic wrote in message news:<3F929FC8.9070901@noplace.com>... > I build realtime systems every day that have to manage jet engines and > do things in a 1.024 milisecond cycle. I think I know a little something > about efficiency. And having worked on the navigational aspects of the > Ballistic Missile Defense, I think I might know a little something about > trajectory computations too. I also know that if I *need* that level of > efficiency, I can get it. Not necessarily in a way you will consider > "pretty" - but in a way that I think looks just fine and works well > without having to modify the Ada compiler to satisfy some C/C++ bigots. Oh, the C/C++ "bigots" again. And what about the Java bigots, and the Perl and Python bigots? And if you're so tuned into efficiency, then why do you refuse to standardize nomenclature for efficient mathematical operations? If I want to add two matrices efficiently in Ada, I can use Add ( From=>A, To=>B ); -- or Addition ( A, Into=>B ); -- or Plus ( To=>B, A ); -- or MatrixAdd ( A, B ); -- or MatrixPlus ( Into=>B, From=>A ); -- or MatPlus ( A, inplace=>B); -- or MatrixAddition ( destination=>A, source=>B); -- and on and on and on And I'll bet every one of those has been used in Ada code somewhere! But if I want efficient matric addition in C++ there is rarely any reason to use anything other than A += B; // lots of room for a comment here, but none needed! Certainly you are not so blind and closed-minded that you cannot see how much simpler and more standardized the C++ method is. And perhaps you will take that into consideration next time you scratch your head and wonder why C++ is so much more popular than Ada. No, it isn't just bigotry. > So not only are you exhibiting profound rudeness, but also poor > engineering judgement. You're supposed to be picking technology for the > future? No, I'm not "picking" technology for the future ATM system. I'm working with the top experts in the world to *develop* it. We're the folks who are figuring out how to make use of the new CNS (Communication, Navigation, and Surveillence) infrastructure that will be available in the next decade or two. We're the guys who will "put it all together". Our goal is to double or triple the capacity of the current system without compromising safety. That will require much more automation than is currently used. That means more safety-critical software. By the way, I didn't get into the position I am in by using bad engineering judgment, and your claim that I am displaying such here is just hot air. > > > > > > Oh, isn't that wonderful. Pascal, Fortran, and Ada. Did you > > contribute your "wisdom" to the demise of Pascal and Fortran too? I > > guess you're going for the trifecta with Ada, eh? Ever heard of > > "three strikes and you're out"? > > > I don't kill computer languages. Also, none of the above are dead. They > all have their markets and satisfy them quite well. Just because some > new language comes along that captures a large part of the market > doesn't mean that older languages don't have a following or a large > installed base of software or valid and useful constructs for developing > software. I'm well aware of all that. What concerns me is what the options will be when the time comes to implement the high-capacity ATM system that I help to develop. Now, if I propose that Fortran or Pascal be used, I will be laughed out of the room. If I push for C, C++, or Java, on the other hand, I will be taken very seriously. Ada is on the edge, but is on the verge of falling off the edge, of the list of serious candidates. Every little thing that can help improve Ada's popularity without damaging its effectiveness is critical now. If the Ada 200x design team gets too conservative, Ada will almost certainly work its way out of the picture. > Nor does it mean that people who have ever used them are some sort of > loosers who should be insulted in public by rude posters. I'm sure they will get over my insults. > It is an interesting thesis that lack of a "+=" opwerator guarantees the > demise of a computer language and presence of one will cause programmers > to flock to its doors in massive numbers. Unfortunately, it is a theory You guys must work overtime to miss the point. Did you read my little analogy about sun visors on cars? You are precisely the salesman who claims that visors aren't necessary because they can be constructed easily with duct tape and cardboard. > that is blissfully unencombered with any facts. At best, you have > "coincidence" - C/C++ are popular. C/C++ have a "+=" opwerator. The "+=" > operator is necessary to be popular. It just doesn't logically follow. Take a look some time at comp.lang.c, comp.lang.c++, comp.lang.java.*, comp.lang.perl, and comp.lang.python. You might just find that each of them gets more posts in a day than comp.lang.ada gets in a month. Is that *because* they each have "+="? I don't know, but you cannot deny the correlation between "+=" and popularity. (Of course, they all use "=" rather than ":=" for assignment, which may also be a huge factor, but that's another story.) > Or you can just abandon any concern about Ada and go tell your boss that > Ada is not worth using on future projects because it doesn't have a "+=" > operator. Or, if you're so convinced of the value of this, go write a > pre-compiler that supports it and translates it into appropriate > procedure calls - that might be a constructive way of demonstrating that > if Ada only had a "+=" operator, it would gain popularity. Either way. I I might just do that. I've already written a pre-processor that converts "=" to ":=" (or "=>", if appropriate) and eliminates the need for semi-colons. I've tested it on about a half-dozen publicly available Ada packages, and it works well. I even have the inverse pre-processor that converts code the other way. When I run code through both pre-processors I get the original code back, which is a good sign. My pre-processors thus implement a new dialect of Ada, which I call "MyAda", that a programmer could conceivably use on an Ada95 team and nobody else on the team would ever know the difference. All I need to make it truly practical is a mechanism to do the conversions automatically. That is, if I wish to use "MyAda", the standard Ada95 code automatically gets converted to MyAda when I check out the file, and it gets converted back to Ada95 when I check it back in. The problem with "+=" is that Ada 95 has no standard. Converting "+=" to "Inc" is easy enough, but how can I be sure that "Inc" is the right procecure name? Ditto for the inverse pre-processor. How can I be sure that "Inc" rather than "Add" gets converted to "+="? Perhaps now you are starting to see why I like standard nomenclature so much. > don't care. I'd just suggest dropping the lobbying for it because it > isn't going to happen. I've already wasted more than enough time on this little endeavor, so I may just take your suggestion.