Newsgroups: comp.object
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: Readability of Ada
Message-ID: <1991Apr23.190817.28079@Think.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <jls.671858932@rutabaga> <PREECE.91Apr22173631@etude.urbana.mcd.mot.com>
Distribution: comp
Date: Tue, 23 Apr 91 19:08:17 GMT

In article <PREECE.91Apr22173631@etude.urbana.mcd.mot.com> preece@urbana.mcd.mot.com (Scott E. Preece) writes:
>The statement that verbosity is complimentary is simply broken and
>reflects, I think, a misunderstanding of the way we understand language.
>There is a reason that style manuals preach concision -- our minds have
>limited scope.  Dense language can increase the amount of material that
>we can comprehend before suffering stack overflow (there is, needless to
>say, bad dense language as well as good dense language, and bad dense
>language can be *much* worse than bad loose language, though one could
>argue that its denseness at least makes its badness more obvious).

That is a very good point.  Consider:

1. Ths sttmnt s 2 trse

2. This statement is about as verbose as is necessary.

3. The statement that is currently being read contains excess verbiage that
contributes little to the comprehension level of the reader, and perhaps
reduces the overall readability quotient of the sentence.

I find statement 1 to be analogous to APL, C is somewhere between 1 and 2,
Common Lisp about 2-2.2 (dependeing upon use of some optional features),
and Ada close to 3.  While I don't wish to recommend BASIC for any serious
programming, it probably comes pretty close to 2.

>Frankly, I didn't find the Ada particularly readable -- it was too large
>to fit on one screen and I lost interest in the exercise.

That's exactly what happened to me.  The fact that an exercise in writing a
single function requires implementing an entire package seemed excessive.
Sure, if one were writing an entire date-handling library one would write
that package, and it would probably include a calendar->Julian conversion
function that looks something like the one given.  But taken out of context
it was way too much.

No one has yet mentioned the significant design difference between the Ada
and C versions of that routine, by the way.  The Ada version had two arrays
of month lengths, one for regular years and another for leap years; the C
version simply adds a day if the year is a leap year and the month is >2.
I find the C version's design preferable, but I'm having a hard time coming
up with good reasons.  I think I just find the two almost identical arrays
unnecessary.  If there were some possibility that one would need to change
one of them without changing the other, such a design would be justified,
but this seems unlikely.  Perhaps if it initialized one array by copying
the other and then changing February's entry I would be more comfortable.
One thing, though: the C version would be better if there were a

	#define LEAP_MONTH 2

rather than using the magic number 2 in several places.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
