Re: += in ada

[18k11tm001@sneakemail.com (Russ)]

Marin David Condic <nobody@noplace.com> 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.