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: Distribution: comp Date: Tue, 23 Apr 91 19:08:17 GMT In article 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