From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=0.3 required=3.0 tests=BAYES_05,FROM_NO_USER
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: Wed, 28 Oct 92 07:45:41 CST
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Subject: Re: The Obfuscated Ada Contest
Message-ID: <9210281345.AA16636@efftoo.boeing.com>
List-Id: <comp.lang.ada>

!gary@ucbvax.Berkeley.EDU  (Gary Funck) sez:

>dissenting/confirming opinions welcome,

OK, here's a few of the former.

> 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.

I would very much like to know the details of this since it
doesn't match my experience.  Mind you, there are smart ways and dumb
ways to do this (why 20 parameters, for example?) and some early
Ada compilers made you pay a severe penalty on values returned by
functions, but my experience has been that controlling data flow
through subprogram parameters has never had overwhelming effects on
speed.  I've seen (but not really believed) claims that because stack
and heap variables are likelier to be in cache than globals, parameters
might actually make code run faster!  Could it be that the folks you're
talking about also suppressed checks to get their speed improvement?

> 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.

Perhaps I'm unique, but my biggest gotcha with USE clauses is that
they obscure the audit trail.  It seems that the folks who deliver
us package bodies with 97 use clauses are also fond of putting
millions of subprograms and visible variables in all the packages
they USE.  There is, BTW, a very acceptable alternative: the local
USE clause within a DECLARE block created just for the purpose of
permitting the code readability helped by the USE.

And a couple of the latter:

I couldn't agree more about stupid names.  One particularly heinous
program that's going on now requires prefixing package identifiers
to all names.  They probably also recommend the USE clause!  So
instead of saying Package_Name.Thing_Name you have to say
Package_Name_Thing_Name.  Oooooh, good idea!

And I suppose I really ought to sit down and work through all the steps
to justify my ill-considered belief that when Booch components are
non-trivial, they're harmful.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+