eric@snark.uu.net (Eric S. Raymond) (08/27/89)
In <1989Aug26.221107.25606@utzoo.uucp> Henry Spencer wrote: > I recall seeing an APL guru -- I think it was Iverson himself, in fact -- > turn a straightforward algorithm (polynomial multiplication, I think) into > a single line of APL. Quite impressive. Also impressive that said line > was quadratic in space and exponential in time, where the original was > linear in both. Once, long ago, I was an APL guru (until I learned LISP and got better :-)). There was a little community of APL experts around the DEC-10 I cut my hacker teeth on. We used to have `one-liner wars' -- the challenge was to see how powerful an algorithm you could code in one line of APL. Using the right-arrow (APL's goto) was acceptable but considered poor form. I once wrote a gotoless one-liner that, given a string and a text matrix `dictionary' would convert the string into a vector of lookup indices for its tokens. Another time I wrote a one-liner `Life' program. Yes, APL is that powerful. But it's also incredibly slow and a hellish memory hog in general, and (most damningly) tends to lead to awkward and inefficient formulations for any algorithm even slightly outside the range of those its fundamental data types are designed to handle. I discovered this last when, after being exposed to LISP, I decided to test the two against each other by a) writing a LISP interpreter in APL, b) writing an APL interpreter in LISP, and seeing which was easier. LISP won hands down, of course. So, after about half an hour of cogitation, I dumped APL and vowed to become expert at the LISP we were using. I did, too. By writing a manual for it...but that's another story. -- Eric S. Raymond = eric@snark.uu.net (mad mastermind of TMN-Netnews)
pardo@cs.washington.edu (David Keppel) (08/28/89)
eric@snark.uu.net (Eric S. Raymond) writes: >Yes, APL is that powerful. But it's also incredibly slow and a hellish memory >hog in general, and (most damningly) tends to lead to awkward and inefficient >formulations for any algorithm even slightly outside the range of those its >fundamental data types are designed to handle. Interested parties should take a look at Tim Budd's work on compiling APL. It won't solve the awkward/inefficient formulations part of the story, but might lead to better memory and time behavior. ;-D on ( APLicable? ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
hjb@otter.hpl.hp.com (Harry Barman) (08/30/89)
As long as you make use of array operations, the performance of APL isn't too bad. The killer is when you get programs that look like fortran, and try to step through each element "by hand". My father is used to work for an APL software house, and has written APL programs that substantially outperform the original COBOL (the APL was reasonably structured as well!). Like many other languages, people can write very messy and cryptic programs in APL. APL does have its uses as a rapid development/prototyping language for applications that require reasonably complex calculations. Cheers, Harry