Computing Environments for OR

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

This talk was an attempt to characterise what makes a computing environment for OR effective, followed by an assessment of how APL measures up when compared with a number of alternatives. It is based on 15 years of experience with British Airways’ large O.R. group, which has been working with APL for four years.

The main point is to stress that it is the whole environment that influences whether O.R.’s computing is productive and whether high-quality, maintainable, developable programs, that do what the user wants, get written. This environment includes the language(s) used, editors, the operating system, hardware, and in general everything that contributes to making the computer a useful tool that is fun to use rather than a source of problems.

The choice of computery often depends on such factors as what’s already in use, what we can afford and whether I.B.M. make it. I’m ignoring all this to concentrate on what is most effective at the job of using computers to solve complex airline problems. I identify five main areas and a number of sub-headings. Many of these should need no elaboration – and there is neither the time nor the space to give any – but these are not necessarily the less important ones. Here is the list:

Interactiveness:

• The more interactive the better: terminals, workspaces, interpreters, …

Environmental and External:

• Availability.
• Response times.
• Control: who decides what to buy and how to use it?
• Portability and Upgrade Paths.
• Diseconomies of scale: it costs £10,000 per annum for BA to provide a 3279 terminal on an IBM-compatible NAS mainframe, and £4,000 for a similar terminal on a 10-user mini.
• The Padded Cell: users don’t want other users to slow them down or get in the way.
• Communications: but they need data from each other in all directions.

General Design Principles:

• Re-usable software: the potential cost savings are enormous.
• User-friendliness.
• Orthogonality: a minimal number of independent ideas or features that work well together.
• Clarity.
• Simplicity.
• Learnability: when users are intelligent and mobile, enable them to learn generally useful techniques from individual applications. (This was a main theme of Paul Berry’s plenary presentation at APL83.)

Technical issues:

• Power.
• Up-to-date devices.
• Editors.
• Text- or word-processing.
• More than one thing at once.
• High-level debuggers.
• Windows.

Software availability:

• End-user products: spreadsheets, word-processing, etc.
• Development aids: e.g. code control systems.
• Uniform interfaces: all this software, purchased and written, needs to be interfaced together. Adoption of standards such as IGES, GKS, etc., helps; you also need the sort of glue provided by Unix pipes.

These requirements lead in two directions that often conflict: firstly a desire for a perfect system, and secondly a desire for an open evolving system, with access to the thousands of useful programs that others have written and will write, and security that one’s investment in writing code will be preserved. The first drives you towards a Language System, an integrated operating system, language, debugger, editor, etc. Perhaps the best-known of these is Smalltalk, but Ada in an Apse has similar aspirations, as do several A.I. environments such as Poplog. Even BASIC achieves it for very small-scale problems. APL also falls more or less into this category. The second direction leaves you many fewer options: I would say that PCDOS/MSDOS, Unix, VAX/VMS and IBM-compatible mainframes constitute an exhaustive list of sufficiently open operating systems.

How does APL measure up against this long list of criteria? Moderately. Much better than IMS, say, or than PL/1 under CMS; but no better a suitable Unix- or PCDOS-based toolkit. The strengths of APL are well-known to VECTOR readers, so I merely present a personal list of those that seem most important:

• easy to learn initially;
• fast development time for small problems;
• well standardised (until spoilt by nested arrays);
• generates enthusiasm amongst programmers;
• structure and brevity helps create clear, transparent code;
• workspace environment with very good debugging.

The weaknesses are serious, however, and many seem to get disregarded by the APL community:

• programming in APL requires continual mini-inspirations. This makes it fun, but also hard to write well, and often unclear at the detailed level. Consider the idiom for deleting trailing spaces; it is unnatural and obscure compared with an iterative loop that repetitively looks at the last character and deletes it if it’s a space.
• consequently, APL programmers are very expensive to recruit (at BA we’ve never managed to hire one), and many existing programmers loathe it.
• non-standard hardware: we can’t use 9800 of our current stock of 10000 terminals.
• the workspace orientation makes it very hard to share code across a group of programmers.
• the widely-felt need to try out code to see whether or how it will work militates against a disciplined approach to program quality and the use of structured methodologies.
• APL is very expensive on CPU time; BA has two 10-mips class mainframes dedicated to APL and a semi-permanent task-force investigating why they give such poor response times.

It is this last that is the main reason for two or three medium-sized disasters at BA, and the main reason why OR in BA is moving away from APL.

The talk concluded with a comparison of APL with C/Unix and Focus/PCDOS in respect of the effectiveness factors listed above. This was meant to highlight the different strengths and weaknesses of the three alternatives and generated a good deal of animated discussion.