One Small Step for APL

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 75

It was a warm sunny August mornng in 1982 when I entered Imperial House as the newest member of the Chief Accountant’s Department. My role, inter alia, was to look after the department’s newly acquired Spectrum computer, and to learn a new language – APL. I had done a little research before joining Imperial and discovered that it was a language programmers either loved or hated – and most people I spoke to hated it.

My previous experience had been gained with Micromodeller, running on an Apple, and the PPL general ledger package running on an IBM mainframe. Both are environments where the user develops his own system without programmer intervention. I had also played with ALGOL and BASIC, but a long time ago.

The Chief Accountant’s Department had little experience of micro-computers and due to redecoration of its offices was temporarily relocated. For at least one of the above reasons the Spectrum had been housed in a disused photographic darkroom. The environment, whilst not affecting the operation of the machine (provided the windows weren’t opened) did little to engender my enthusiasm for the new task. I was shown how to switch the machine on, most people knew how to type B to boot, but few knew how to use APL.

A week later and in one fell swoop I was introduced to the teach yourself system, provided by MicroAPL, Gilman and Rose’s “APL an Interactive Approach” and Adrian Smith’s book “Design Handbook for Commercial Systems”, and then I was left to my own devices. These aids to learning either had a soporific effect on railway journeys or left me confused, so I reverted to John Le Carre but he couldn’t help. I found, later, that the non-fiction books helped enhance existing knowledge but lacked the stimulation I needed to gain initial expertise. Therefore, I decided to embark on a series of one day courses on a child’s guide on how to write the ultimate “one liner”. The hieroglyphics gradually began to make sense, but I was not filled with a sense of wonder at the dawning of a new age, and I would have been quite happy if this American import could have been re-incarcerated with the Essense’s Dead Sea Scrolls, in the Qumran Hills.

My new found knowledge – if that’s what three days’ training in a classroom environment could be called – was soon to be put to the test by building a simple system. I had two basic problems:

1. I had to replicate an outdated manual system.
2. There was no detailed specification.

A task which would now take me a day to complete, took me two weeks. The system is still running but it is unsophisticated – and it has more than one line!

The whole experience left me wondering, yet again, why had we chosen a language, which took so long to learn and was so unfriendly. This was not a unique experience as other members of my department felt likewise and resorted to pencil and paper or flocked to the PC.

It was about six months later that I began to get involved in producing a full system specification to be implemented by a trained Analyst/Programmer, whom I watched build the system, and only then did I begin to see what all the fuss was about.

During the subsequent three years I have been closely involved in specifying and building complex accounting systems, and during that time I have acquired a reasonable knowledge of the language. However, I still would not class myself as an APL programmer because I primarily hold an accounting role, the demands of which prevented specialisation in “a programming language”.

I now realise what can be achieved with the language. It has the following obvious advantages:

• It has a short development time for even the most complex systems.
• Routines can be developed into small building blocks or functions which can be interrelated and are easy to debug.
• Data is easily controlled within the workspace.

However, it does tend to have a few disadvantages:

• It is so brief as to be curt.
• The characters are not obvious and cannot be read by anyone but programmers and other dead races.
• It requires a special keyboard and printer.

A well built APL system can give great benefits to the user. However, in the real world, systems are rarely static, the continuing changes in company structure, legal requirements and commercial demands necessitate frequent changes. APL systems are often not easy to change quickly, even for a skilled programmer, unless he is the author. APL allows each person his own style, which partially evolves from his level of competence but also from his approach to the problem.

I have also found that APLers adopt a self-documentation approach to their systems, with a line of text at the start of each function, thus avoiding tedious manuals but not satisfying auditors. Self-documentation benefits those familiar with the system but is probably inadequate for a newcomer, and hence usually results in only authors changing their systems. Because only the originator can make changes, Murphy’s Law says he is usually not at hand when needed to make amendments, as his expertise is in use elsewhere. This criticism is true, to some extent, of other languages but despite their failings these are easier to learn or are less hostile, because of their use of near English commands. Novices gain a fillip from success and users like to gain familiarity with their systems but APL does not encourage them. Harassed users do not always have the time to brief and control their systems analyst, particularly late at night with an early morning deadline, and inevitably there is a desire to control your operating tools.

If a company has made a heavy investment in a computer system it wants to gain the full benefit from not only its main workhorse applications, but also from ad hoc analytical tools for business decision making usually called the “what-if”. This need has led to the growth of the spreadsheet and PC market and a stampede for freedom from programmers, but it seems wasteful to have at least two computers, two terminals, two printers, two languages, etc, etc. The ideal solution to quote ICL would be to have “one per desk” – one machine, one language, at least within each culture. This is not a universal solution to chain everyone to only one supplier, but it can be both expensive and confusing for a non-expert to have to use two computers. Familiarity and dexterity helps speed up the decision-making, particularly with a universal tool – but that tool needs to be both flexible and easy to learn. There ought to be standardisation for the non-expert within a company or department. The guy at the sharp end probably doesn’t care whether he is using APL, Basic or whatever, what he wants is to get the job done in the most efficient way, with the minimum of fuss.

There is no doubt that APL has many advantages over other languages but I believe you experts are not developing it to its potential. There could be great satisfaction and one should not also forget financial reward, in developing the ultimate solution. Could you develop the quantum leap from Lotus 123 et al. I know you are developing many bespoke systems for major customers which form building blocks with other systems. I have also seen interfaces with spreadsheets and heard suggestions about using the PC as a dumb terminal, but is anyone developing for one or two generations out, and more importantly is it likely to expand outside the small world of VECTOR?

My dictionary defines vector as “any quantity requiring direction to be stated as well as magnitude in order to define it properly”. Most people in the business community have heard of Lotus, few will know of APL. Perhaps you in the APL community need more magnitude and more direction. If, as I believe, the product is a good one, you should be able to go out and sell it in the right way with easy to use systems which are well marketed. You are the prophets but have you been left in the wilderness?

If I show my ignorance of what is available, then I am probably representative of the vast majority of your potential customers, who have insufficient information about the power of APL. Don’t wait for the Big Blues of this world to lead the way, expand outside the comfort of the VECTOR clique and develop more user-friendly, generalised products which can help the novice build his own routines, which should enable “what-if” modelling and may eventually interface with other bespoke systems. The development of cheap hardware has created the most receptive audience you could ask for. The keyword system developed for the QL was a good attempt to meet this demand, but it did not go far enough to simplify access to the APL environment, but it did get reviewed outside the computer press.

In writing this I have attempted to be controversial and draw together the adverse comments of others. If you are stimulated to respond please remember you should address the silent majority.