Editorial: What is APL?

by Ajay Askoolum

APL. This acronym either evokes a sense of comfort or one of confusion. When confused (state of lacking information), the typical reaction is ‘What is APL?’.

Indeed, what is APL? It is a commercial language which is available on all platforms, from mainframes, MACs, Unix to Personal Computers running DOS, OS/2, Windows 3.1x, 95 and NT (including some shareware versions). In the infancy of personal computers, APL interpreters were available for CP/M machines too. APL is some 30 years old, and has offered a core level of consistency which can only be envied by other major programming languages which have evolved.

Today’s APL strives for compatibility with IBM’s APL2, irrespective of operating system platform. APL2 is a mainframe interpreter. However, the PC offerings, notably APL+Win from APL2000, Dyalog APL/W from Dyadic and APL.68000 from MicroAPL offer ‘core’ language compatibility with APL2 as well as Windows (or MAC in the case of APL.68000) established standards. IBM’s Windows 95/NT version of APL2 is in Beta test level 7; the OS/2 version has been available for a long time.

Therefore, APL, irrespective of its tokens or specialised characters is now DDE, ODBC and Windows API compliant. APL can have a conversation with Microsoft Access, Word, Excel, Lotus123 (to name but a few) and can use third party add-ons such as FarPoint’s VBX (Spread) and Visual Components ActiveX OCX (Formula One) with remarkable ease. TrueType fonts have eliminated the frustration of communicating written APL. APL had maturity from the start, in spite of the adversity of slow CPU, limited memory, storage and expensive hardware such as custom printer heads and character set chips; it has now come of age and works seamlessly, without requiring specialist hardware.

With this level of integration, APL is neither the ‘stick’ to be confronted with, nor is it the fledgling of a protective species which requires a protective environment. Why is it not more successful? More visible? It would be easy to suggest that this is entirely due to not having Microsoft as a benefactor. I can put forward three alternative explanations.

First, is the APL publicity organ (the marketing of APL vendors/distributors as well as the numerous international APL journals, including Vector) in the wrong hands? Possibly so, because this is an agent preaching to the converted. If not so, perhaps the medium of communication is not on a wavelength that reaches the wider world. Indeed the standard clichés that ‘APL works with you, not against you’ or ‘APL takes one tenth of any other language, namely, volume of code and time to develop it’ are only meaningful to the converted.

Second, APL is still in the primitive age when the written word had not been invented. APL users have vendors’ manuals to hand, usually. The uninitiated will not come across APL anywhere else or when they do, they tend to read the epitaph of APL. On the other hand, a novice is spoilt for choice when attempting to find third party reference on any aspect of the world of computing, except APL. An APL user either no longer needs any reference, has become stagnant for the lack of it or knows exactly where to find it through his/her specialist network of contacts, such as Vector’s product guide. Now I can use all the methods, properties and events of Formula One OCX version 5.0 but first I had to find out how to by guesswork: its documentation does not refer to APL, its help desk does not support APL per se and APL2000’s documentation of it could not be more sparse. A viable alternative to finding out is to give up ...

Thirdly, the inherent nature of APL is suicidal. It solves problems very quickly and therefore its requirements such as mainframe CPU, which can have a year’s lead time for planning and budgeting, are more immediate. A longer time cycle can be beneficial because it does not create a ‘crisis’; it allows for a more leisurely approach to planning and development. But, the immediacy of APL ought to be an asset not a liability. I suspect that it is not the development cycle but poor APL coding which is the real culprit. APL is the least prescriptive language I know and it is completely oblivious of programmer abuse. Given that most APL programmers have crafted their skill with a great deal of personal effort (because you have to do everything, you learn everything), it is easy to understand not only the individual style of APL systems in existence but also the political naivety of APL professional in the midst of computing professionals at large. On balance, APL tends to lose the battle for survival, primarily because a life span of 30 years has been long enough to confirm a sense of recurring crisis with the maintenance of APL systems.

Where next for APL?

The Vendors’ concession to control structures or keywords is a major step forward not only for programmer productivity but also for easing the introduction of APL to other programmers. Core compatibility with APL2 also allows programmers to move from one interpreter to another but this is severely jeopardised by departures from the ‘core’ APL2 standards; the different quadAVs, IBM’s own auxiliary processors, Dyadic’s namespaces and the myriad of APL2000’s quad functions are very distinct solutions to standard recurring problems. The result? One APL can talk to another APL only via an interpreter!

From the point of view of attracting new members to the APL fold, a major leap of faith is required of APL vendors: tutorial manuals. These should provide worked examples and commentary on realistic applications using today’s APL. The objective would not be to teach but to illustrate techniques. A stock control or book club application with a GUI front end or indeed other standard exercises on programming courses would be suitable. Demonstration workspaces such as APL+Win’s REL20 are fine for illustrating the power of APL but they make no effort in teaching how to harness the same power (reverse engineering is not a recommended alternative to tutorials).

Vector and other journals need a re-juvenated approach. This can only come from new people getting involved in writing for the journals, or by simply taking the way forward. APL needs to be seen, seen not just by decision makers but especially by passers by. Quite literally, we need to enable APL material to fall into the hands of casual browers in bookshops, newsagents etc. The emphasis needs to be on teaching good standards and promoting today’s basic APL where nested arrays and Windows GUI are no longer specialist topics but integral to the language.

In future, Vector plans to organise issues by themes such as ‘Windows Programming With APL’ , ‘APL Basics’ and ‘Sustainable APL Programming Standards’. Additionally, Vector will organise a number of tutorial/demonstration sessions (see APL News). This requires your contribution, in fact it requires the wider participation of the international APL community. Vector will endeavour to make good APL material accessible to as wide an audience as possible, has considered electronic distribution of material and has a web site for this and other purposes (www.vector.org.uk). Your individual contribution is a vital requirement for the continued success of APL. It is imperative to share/publicise APL insight and expertise, and that implies that the culture for APL development must evolve from being driven by keen individuals to being team based. That is, APL should evolve from the ‘Here’s the solution, what is the problem?’ ideology to the ‘For this problem, APL is demonstrably the effective solution’ ideology.

Finally, an incentive: Vector will give one year’s complimentary subscription for each article which is accepted for and published in a future issue. The forthcoming AGM is an ideal opportunity to express your ideas for Vector and the Association; please avail yourself of the opportunity and come forward.