Thoughts on APL design
Vector 3:2, page 87
Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 87
There are many facets to the design of an application. As far as APL is concerned there have been many papers and even texts that concern system design. My feeling is that although some of these works are excellent, there has not been enough published on design, and that most of the existing works are hard to find.
I think that the novice applications programmer is particularly hard up in this regard. Even someone who has a couple of years’ experience of APL programming, in university perhaps, is ill-prepared to tackle an applications project. I can recall, for instance, a programmer who asked me plaintively:
“How do I write an application? What do I do to get started?”
Perhaps this fellow was not the self-starter type, but he was certainly bright (he is in fact a lawyer now) and had both a computer science degree and a solid understanding of APL. He had read several texts on APL (Gilman & Rose, Peelle, and others) and was comfortable with NARS (APL2). Just the same he was at a complete loss for what to do.
This predicament, given his background, supports the assertion that APL literature is inadequate, that it is missing critical topics in the general area of applications programming. There is a wealth of papers on particular applications, but these are rarely of much use. Some present algorithms but very, very few reflect the sequence of steps in which the application was actually done.
There is a school of thought which believes that there is no substitute for experience. This school might be called the “experientialists”. The radical wing of this school believes that one should just plunge in, experiment and learn by trial and error. Some believe that this is the way to learn APL to begin with. I would say that it is suitable for a rather small minority, and even for such types it is not necessarily the most expedient approach. One does not learn physics by experiment alone, so why should APL be any different?
On the other hand, experience is the best teacher. There is nothing that can substitute for real-world problems. One only learns by facing new problems. My point is that the learning time could be shortened if the novice had supportive material to study and refer to during the learning phase.
The questions are what sorts of material should be used, and for how long. It’s easier to answer the second. Learning time is infinite, although the percentage of learning time in a project will eventually become quite small. The answer to the first question is more elaborate and I cannot claim in any sense to give it fully. I only hope to open up what has been neglected by the literature so far. The most suitable medium would be an anthology on design, combining several different approaches, even contradictory ones.
If such an anthology were published, it would serve a very useful purpose. It would make APL applications programming more accessible. It might blur the distinction between end-user and applications programmer. It certainly would help to increase the popularity of APL, even perhaps to make APL “the people’s choice”.
Much has been said and done about the problem of making APL more popular. I would guess that there have already been some who have cited education as one of the ways to increase APL’s popularity. More often, however, the focus has been on enhancements to APL, ways of bringing APL to the people. Considering that many APLers fell in love with APL\360, I’m sceptical that enhancements have much essential weight in the matter. My general conclusion is that rather than bringing APL to the people’s level, we need to use the proper educational tools to bring the people to APL. One way to start would be to collect, review and republish the literature on design. To proceed from there one could encourage more people to contribute and to expand the anthology once it has been collected.
I would suggest, as a very first step, that an index of such publications from VECTOR, Quote Quad, APL News, or elsewhere, be developed. VECTOR would seem to be the most appropriate collation point, and the most effective place to disseminate the index.