The Obfuscated Ada Contest (was Re: An admittedly biased ...)

The Obfuscated Ada Contest (was Re: An admittedly biased ...)

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!scott.skidmore.edu!psinn]

In article <1992Oct19.165603.16988@nntpd2.cxo.dec.com> wallace@bonmot (Richard 
Wallace) writes:
>
>Gregory Aharonian (srctran@world.std.com) has put his finger on the real
>issue behind the C++/Ada religious wars -- economics.
>
>I can not agree with the slams that are put forward by Gregory.  The issue
>behind the economic arguement is one that can be brought down to
>implementation and education issues.  I list them here:
>
... interesting info. on the economics of PC and GNU software left out ...
... info. on lint as an unacceptable tool left out ...

>This is the issue that the U.S. Government wants.
>Not to grow the individual (who is around for 20 years on a single program?)
>but to grow the technology so that second-sourcing -- not a well understood
>concept in the software industry -- can be done on the software of the
>Government computer software.
>

To change this thread a little: Let's talk about the Ada programs
that I've seen in the "real world" of Ada programming on large
projects.  First my disclaimer: I haven't worked on a defense
contract, so am not aware of all the constraints that defense
contracts impose on programming practice.  However, I'd like to
learn more, because I have had the oppurtunity to observe the output
of several large Ada (commercial and defense) projects.  Most, if
not all of the code I've read has been almost completely opaque,
reaching standards of opaqueness seldom achieved in the C source
code (and even assembly language) source that I've read.

Here are some of the practices that I've seen, which just leave
me wondering:

1. Naming conventions that only computers can understand.  Something like
   SCU_1_1_2_FCU_VAR (the 2167 disease), or ACU_CONTROLLER_X_AXIS
   (the subsystem disease).  It seems that the readability of the
   program has been sacrificed to the god of traceability.  Tell me
   that you get used to reading 50 character variable names where the
   last 5 characters are significant.  Tell me that it's not a monumemtal
   effort to change program structure.  Tell me it wouldn't be better
   to implement a traceability/CASE tool that keeps the unit hierachy
   and dependency numbering scheme in parallel with the program components.

2. The fully qualified never-use-the-use-statement syndrome, which
   is a close cousin to the "local renames are clearer ... really"
   syndrome.  First, I'm aware of some/most of the gotchas related
   to the rampant use of the "use clause".  But hey, I give the
   programmer the benefit of the doubt, and also believe in code
   review.  If a "use" makes things clearer, then so be it.  If
   adding a new item to another package causes a clash in one of
   its "users", then fix the clash and get on with it.  I've never
   seen these clashes come up often (though my experience working
   on large Ada projects is limited). It seems to me that the
   maintenance cost of understanding and reworking a set of packages
   which never use "USE" is much higher than the cost of fixing an
   occasional name clash.  Isn't this a tools issue? Couldn't a
   pretty printer, cross-ref. program or browser be able to provide the
   necessary package resolution information on an as-needed basis?

3. The never-use-a-package-variable syndrome, whose close cousin
   is the pass-the-world-via-procedure parameters syndrome.  On this
   one, I have only second-hand experience.  I've heard of a project
   which mandated that global (library level package) variables 
   could *not* be referenced by packages other than the packages
   that declared them.  This mandate apparently led to the development
   of procedures with up to 20 parameters, whose values were passed
   up and down the call hierarchy.  When the delivered system couldn't
   meet its time constraints, the code was reworked so that it
   judiciously used global variables. Voila!  it was twice as fast
   and half the size.

4. The Booch component syndrome.  I like Booch's books and OOP, don't
   get me wrong. But when you run into a program that's running at
   PC/AT speed on an R4000 box, give me a call :-). When you find
   out that the program is beating its brains out because it creates
   1000 iterators, each implemented as a task, we definitely have
   something to talk about.  My point here is: if some degree of
   abstraction is good, a very high degree of abstraction is not
   always better.

I'll close with a couple of questions:

  - Are some/all of the above practices common to the Ada projects
    you've worked on? If, yes, what's your take?  Did such coding practices
    really improve understanding and maintaining the program?

  - Are the programming practices described above unique to Ada? 
    I ask because I've seen a pattern in the "production" Ada code that
    I've read; each program runs along the lines outlined above.
    The C code that I've worked on had other problems, but long names,
    rigid structure, and unnecessary levels of abstraction
    weren't among them :-).

and a concern:

  - If the only Ada programs that a new graduate/new hire/new Ada programmer
    saw were by obscured "encrypted" naming conventions, rigid structure,
    and poor performance, I'd be seriously concerned that Ada would
    take the rap, when it is only the messenger.

dissenting/confirming opinions welcome,

- Gary

-- 
| Gary Funck  		    gary@intrepid.com  [uunet!uupsi!intrepid!gary]
| Intrepid Technology Inc., Mountain View CA (415) 964-8135
--

Re: The Obfuscated Ada Contest (was Re: An admittedly biased ...)

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!news2]

In article <1992Oct22.080735.19815@intrepid.com> gary@intrepid.com (Gary Funck)
 writes:
>   something to talk about.  My point here is: if some degree of
>   abstraction is good, a very high degree of abstraction is not
>   always better.

Yes, and also there is a quote from Butler Lampson "Abstraction is no excuse
for not getting it right".

Re: The Obfuscated Ada Contest (was Re: An admittedly biased ...)

[Alex Blakemore]

In article <1992Oct22.080735.19815@intrepid.com> gary@intrepid.com (Gary Funck)
 writes:
>   My point here is: if some degree of abstraction is good,
>   a very high degree of abstraction is not always better.

same could be send for medicine, desserts, and Keynesian economics

I always loved the term that Doug Bryan introduced in his Dear Ada column:

  abstraction inversion

to describe the phenomenah of layering inappropriate amounts of 
complex interface to obscure a simple system.
such as a generic object oriented task-safe cached priority heap to represent
a constant size string.  its poor design, and unfortunately people often
hide poor design behind elaborate interfaces and buzzwords.

As a gross generalization: I'ld say C programmers too often ignore interface
issues and dont worry enough about abstraction and information hiding,
while being overly obsessed with implementation detail and efficiency.
And Ada programmers too often do the opposite - become obsessed with elaborate
interfaces and overly complex structures while ignoring implementation and
efficiency issues.  C programmers too often think the best names have less than
4 characters, while Ada programmers too often think the best names have more th
an 40.

The best programmers in either language, try to balance both concerns.


-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

Re: The Obfuscated Ada Contest (was Re: An admittedly biased ...)

[Daniel Wengelin]

In article <1992Oct22.080735.19815@intrepid.com> gary@intrepid.com (Gary Funck)
 writes:

>1. Naming conventions that only computers can understand.  Something like
>   SCU_1_1_2_FCU_VAR (the 2167 disease), or ACU_CONTROLLER_X_AXIS
>   (the subsystem disease).  It seems that the readability of the
>   program has been sacrificed to the god of traceability.  .......
>
>2. The fully qualified never-use-the-use-statement syndrome, which
>   is a close cousin to the "local renames are clearer ... really".....
>
>3. The never-use-a-package-variable syndrome, whose close cousin
>   is the pass-the-world-via-procedure parameters syndrome.  On this....
>
>4. The Booch component syndrome.  I like Booch's books and OOP, don't ....
>
>I'll close with a couple of questions:
>
>  - Are some/all of the above practices common to the Ada projects
>    you've worked on? If, yes, what's your take?  Did such coding practices
>    really improve understanding and maintaining the program?
>

I would like to comment briefly on the issues raised by Gary. 

1. We have found no contradiction between readability and traceability.
   Maybe DoD2167-A  could impose problems, but the "subsystems disease"
   has not.

2. The "don't use use"-rule is applied in our company Ada Coding Standard
   (ACS). However, "localized use of use clauses can improve readability"
   and "Use your common sense and make sure that dependencies are easy
   to grasp for the reader".

3. Our ACS promotes information hiding and parameter passing.

4. I agree on the problem. The use of C.O.T.S. software is a very tricky
   area, especially in "live" real-time systems (as opposed to prototypes).


The bottom line is as usual _education and skill_, no matter the language
used or methods applied. However, concerning 2.-3. our experience is that
it is cheaper to maintain software that's on the abstraction side of
the "abstraction-performance tradeoff". It is true that parameter passing
is costly, but it is easier to flatten a structure to gain performance
than to create a structure to gain abstraction (understandability). This
could indicate that a language that promotes structure and allows
performance is preferred, rather than a language that allows structure
and promotes performance.

Concerning COTS sw, we have evaluated some with "less than perfect"
results. Correctness, performance, error handling, etc has to be 
ensured before the product is taken to use. Hence, I propose that
formal code inspections (conf. Fagan) are arranged for all COTS sw.


               Daniel W.


----------------------------------------------------------------
!    with Standard_Disclaimer;                                 !
----------------------------------------------------------------
!    Daniel Wengelin               ! E-mail: dawe@nobeltech.se !
!    Systems analysis and design   ! Phone : +46 8 58084000    !
!    NobelTech Systems             ! Fax   : +46 8 58081542    !
!    Naval Systems Division        ! Mail  : S-17588 Jarfalla  !
!                                  !         SWEDEN            !
----------------------------------------------------------------
! NobelTech: Winner of the -92 Ada Industry Leadership Award   !
----------------------------------------------------------------

Re: The Obfuscated Ada Contest (was Re: An admittedly biased ...)

[cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!wupost!crcnis]

gary@intrepid.com (Gary Funck) writes:

>I'll close with a couple of questions:

>  - Are some/all of the above practices common to the Ada projects
>    you've worked on? If, yes, what's your take?  Did such coding practices
>    really improve understanding and maintaining the program?

In the group of people I work with, we have a myriad variety of styles, even
though we have a published "Ada standard" we're supposed to follow.  One of the
worst, in my mind, things people are doing in their code is preceding every
variable name with "The_".  Thus, you have statements assigning to record
componenets like this:  The_Box.The_Left_Side.The_Color

To me, that's NOT readable.  In addition, it's very annoying to have to type
when working on the code.  What's wrong with:  Box.Left_Side.Color or something
similar?

We also run into the case of variable names which are 30+ characters long,
or so it seems.  I agree that using variables such as X, Y, K, I, J, etc
can be hard to maintain, but so can code where the average identifier is
15+ characters long!

There are also compromises made in the "pass the world" notion.  Some 
packages do this, some do not -- we had to allow global variables in some
code, as we're dealing with X-Windows, and thus the Ada code isn't always
in "control".  X-Callbacks basically force you to use global variables.
There's a time and a place for everything.  Sometimes, globals are best,
sometimes passing as parameters is best -- to me, to try to force it into
rigid rules is a mistake, and produces hard to follow, and hard to maintain
code.

>  - Are the programming practices described above unique to Ada? 
>    I ask because I've seen a pattern in the "production" Ada code that
>    I've read; each program runs along the lines outlined above.
>    The C code that I've worked on had other problems, but long names,
>    rigid structure, and unnecessary levels of abstraction
>    weren't among them :-).

I've not seen them anywhere else...  In addition, we have a myriad collection
of one-line procedures; the tendency to produce them seems to come from the
programming ideas people are perceiving to go along with Ada.  While yes,
the compiler SHOULD optimize the calls into inline code, there's no
guarantee that it will.  In addition, one-line procedures are harder to follow
when tracing through the code to try to track down a problem.

>and a concern:

>  - If the only Ada programs that a new graduate/new hire/new Ada programmer
>    saw were by obscured "encrypted" naming conventions, rigid structure,
>    and poor performance, I'd be seriously concerned that Ada would
>    take the rap, when it is only the messenger.

>dissenting/confirming opinions welcome,

>- Gary

>-- 
>| Gary Funck  		    gary@intrepid.com  [uunet!uupsi!intrepid!gary]
>| Intrepid Technology Inc., Mountain View CA (415) 964-8135
>--


-------------------------------------------------------------------------------
-                                   "She had what it took: great hair, a      -
- Kevin Trojanowski                  profound understanding of strategic lip  -
- Internet: troj@cwis.unomaha.edu    gloss, the intelligence to understand    -
-      CI$: 70521,312                the world and a tiny secret interior     -
- US Snail: 1905 Thurston Ave, #8    deadness which meant she didn't care."   -
-           Bellevue, NE 68005                            -Douglas Adams      -
-                                                          _Mostly Harmless_  -
-------------------------------------------------------------------------------
 

Re: The Obfuscated Ada Contest (was Re: An admittedly biased ...)

[John Goodsen]

troj@cwis.unomaha.edu (Kevin Trojanowski) writes:

>
>In the group of people I work with, we have a myriad variety of styles, even
>though we have a published "Ada standard" we're supposed to follow.  One of th
e
>worst, in my mind, things people are doing in their code is preceding every
>variable name with "The_".  Thus, you have statements assigning to record
>componenets like this:  The_Box.The_Left_Side.The_Color
>
>To me, that's NOT readable.  In addition, it's very annoying to have to type
>when working on the code.  What's wrong with:  Box.Left_Side.Color or somethin
g
>similar?
>

Try using "The_" as a prefix ONLY in cases such as parameter names.
It makes the code readable on the procedure call:

       Set_Color ( The_Window => Root_Window,
                   The_Color  => BLUE       );

Using "the_" as a prefix for record field names, local
variables, etc. does nothing for readability, and in fact
confuses the issue as shown above...


>There are also compromises made in the "pass the world" notion.  Some 
>packages do this, some do not -- we had to allow global variables in some
>code, as we're dealing with X-Windows, and thus the Ada code isn't always
>in "control".  X-Callbacks basically force you to use global variables.
>There's a time and a place for everything.  Sometimes, globals are best,
>sometimes passing as parameters is best -- to me, to try to force it into
>rigid rules is a mistake, and produces hard to follow, and hard to maintain
>code.
>
> X-Callbacks basically force you to use global variables.
  ???????????????????????????????????????????????????????

X callbacks ? Xt callbacks ?  Motif Callbacks ?

All three provide mechanisms to pass client data.  Using global data
in X windows will only further complicate matters if you ever want 
your software to be Multi-Thread (Ada task) safe...  Possibly you've
just skimmed over the ability to pass client data with callbacks ???


$.02 + impending 50% taxation of the liberal 90's == my $.03 worth :-)

--
John Goodsen                           PCIS Programme
Software Process & Environments        Ada Joint Program Office       
EVB Software Engineering               goodsenj@ajpo.sei.cmu.edu
jgg@evb.com