Re: Programming language vote - results

[Don Guinn <donguinn@hal-pc.org>]

D.H. Kelly wrote:
> 
> Don Guinn wrote:
> Why is it OK to spend a whole morning understanding a couple pages of
> FORTRAN code, yet it is unreasonable to spend the same amount of time
> with a 2-liner in APL or J which does the same thing?
> _______________________________
> I prefer to use APL but I have long ago realized that it is beneficial to
> spread it out a bit rather than use very complex 1 or 2 liners. It might
> make it possible to figure the program out in a couple of minutes rather
> than hours - especially if properly commented. APL is great for getting
> things done concisely and effectively but that is no excuse for obscurity.
> The delight many take in writing one line recursive programs, etc, actually
> turns others off so that they miss the real usefullness of the language.
> --
> Don Kelly
> dkelly@nanaimo.ark.combull
> remove the "bull " to reply
_________________________________

You are right.  It does make it easier to read if things are spread out.

Lately I have had to spend a fair amount of time studying Visual Basic
and was impressed on how Microsoft and other writers could fill a thick
book with so little information.  I was able to read the books faster
than I read paperbacks because after I saw the same information the
third time I could simply scan it looking for possible differences.

Not so with APL and J.  Redundancy is minimal and it takes a long time
to read the manuals.

The same thing happens in code.  Visual Basic, C etc. are voluminous in
the size of the source.  The source for a small application go on and on
and can be read rapidly because the information content is so low.  A
manager looks at the size of the source and is impressed!  Don't tell
him that most of it is boilerplate built by a wizard.  That out of the
20 to 100 pages of source there resides two or three pages of original
code.

Now that same manager comes in and sees that you're spending days
working on a program in APL which, if printed, would fill only a few
pages.  He is not impressed!  You are obviously not producing. 
Nevermind that both produce the same result.

As far as documenting code.  Documentation is wonderful when it adds
information and insight on what the program does.  I have seen too many
programs full of documentation which does nothing but repeat what is
already stated in the code itself.  It's as if the person who wrote it
can't read his own code.

Which brings up how programming is being taught.  We go to classes to
learn how to write computer programs.  Where does one go to learn how to
read programs?  Ever see a course in reading computer programs. 
Actually there are, but they're never called that.  They are called
analysis and debugging courses and no applications programmer would ever
want to go to.

I'll never forget the little red book for a linear algebra course I
took.  It was no bigger than the J dictionary.  We would spend an entire
evening on one page.  Does that mean that it was not well written?

Documentation needs to explain the concepts used in an application.  It
should provide definitions of terms (variables) and possible things to
watch out for.  But it should not have to translate the source code into
English.  It should not be measured by the pound.


Don Guinn
donguinn@hal-pc.org