APL for the Teacher
Vector 2:1, page 79
Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 79
It is generally agreed amongst APL ‘cognoscenti’ that the language has failed to be accepted by the educational and business establishments of the UK to anything like the extent of its promise. At one APL Conference after another, this lack of appreciation has been bemoaned and balefully ascribed to every imaginable reason from the stupidity of “homo sapiens” (the user) to the intractability of God (Ken Iverson).
It is, of course, relatively easy to harp upon this disappointing performance; what is more difficult, however, is to plot a course which will cause the obvious virtues and potential of APL to be better understood by the public.
The purpose of this paper is to propose a line of approach that may enable the objections of the unbelievers to be outflanked and overcome. If this is agreed, the next step would be to decide upon suitable ways of getting the message over to the educators and the users.
When comparisons are made between APL and other languages, the relative merits of each — on performance, conciseness, ease of development, etc. — are usually related as though the purpose of APL was the same as the purpose of other languages. Thus we are accustomed to hearing such remarks about APL as “It is good for the one-off” or “It is just an intellectual exercise for the Great Unwashed.” In my opinion we should refer to and, indeed, teach APL as a different species, a language of control; moreover, at present and for the time being the language of control.
Consider, if you will, the characteristics of an aeroplane. It has its engines which provide the power, and alongside them there is a complementary system which monitors and checks the engine performance and fuel supply, namely the control system. This symbiosis of ordered power is closely inter-connected through a network of nervous system forming a coherent whole, but the two elements are very different in function and purpose.
A company operates in a very similar way. It needs a high-volume DP system to “drive” the organisation (sales accounting, payroll, ledgers, etc.) but it also needs a planning and control system with entirely different attributes to the “heavy-duty” characteristics of transaction-based DP. By contrast, this system has low data volumes and is fed with summarised, rather than detailed information.
I do not subscribe to the idea that this latter control system should form part of the “main-drive” system any more than that the mind of a human being should be mixed up with the locomotory muscles. If the Almighty had wanted it that way surely he would have put our brains in our bottoms.
I propose therefore that those people who design computer systems, or who teach computer studies, should be encouraged to think about installations in two separate parts, the main processing “body” and the control system or “brain”. Computer managers would not have to select one language to support an installation, but two, one of which would automatically be APL. In this way the great competitive language argument would not arise.
Since planning is an art, and data processing is but a rather pedestrian mechanised science, I feel that the idea of a control language would apeal to the more imaginative and creative recruits, and that general recognition of a need for an installation “brain” would ensure the future place and progress of APL.