Re: good software engineering (was: mixing integer and logical ops)

Re: good software engineering (was: mixing integer and logical ops)

[David Emery]

More important, is that it makes it much easier to spot "bad" code!
				dave

Re: good software engineering (was: mixing integer and logical ops)

[Robert I. Eachus]

In article <EMERY.93May25151706@goldfinger.mitre.org> emery@goldfinger.mitre.or
g (David Emery) writes:

  > More important, is that it makes it much easier to spot "bad" code!

     I've always thought that one of the major advantages of Ada was
that it makes bad code look so bad that the author fixes it, often
before anyone else sees it.  To really appreciate this, notice how
many of the Ada 9X revision requests reduce to "I know that it is
possible to do what I want like this:...  but that is too ugly to
use."

     This is not a criticism of many of those RR's.  There are several
cases where a necessary Ada 83 feature gets tarred with the wrong
brush.  Ada 9X does fix many of them, such as operator visibility
rules, and redefined equality operators.  But the point is that I
cannot imagine someone writing a similar revision request about C.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: good software engineering (was: mixing integer and logical ops)

[Wes Groleau X7574]

In article <EACHUS.93May26115049@spectre.mitre.org> eachus@spectre.mitre.org (R
obert I. Eachus) writes:
>     I've always thought that one of the major advantages of Ada was
>that it makes bad code look so bad that the author fixes it, often
>before anyone else sees it.  To really appreciate this, notice how
>many of the Ada 9X revision requests reduce to "I know that it is
>possible to do what I want like this:...  but that is too ugly to
>use."
>...... and redefined equality operators.  But the point is that I
>cannot imagine someone writing a similar revision request about C.

I think the reason is not that Ada makes it easier to spot "bad code"
Rather, IMHO, it's that the "Ada community" has from the beginning
had an attitude in favor of "pretty" and readable source code.  The
C community on the other hand is unsuccessfully trying to change a
culture that EXPECTS code to be unreadable.

Re: good software engineering (was: mixing integer and logical ops)

[Step he Leake]

Wes Groleau writes...
>>     I've always thought that one of the major advantages of Ada was
>>that it makes bad code look so bad that the author fixes it, often
>>before anyone else sees it.
> 

Robert I. Eachus writes:
>I think the reason is not that Ada makes it easier to spot "bad code"
>Rather, IMHO, it's that the "Ada community" has from the beginning
>had an attitude in favor of "pretty" and readable source code.  The
>C community on the other hand is unsuccessfully trying to change a
>culture that EXPECTS code to be unreadable.

I'll go with Wes; I've always found that if Ada makes me work to hard to do
what I think I want to do, there is usually a better way, or I don't really
want to do it. Put another way, if you find yourself writing inelegant Ada
code, take a step back and think the problem thru again. Maybe peruse the LRM;
some feature of Ada that you had temporarily forgotten about might jump and
suggest a better approach.

Stephen Leake	NASA Goddard Robotics Lab
internet : nbssal@robots.gsfc.nasa.gov

Re: good software engineering (was: mixing integer and logical ops)

[Robert I. Eachus]

In article <C7nJIx.3n7@crdnns.crd.ge.com> groleau@e7sa.crd.ge.com (Wes Groleau 
X7574) writes:

  > I think the reason is not that Ada makes it easier to spot "bad code"
  > Rather, IMHO, it's that the "Ada community" has from the beginning
  > had an attitude in favor of "pretty" and readable source code.  The
  > C community on the other hand is unsuccessfully trying to change a
  > culture that EXPECTS code to be unreadable.

    I think it is a little more complex than that.  Why did the
culture evolve that way, and why does it evolve similarly when new
communities adopt Ada?

    First of all, declarations in Ada come first, and it is hard to
write unreadable declarations.  So if the private part or the sequence
of statements is obtuse, the reader--even if he or she is also the
author--notices the increase in the fog level.  (Yes, an expert can
write a declarative part with a high fog index.  But by the time he
has that capability, he has also been conditioned not to.)

     Second, Ada tends to magnify little flaws out of proportion.
When you write Int(Integer(Int'First) + N - 1) the need to rethink the
type of N is immediately apparent.  In this case, which happened to me
earlier this week, the reason for the expression was that N could be
out of range of the generic formal type Int.  Replacing the variable N
by a new variable, linearly related to N, but always in range, got rid
of the need to use Integer for anything.

     So Ada code is held to a high standard of beauty not only because
elegence in Ada is usually easy, but also because the occaisional wart
is so ugly that anyone with the least bit of pride will try to clean
it up.

     Yes the culture is important, but the language keeps the culture
the way it is.  A similar case is short variable names in C or APL.
This not "just" a cultural thing, those languages tend to make long
names look silly.  (C also had an early restriction on the number of
significant characters (8) and on external names--but that was an
implementation restriction.  C has always allowed arbitrarily long
identifiers.)


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: good software engineering (was: mixing integer and logical ops)

[Robert I. Eachus]

In article <27MAY199312323696@bambam.gsfc.nasa.gov> nbssal@bambam.gsfc.nasa.gov
 (Stephe Leake) writes:

   Wes Groleau writes...
   >>     I've always thought that one of the major advantages of Ada was
   >>that it makes bad code look so bad that the author fixes it, often
   >>before anyone else sees it.
   > 

   Robert I. Eachus writes:
   >I think the reason is not that Ada makes it easier to spot "bad code"
   >Rather, IMHO, it's that the "Ada community" has from the beginning
   >had an attitude in favor of "pretty" and readable source code...  The
   >C community on the other hand is unsuccessfully trying to change a
   >culture that EXPECTS code to be unreadable.

   Whoops!  The attributions are backwards!

   Stephen Leake said:

  > I'll go with Wes; I've always found that if Ada makes me work to
  > hard to do what I think I want to do, there is usually a better
  > way, or I don't really want to do it. Put another way, if you find
  > yourself writing inelegant Ada code, take a step back and think the
  > problem thru again. Maybe peruse the LRM; some feature of Ada that
  > you had temporarily forgotten about might jump and suggest a better
  > approach.

  So I think Stephen is trying to agree with me here.  However, Wes's
position is fairly close to mine, so I'm not 100% sure.  This is
starting to remind me of the nature vs. nurture argument, or maybe the
chicken and the egg...

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...