> > More seriously, it may be that the program was written with the > > assumption that the processor on which it ran had an APL assist feature > > and your service bureau machine lacked the feature. > > It's more likely that it was written to be elegant and concise, > rather than efficient. E.g., using sparse matrices to avoid > extra lines of code. > > I'm not even sure on which machine he ran. We had a 360/65 for a > long time, before upgrading to two 165s. I don't recall the > assist feature - that might have been offered later on?
I never actually met a processor with the (mythical?) APL assist feature. However, I did write mountains of APL throughout the 1980s. APL was always thought of as a resource hog. IMHO it could be very efficient or grotesque, depending on your data structures and algorithms. If you wrote programs in the style of 3 GLs, it was typically a dog. If you wrote programs that exploited the array-orientation of the language, it often ran as fast as hand-crafted assembler or fortran code for the same problem and with a whole lot less effort. FWIW (at least from VS-APL onwards) APL wasn't entirely interpreted. Closing a function definition caused the function to be parsed into a tokenized form that could be processed by the interpreter more or less like a sequence of low-level procedure calls - each specialized for the particular primitive being used. It's not hard to see how such an arrangement could turn out to be pretty fast under the right circumstances. We used to run dozens of interactive APL users on what today would be laughably underpowered systems. Even on a (very busy!) /158. CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
