Re: Ideas for Ada 200X

[Richard Riehle <richard@adaworks.com>]

Russ wrote:

> Richard Riehle <richard@adaworks.com> 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.

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.

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.

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.

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.

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.

Richard Riehle

>
>
> First, the assignment operators provide a more concise and less
> redundant syntax for common math operations. For example, they allow
> one to write
>
>     extra_looooong_variable_name_for_count += 1
>
> rather than
>
>     extra_looooong_variable_name_for_count :=
>     extra_looooong_variable_name_for_count + 1
>
> I happen to think this is better even for shorter variable names. For
> example, I think
>
>     count += 1
>
> is cleaner and more elegant than
>
>     count := count + 1
>
> Why? Because the latter has redundant information. Why repeat the
> variable name if you don't need to? With +=, if I decide to change the
> name, I only need to change it in one place on that line, for example.
> Perhaps I am obsessive minimalist, but the latter construct bothers
> me.
>
> Second, the asigmnment operators provide a more concise and clearer
> syntax for efficient vector/matrix operations. Why write Add (
> Into=>A, From=>B) when I can just write A += B?
>
> Note also that these operators are not exclusive to C and C++. They
> are also available -- and widely used -- in Java, Python, and Perl.
> Note that C, C++, Java, Python, and Perl are probably the most popular
> general purpose languages around today. And each of these languages
> has +=, -=, *=, and /=. So I think it is quite misleading to say that
> these operators "make one language look like another." What they do is
> make Ada look like *all* of the five most popular languages around
> today.
>
> If Ada insists on bucking the norm just to be different, I won't be
> surprised if it continues to fade away, and that would be a shame.