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=1.0 required=3.0 tests=BAYES_20,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 28 Aug 92 11:29:00 EST From: "Paul Byrley" Subject: Play 20K expressions again, Sam Message-ID: <9208281536.AA01868@ajpo.sei.cmu.edu> List-Id: I was willing to be prejudiced again against "those academics" when I first read about the supposed bug in a compiler that balked at 20k expressions. After reading Sam Harbaugh's good natured commentary, I rethought my position and decided to just comment. About 1985, I asked the net at SIMTEL20 what to do about contractually limiting the size of Ada packages. We had been using FORTRAN and MIL-STD-1679 or 1644 where the limit was 200 LOC for a sub-program (1679 and 1644 predated Ada by 5 to 10 years). I thought 200 LOC was excessive for good life cycle support (assuming 50% comments and 64 lines per line printer page you got 6 pages of code plus a page or two of declaratives). We had just started talking about the Hrair limit then, thanks to Grady Booch (and, I think, some rabbit in Watership Downs) and six pages of listings was too much for my brain to encompass. I felt sure, however, that the 200 LOC limit we used for FORTRAN subroutines wouldn't translate into a valid Ada limit. Anyhow, when I asked the net, I got back about eight comments, all saying "no LOC limits for Ada packages". I believe that Grady Booch and Ed Berard were among the commenters and that was support enough for me. Since then, our agency has used the no LOC limit approach on probably 50 procurements for real time training systems, ranging in size from 5000 LOC to 800K LOC of Ada. I think only one vendor has violated what, as near as I can tell, is industry agreement on good practice on package size. Most packages seem to be from 100 to 500 LOC, and almost never over 1000 LOC. The one "violator of good practice" insisted on delivering a 10K LOC package. It worked, but is going to be more expensive for all us taxpayers to support for the next 10 to 15 years. My opinion is that if a person is hanging together large amounts of code and will support it himself forever (promises not to quit or die before his employer ceases to need the software), then 20K expressions is ok. (Does one expression = one LOC or are we talking one expression = LOC/4 to LOC/8?) If a taxpayer (even a federal research grant comes from taxpayers) is going to have to pay extra for the indulgence of a 20K expression programmer, then I thank Verdix for their choice. Actually I wish it were lower. I remember, years ago, learning that the reason my latest FORTRAN "gem" was not compiling was that I had overrun the compiler tables- that program was about 1000 LOC and I was briefly indignant also. Yeah Sam, that was half a box of cards, red ones and blue ones and even green ones, with a diagonal magic marker across the top so you could maybe recover when someone dropped them. Regards to all, even the long package advocates. Paul Byrley