Conference Summary

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

The 89 conference in New York was to be my second exposure to large numbers of APLers in a confined space, the first being our own (that is, British) attempt at Manchester in 1986. I had really enjoyed myself there, with its fascinating series of talks and product displays, although equally enlightening was the opportunity to meet and talk with so many other like-minded, slightly crazy people. I'd had to miss Dallas in '87 and Sydney in '88, but a new job with more committed employers provided both the financial and professional impetus needed, so, together with an old colleague (Simon Barker, now of BUPA), I duly sent off my registration and hotel booking form (taking care not to think about the cost of staying at the Hilton...).

My conference began like the bulk of the other attendees with the Monday morning opening plenary session which was to be given by Tom Gilb (for reports on the Saturday talk/welcome and the Sunday statistics tutorial, see elsewhere in this issue). The talk centred on the development of a formal planning/specification language which seeks to express such vague but essential areas as user requirements, test criteria, cost/benefit tradeoffs etc., in a more quantifiable and structured format. Thus, the usual request for "a more efficient warehouse" would be broken down into 'statements' such as "OBJECTIVE: SHELF SPACE UTILISATION 91-95% [Objects less than 10Kg.]". The performance or characteristics of the existing problem (on which design decisions would be made) would again be broken down into smaller statements which would be easy to identify later , such as "PAST: USER LOAD ON STOCK SYSTEM 120 MAX[Average 85]". Or, later on, "TEST: USER LOAD ON STOCK SYSTEM[Development: 10 staff, 2 locations]". The three components of each statement represent the general statement type, the aspect of the problem to which it refers, and (in the square brackets) any refinement or qualifying statement. Comments may be appended to any of the statements at the end of the line. Another good feature was the introduction of a "SOURCE" statement type, in which specific book/chapter/paragraph references are given at the point at which such information may be used to justify a design decision, rather than in the form of footnotes or the almost totally useless list of titles in some forgotten appendix.

The development and use of this planning language has meant that, for Mr Gilb's systems at least, all requirements are stated and fully defined, both in terms of cost and specific benefits etc. Critical information on existing procedures/factors is stated and the source of that information listed with it, and so on. In this way, Mr Gilb has gone beyond normal systems analysis (which has always seemed obsessed with computer program design, at the expense of full problem definition) to such an extent that his specs have been used as the basis of legal contracts for the development of systems. Despite the fact that Mr.Gilb, a Software Engineering specialist currently based in Norway, did not actually touch on APL, to me it was probably one of the most significant talks for business APL system developers that I've ever heard, especially given the increasing interest in quality assurance. Two short paragraphs do not do justice to a two and a half hour presentation, but hopefully readers will go away and read the proceedings or, better still, obtain a copy of his book, "Principles of Software Engineering Management" (Addison-Wesley, 1988).

The afternoon began with a visit to the Workshop on APL Problem Solving. I'd thought that this would be another opportunity for me to pick up some useful techniques etc., but in fact the two presenters were studying us, the audience, and the thought processes which we went through with a given problem. To provide the data for later study, the audience was paired-off, with one partner acting as the solver while the other recorded the thoughts and ideas as they occurred (the solver was supposed to vocalise ideas, the recorder being allowed to probe but not prompt in any way). After an excruciating 20 minutes (which seemed much longer) the roles were reversed. I'm not sure how valuable was the material gathered, but it was an interesting exercise to see the many differences, and similarities, of approach.

The last session before tea was by Diana Cook, High Productivity Systems, which looked at techniques for designing and/or maintaining large systems. By using a detailed analysis of more than 300 bugs encountered in running a large financial system, the various causes were discussed and the advantages of using structured programming methods illustrated. Of particular importance was the adoption of a set of project control guidelines or principles, many of which though 'obvious' are all too often ignored in a number of sites. The use of data dictionaries to control/translate program access was mentioned as this is a useful method of reducing many common maintenance problems, as was the more rigid control of modifications and enhancements (the cause of many of the worst bugs). Finally, the keeping and analysis of an error log was shown to provide useful data on underlying patterns or problem areas not necessarily discernible from installing individual "fixes".

The last two sessions on Monday were quite different, although equally interesting. Firstly Alan Graham, now ex-IBM, put forward his suggestions for a new, simplified version of APL which would also rationalise some of the variations between competing versions/implementations. Being 'simple', of course, means that the ideas in APL0 are too far-reaching to fit into a small article, but many of his suggestions seemed to produce quite a favourable reaction among the audience. Finally, Anthony Camacho gave an illustrated guide to the design of mazes (that's right, Hampton Court and all that). He'd recently been employed to help design and more importantly check-out some new mazes which had been commissioned around the UK. The most important test was to determine approximately how long it would take for someone to get out!

Tuesday is somewhat blurred for me, since I was suffering from extreme giddiness (delayed jet-lag), but I do remember a fascinating talk by young jazz star Stanley Jordan who used programs to help develop harmonics and musical relationships of which he would not otherwise have dreamed. The other session of note for me was given by Nancy Wheeler, covering an introduction to SQL/DS and later on how it can be used with/from APL2. Given APL's simple yet powerful analysis tools, the idea of using products such as SQL to access the vast amounts of existing data out there could give the language a whole new lease of life.

The Wednesday morning sessions APL2 on the PS/2, and APL In The Workstation Environment which followed it were more in the order of product demonstrations, although each was very well done and quite educational. The workstation demo in particular showed just how much power can now sit on a desk, and helped to emphasise the drift in some organisations toward downloading mainframe systems onto one or more such super-micros.

Just prior to lunch, Arthur Whitney (of Morgan-Stanley) told an increasingly interested audience about a streamlined version of the APL interpreter which he had helped to develop in-house. Among the important design principles adopted for this project were portability (I believe it was written in 'C') and simplicity. As an example of the latter, all "idiom recognition" sub-modules were excluded, attention being given to speeding up the basic procedures with assembler routines once the design was finalised. The significant time-savings achieved by this interpreter were illustrated by comparisons with bench marks run elsewhere. Indeed, so interesting were the results that more than one person (myself included) sought more information afterwards, in particular as to whether it would be made more widely available (unfortunately not).

Immediately following lunch, a further plenary session was held at which Stephen Wolfram demonstrated a stunning package called Mathematica. This package utilises the high resolution Macintosh screen to allow "normal" mathematical symbols and constructs to be typed, except that now values can be assigned to abstract formulae. As in many instances values can also be formulae, the more complex examples began to resemble rule-based systems.

The highlight of Wednesday afternoon was a panel presentation by four experienced developers of Practical Development Techniques for Large Systems. What was fascinating to me as a business user/developer was the variety of approach, albeit in some cases dictated by external constraints on time or budget. Panel members who obviously were well in control of their fate extolled the virtues of comprehensive documentation, beautifully structured design, libraries of utilities with their own maintenance programs/procedures, and of course standards - all good stuff, but not always achievable, which is why the last speaker received so many sympathetic nods. This individual explained about rushed projects with compressed deadlines, prototypes which were so successful that they were immediately installed as production systems, no time to develop standards other than the informal exchange of techniques, with the "strongest" becoming naturally the most common as it was generally accepted. What the last speaker did emphasise, however, were APL's speed of development and change, which helps them to keep their users more than satisfied.

Thursday came all too quickly and began with sessions on data typing and user-defined data types in APL2. After the break, Martin Gfeller and Manuel Alfonseca continued with a look at Object-Oriented Programming in APL. I must confess to being an interested novice in this area, and was hoping to pick up some useful insights. In brief conversations with Mr Gfeller during some earlier coffee-breaks, his ideas for OOP and extensions or revisions of APL, were both stimulating and well structured, with potential advantages to those users not necessarily using OOP techniques. The session itself was rather marred, however, in a number of ways. Firstly, the audio-visual equipment was not functioning at all well, at times making the speaker almost inaudible. This, coupled with Mr Gfeller's lack of large-scale presentation skills, unfortunately blurred the very valuable message which he was trying to get across. What did come across was the suggestion (and I hope this is the right interpretation) that data and functions be grouped into general(-ised?) "classes", with rules governing their interaction just as there are in mathematics or interpreter construction. Unfortunately, neither of the two sessions seemed really accessible to the relative novice, with too much of the discussion descending into the realms of pure maths.

While the emphasis on the pure mathematical (not always related to APL) was rather more prevalent than I would have wished - being a simple "business solutions" APL-er - the conference was on the whole a great success for the ACM/SigAPL group which organised it. As with any event such as this, the organisers are somewhat hostage to those who submit material, and so not every session will suit all tastes - and rightly so. Strange indeed will be the taste of someone who finds nothing of interest, or who does not come away better informed than before. I encourage everyone with an interest in the language to attend at least one conference, therefore, so I will close by offering my thanks to SigAPL and wishing good-luck to the Danes for APL90 in Denmark. See you there.