Plea for naming conventions

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

APL enjoys the privilege, both in Britain and internationally, of being the focal point of a community of advocates, academics and acolytes. Most of the members of the British APL Association derive some or all of their professional income from the disciplines of APL, and we are all aware that the BAA provides, in part, an umbrella for political activities to promote understanding and use of the language.

Romilly Cocking, of Cocking and Drury Limited, made a short impromptu speech during the presentation of an APL micro at the November 1985 meeting of the BAA, and particularly addressed a major problem facing the British APL community at present. In a plea to encourage the availability of APL to schools and colleges, he pointed out that the use of APL cannot grow unless the number of capable APL programmers grows also to match the demand. He felt that APL programmers could easily price themselves out of the market.

A great deal of commercial APL programming in this country is performed by contractors, working either through agencies or specialist software houses. In fact, there seems to be a current trend among companies that employ full-time APL staff to reduce or eliminate these sections of their data processing departments.

APL and DP are traditional enemies. This is partly because of the way APL has grown over its twenty-nine year history. The adoption of APL has been a programmer-driven rather than management-driven phenomenon. APL programmers tend to be undisciplined, and this seems to be a function of the language itself rather than of the sort of people that are drawn to APL in the first place. DP departments do not like undisciplined programmers, particularly when the unfair advantages of the language they use leads them to behave like smartasses as well.

Why does APL lead to undisciplined programming? Its remarkable ease of use leads to two problems. Firstly, it is possible for an APL programmer to begin work on a system before a single page of specification has been produced. The interpretive environment of restartability provided by the active workspace, the ease of language extension, the function-base design, component file systems, and adaptability to new requirements, enable the programmer to design the system as he goes along, altering the overall approach and introducing new ideas as fast as the requirements change and develop. Secondly, it is possible to design an entire system without a comment being written, or a listing being printed. Every one of the advantages of the language listed above becomes a disadvantage in this respect.

Provided that development of a computer system is continuous, and the programmer or team remains constant, the problems are not serious. But the high turnover and relatively weak loyalties of all programmers are well-known, and APL programmers suffer more from these shortcomings because of the lack of stability of APL within DP and the large relative number of contractors. It is therefore especially important that APL systems are maintainable.

The draft international standard has been hailed, as all standards are, as a great advance in stabilising APL itself, and thus hopefully improving its image as an acceptable implementation language among DP departments. By contrast with COBOL however, which became popular primarily because of demands for a (to a certain extent) self-documenting and maintainable language system, and many other languages like PL/1, PASCAL, FOCUS, etc, APL code can be very obscure. The answer to this criticism has been that APL can be used in a highly structured manner, and that code can be as clear as a bell.

In practice, it hardly ever is, and this seems to me to be very sad.

In compiled languages, routines can be grouped to emphasise functional interdependence, and can be ordered to indicate structure and flow of control. Declarations can also be grouped to show structure, and their mere presence can give a deep insight into the purpose of the block in which they appear. Even the naive use of the letters I to N to indicate integers in FORTRAN, or the use of $ in BASIC to indicate strings, gives a certain clarity. And the presence of the underline character for use in names makes identification of their purpose a little clearer.

APL has none of these features. The only apparent ordering of objects in a workspace is alphabetic, except local declarations in function headers, where virtually no use is made of order. With the obsolescence of groups, which in any case were difficult to maintain and used almost exclusively for )COPY, and hardly ever for the organised production of listings, there remain only artificial means of grouping objects.

Some attempts to correct the course of development of APL to include grouping and ordering of objects have been published in the various proceedings from past international APL conferences, but language development has a high inertia, and recent developments among the big guns of the APL world have shown that perhaps it is better to leave well alone than to try and put in every good, new idea that comes along.

So it is left to us, the programmers, to develop standards of our own. I hope that, like me, most programmers have some self-imposed standards, including naming conventions for functional groups, labels, function arguments and particularly global arrays, and also some commenting standards, like at least one line of general description per function, plus a description of the domain of each of the arguments and the result (and global used or affected).

The problem is that, even where such conventions are used, there is very little agreement. The delta particularly is used in as many ways as there are programmers. (My personal convention is to use it to start the names of global functions and arrays needed only for development of the workspaces, e.g. screen editors, but not in the production version.) In fact the only popular standard I know is the use of the first component of a file to contain a description, and this is often forgotten, over-brief, or months out of date.

In a field where many programmers spend a great deal of time trying to find out what the previous developers were up to, it seems vital to our own interests, and to our credibility as a group to our employers, to develop some standards. And because, as a group, we are very much united and organised, it seems that we should have an advantage over others. A language standard is barely half the answer to the establishment of APL as a competitor with other languages. We need a voluntary, and perhaps ultimately formal, national or international standard of conventions truly to exploit the claimed maintainability of APL systems.

I would not begin to promote such a standard in detail. It has taken many years of different jobs, in different environments on different hardware with different teams, even to begin to get together a set of rules which I am happy with myself. It would be chauvinistic for any of us to attempt to force our own pet ideas down each others’ throats. I should think every APLer in the world has a useful and usable idea to contribute, and we must all listen more than we talk.

This task is several orders of magnitude harder than the language standard was, since thanks to Iverson and IBM in the early days (and no thanks to them now), there is very little disputable content of the language itself. By contrast, there are as many different documentation conventions as there are APL programmers who use them, and even those programmers are lazy. We can only begin by thinking how we each develop code, use comments and names, and then try to formalise that. Then throw the hundreds of ideas into a hat and pull out something which everyone will (reluctantly) accept.

I have heard that British Telecom engineers can always recognise when a phone has been tampered with, because they have their own special way of twisting wires and fastening screws. Perhaps in a few years APL programmers too will be able to examine a workspace and spot the difference between professional work and amateur meddling.