Keith said:
I used APL extensively in the 70s and very early 80s. I thought it was
WO then, and I still think so. I've seen process tracking tools
written in APL that weren't supportable and were left in place because
no one had a clue how they worked. No documentation (and please don't
tell me APL is self-documenting) and no comments (not easy in APL).
No language, and I have used quite a few over the last 50 years, is self
documenting except in certain very rare circumstances. Your statement
re commenting is wrong. For many years APLs have allowed comments on
the same line as code. Only the very early ones required comments to be
alone on a line. Also, documentation and comments took up space and in
the early days with 32KB workspaces that could present a problem.
Sometimes those separate workspaces got lost. On the other hand ANY
language can be missused to produce undocumented, uncommented and
unreadable code.
My practice, these days, is to produce one or more (usually more) lines
of comments at the beginning of a function briefly explaining its
purpose, what is expect as argument(s) and what is the nature of the
result. In the body of the function, I add a comment to the line
stating _what_ I'm doing, not _how_ I'm doing it. Read the code for that.
A very simple example avoiding the character set problem:
{del} z{is}D_S_T yr;M;DTS;D;dt;{quad}IO
[1] {rem} E*2 941213 Start and end of Daylight saving time in year, yr
[2] {quad}IO{is}1 {diamond} 'Daysof Day' need 'date'
[3] dt{is}400 1000+10000{times}yr {rem} Apr and Oct as yymm00
[4] D{is}0=0 Day{each}{each}DTS{is}Daysof{each}dt {rem} Dates and
which are Sundays
[5] z{is}(<\{take}D)/{take}DTS {rem} DST start date
[6] z{is}0.02+z,({rot}<\{rot}2{disclose}D)/2{disclose}DTS {rem} DST
starts/ends
{del}
However, If I had to fix some problem in poorly documented code, I'd
rather it was APL than C or FORTRAN or PL-I, ...
They were finally replaced wholesale, though I don't remember by what.
Obviously they didn't have anyone competent in APL on staff. I've been
there and done that. If the code was badly written, I'd figure out
enough to know what was to be done and rewrite it.
Regarding the readability of APL, in the early '70s, I was invited by
Garth Foster to give a talk at Syracuse University on what I was then
working on. On the way to the lecture hall, Garth told me that he
wanted to do an experiment with regard to the readability of APL. He
said that he had put a rather complex single line on the blackboard and
wanted to see how long it would take me to figure out what it does and
how. Although I had never seen this code or the methodology it used, by
the time Garth finished an introduction (a couple of minutes), I was
able to state that it right justified a line of text making a rather
tricky use of {grade-up}. "If you can say the word for a knot, you will
know how to untie it." Samuel R. Delany in "Babel 17".
No more so that C or several others.
Ted