Newsgroups: comp.lang.apl
Path: watmath!watserv1!utgpu!cs.utexas.edu!uunet!usc!elroy.jpl.nasa.gov!jato!csi!sam
From: sam@csi.jpl.nasa.gov (Sam Sirlin)
Subject: Re: acceptance of apl
Message-ID: <1992May12.013709.3279@csi.jpl.nasa.gov>
Originator: sam@kalessin
Sender: usenet@csi.jpl.nasa.gov (Network Noise Transfer Service)
Nntp-Posting-Host: kalessin
Organization: Jet Propulsion Laboratory, Pasadena, CA
References:  <92128.195059EERIG07@TECHNION.BITNET>
Date: Tue, 12 May 1992 01:37:09 GMT
Lines: 126


In article <92128.195059EERIG07@TECHNION.BITNET>, <EERIG07@TECHNION.BITNET> writes:
|> i would like to start a thread that may prove useful to the
|> further propagation of apl.

An important issue IMHO. 

|>    it has constantly amazed me that software like matlab has spread
|> throughout our department like wildfire, whereas apl has been
|> totlly passed by. for those not familiar, matlab is a kind of

That's happened throughout the controls community as well as EE. Of
course I expect both of these are small potatoes compared to even a
small niche in the business community. 

|>    i wonder if this is due simply to the fact that matlab uses word
|> primitives. it may be part of the answer. 

Yes. People (raised on fortran) don't fear matlab.

|> 1- apl is so rigorously viewed as being structured, or concise, that
|> once a concept is taken up, it doesn't seem to disappear. namely, the
|> idea of the workspace is treated much to seriously.  take a graphics
|> package for instance - a whole mess of functions and variables that

Very important. I was very surprised when I learned STSC had trashed
groups in their pc product! This was the only tool available to reduce
this problem. I promptly wrote a simple simulator that I use all the
time. Groups are pretty old now though... Matlab solves this by just
using the interpreter to automatically search the defined PATH
environment variable for a .m file  and then load it - all you do is
type plot(x) (or whatever) and it looks for a plot.m to load. This
does have the dissadvantages that 
- name conflicts easily arise
- paths are not changeable in the interpreter (I think...)
It seems to me that APL's library functions should have been extended
to do something of this sort. Perhaps locatives in J will be usefull
here... 


|> 2- matlab provides a very large library of functions for many applications,
|> so that the scientific community at least doesn't always have to write
|> everything from scratch. many of these are hard to find for apl.

Another important point. I had to translate the QR and QZ routines
from EISPACK myself into APL. Needless to say I haven't done all of
EISPACK and LINPACK... Matlab was  designed around these. There's also
very little passing around of APL libraries, due I think mostly to
incompatible language dialects and ws formats. I also think an
unreadable ws interchange format didn't help as much as a readable
(printable ASCII) one would (that's why I use mine). 

|> 3- why oh why does apl ignore the directory structure? 1 is a:,
This must be IBM? Manugistics (was STSC) can deal with dos files and
directories (I think that's one reason almost everyone uses it on
PC's), but the libraries are really just used as shorthands for 
particular paths. Shouldn't they have really become libraries that the
interpreter knows how to draw upon?

|> those are my thoughts. though 1 is the one that bugs me most. i was a TA in
|> a course that used matlab for homework assignments, and couldn't help
|> comparing it constantly to apl. if it werent' for these few shortcomings
|> i would have warmly using apl instead. but how would they have printed
|> graphic output? 

I'm surprised you list lack of graphics as a shortcoming. I've used
APL for plotting since I started using it (APLSV on a Tek 4013!). In fact
I used APL (DEC 20) for a numerical analysis course (the TA was
completely at a loss, but I knew what I was doing anyway). I do agree
that plotting is very important. It's just about the first thing I
port. I actually use J mostly for graphing results generated in
fortran (X windows). 

|> matlab now has a following a few hundred strong in our
|> EE dept, and try to change that. IMHO it seems as if apl developers are
|> determined to keep the number of their clients low, for some obscure
|> reason, which is a real pity.

Matlab has also agressively pursued the academic community, with
substantial discounts to students and schools, but STSC does this too.


My reasons summarized:

1. Lack of code reuse - WS aren't yet a good way to exchange
   code. This is due to:
   a. language incompatibilities in crucial areas like ws format, 
      external files 
   b. lack of a readable, easily transferable format for ws
   This is more of a problem as more of us move off mainframes and
   onto many wildly different desktop computers.

2. Fragmentation of the community. This is especially notable in the
   endless argument over nests and boxes. Generalized arrays are very
   important, and the theoretical issues might be crucial but now they
   are impeding the language. 

3. Lack of a way to organize groups of functions to make them easily
   usable for the task at hand. Give me graphics, LAPACK, but don't
   clutter up my ws. The issue of code in other languages is also
   important (this is being addressed).

Solutions? 

1. Adopt a readable, printable ASCII standard representation. I
somewhat immodestly propose my (slight) generalization of the many
existing keyword systems for the characters toghether with J.
Mitloehner's PP scheme for describing objects. Start using public
repositories of functions (waterloo, Holt's BB,..?).

2. Pick one. Real soon now.

3. I'm not sure about this. It seems you'd want to

   - specify (and be able to respecify) what libraries to be included
   - have the interpreter automatically recognize when a function you
     call is in one of the libraries, and go load it. It would be nice
     if you didn't have to type something special - I'd rather type QZ
     than ]QZ or load qz (you have to do this sort of thing in some
     matlab dialects - yes matlab has dialects already, in fact I know
     of efforts to generalize to include arrays etc...!). 

-- 
Sam Sirlin
Jet Propulsion Laboratory         sam@kalessin.jpl.nasa.gov

