Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!fortune!phipps
From: phipps@fortune.UUCP (Clay Phipps)
Newsgroups: net.lang
Subject: Re: APL Myths
Message-ID: <3711@fortune.UUCP>
Date: Tue, 26-Jun-84 20:00:23 EDT
Article-I.D.: fortune.3711
Posted: Tue Jun 26 20:00:23 1984
Date-Received: Thu, 28-Jun-84 03:36:54 EDT
References: <1982@decwrl.UUCP>
Organization: Fortune Systems, Redwood City, CA
Lines: 140

[beware the jabberwock]

    >I have used both FORTRAN and APL (among many other languages) and 
    >I came to the conclusion that APL is the world's only write-only
    >language!  

Then you have not yet seen some really convoluted C code.
C can be write-only if the programmer exercises sufficient cleverness.

    >The standard technique for fixing a bug in an APL program is
    >to rewrite the whole program ... FINDING the bug in an APL program is
    >much more difficult than in any other language I have used.  

In the early days, it wasn't the notation, it was the diagnostic messages
(if you couldn't buy, beg, or borrow an APL type ball, you didn't use APL).
As someone once said, "APL's error messages consist of only two words,
and one of them is 'error' !"; the other words were "domain", "range", "rank",
"index", "value", &c.  With zillions of functions, even knowing the precise
distinction between, for example, domain and range was often little help.
The definition of the functions was not rigorous, at least in print
(especially for multidimensional arrays where some dimensions were 1)
so you wrote and debugged by trying little pieces of code at a time.
This is the moral equivalent of looking at C compiler source code
to figure out how to write a declaration for an "array of functions 
returning pointers to ...".  But at least APL indicated the precise token
at which the error was detected (as might be obvious, I have not used APL
in a long while; I hope that the diagnostics have improved);
most FORTRAN systems give the poor user a hexadecimal or octal address
for an instruction, and leave the translation of that to a FORTRAN 
statement number as an exercise for the user.
    
    First of all, your opinion of APL is probably derived from the basic fact
    that APL is different from procedural languages (FORGOL).   

APL is different from conventional procedural languages;
however, APL is itself a procedural language:
the programmer must specify everything to be done,
in the order that it is to be done.
The programmer does not need to concern herself with details
that may be irrelevant to a particular program,
e.g., the order in which the elements of a vector are to be accessed
when the entire vector is being manipulated.
That is the big difference.

    You probably find it hard to understand all those symbols.  
    But saying that it's unreadable is like an american saying 
    that Japaneese is unreadable.  It's only unreadable 
    if you don't understand the symbols.

Some people do find highly symbolic, as distinct from natural-language-like,
notation difficult to comprehend; it's a human engineering issue.
However, Ken Iverson (who is a mathematician by virtue of his formal
education) and his colleagues involved in the design of APL
did devote considerable effort toward making the notation of APL
consistent with that of formal mathemetics.  Even Iverson admits that 
mathematical notation "lacks universality".  When there was no obvious
notational choice, they considered various historical precedents;
when that failed, they invented their own notation.
Thus the Greek letter rho, which is used in mathematics and physics
to designate the length of a vector (e.g., in cylindrical coordinate systems),
was used in APL to indicate the length or cardinality of the vector
data structure [I don't have the exact rationale for the choice of rho
in front of me, but this should suggest the general ideas].
For a full discussion, see
Kenneth E. Iverson: "Notation As A Tool Of Thought" (1979 Turing Award
Lecture), *CACM* vol. 23, num. 8, August 1980, p. 444 .. 465.
Compare the care used in devising the notation for APL
with the use of in C of countermnemonic symbols like "&" for "address of".
In APL, the question is only "what's that symbol mean ?";
in C, it's often "what is that symbol being used for this time ?".
Personally, I would much rather learn many symbols with distinct meanings,
as in APL, than learn a few symbols with many unrelated meanings, as in C.
Consider the many meanings of parentheses in FORTRAN and C.
    
    >By the way, has anyone ever found a way to write structured APL?

    I'm afraid that you've betrayed your lack of knowlege of APL 
    by asking for a way to write structured APL (saying that you've used it, 
    is different than saying that you understand it).   

Why not answer the question first ?  
Yes, many people have devised their own form of "structured APL".  
For example, there was one in the '70s called APLGOL, 
which embedded APL expressions in Algol-like statements.
The push for a "structured APL" probably peaked in the mid-70s.
There are still probably papers appearing in *APL Quote Quad* describing
new variations on the theme of "structured APL".
The problem has been that the majority of the APL community
has not accepted these graftings (or mongrelizations) of APL
with other languages.  It's like grafting a Winnebago to a Porsche.

    One of the best elements of APL is that it attempts to 
    substitute powerful notation for procedural specification ...
    ... [structured programming] concepts aren't as necessary in APL 
    because the vast majority of loops and things, are eliminated 
    because of APLs powerful set of functions and operators.

Structured programming concepts are still useful
for the decision constructs that APL really does not have.
These are (or at least, were) mostly implemented by programming idioms
involving the built-in functions and operators, e.g., "execute".
This is related to the use of programming idioms conventional languages;
for example, expressing unbounded repetition in C using "for(;;) {...}",
or the same thing in Pascal using "while true do ...",
or loop exits in Pascal with (gasp !  gag !) "goto".

There are shouts about preserving the purity of the language,
but it may well be that no one has done a sufficiently good job
of integrating structured programming features into APL.
But once a part of APL, "structured programming" features 
might not be recognized as such if done properly.  
    
    Another reason why I find APL more readable is its terseness.  
    ...
    The FORGOL program is the algorithm and has all kinds of superfluous 
    confusing things like the sum and index variables and the DO loop.
    
Furthermore, forcing the programmer of a FORTRAN or Algol derivative
to explicitly code irrelevant tasks means that the compiler is forced
to a large degree to perform these irrelevant tasks,
at a sometimes significant cost in execution efficiency.
This has important consequences for parallel and data flow architectures.
As has been mentioned elsewhere in this group, 
extracting the conceptual parallelism from a sequential procedure
is very difficult.  By expressing manipulations of vectors and arrays 
at a high level, APL comes closest of readily available languages
to leaving fundamental parallelism in programs, so that the compiler
or interpreter can deal with parallelism in a straightforward 
and efficient manner.
"Parallel Pascal" or "Vector C" is a language design and implementation 
effort; "Parallel APL" would only be a matter of implementation.

There is much for the language design and programming communities
to learn from APL, if only they can resist the fear of Greek letters.

-- Clay Phipps

-- 
   {cbosgd decvax!decwrl!amd70 harpo hplabs!hpda ihnp4 sri-unix ucbvax!amd70}
   !fortune!phipps