The Road not Travelled

VECTOR Vol.3 No.4

The Road Not Travelled by Sylvia Camacho

Ifa working lifetime is 40 years, I have already spent three-quarters of mine connected with the computer industry, being employed by it, married into it and, over the last 5 years, living space among proliferating micro-computers. This gives me more hindsight than most and, with the wisdom this is supposed to confer, I to draw some conclusions.

Despite their reputation, there has been nothing spectacularly fast about the development and exploitation of computers. Mary Goldring pointed out that technological innovations, the motor car for instance, take about a generation to get from the drawing board to the mass market. Computer technology has been,-in general, no exception although I think a case might be made that the increase in power per pound has been greater than for any other technology and will lead over the next 20 years to more extensive exploitation of micro- computers as components of other products than as general purpose calculating machines.

When, in 1965, J left computer manufacturing to start a family, the pattern for the use of computers as general purpose calculating machines was already set although there was still a debate in the trade over the rival merits of several (now called 3rd generation) programming languages. I left as magnetic disks were coming into use as a storage medium and although now larger and cheaper, they are still the preferred method of holding data. The advantage of disk over cards and tape is that portions can be overwritten leaving the rest of the data undisturbed. During the late 1960s and early terminal equipment became cheap and reliable and this, together with the indexed files and databases made possible by disk gave rise to interactive program development and use. Changes since then in commercial computing have been largely consolidations and serial processor hardware performance is now close to physical limits. An increase in speed will require a change to parallel processing the first experiments such as the transputer are in the laboratories, on the basis experience we can expect this to take another 20 years to bring into widespread use.

I expect that my reader will by now be protesting that whereas the received wisdom is that we are at the beginning of a computing era, ] am saying that we are near the end of one. This is difficult to reconcile with the recently buoyant market in micro computers and the attention of Government and reasons the scientists and engineers who set such a brisk pace in hardware innovation have not been equalled in imagination by software theorists. The attempt to use languages developed for linguistic the hope of realising something approaching artificial intelligence’ is notably misplaced as it takes no account of what we know about the nature of the real intelligence’ manifest in the brain. course, does not stop vendors who need to bring a useful product to market advertising as artificially intelligent’ software packages that are more properly called expert systems’. | believe that for the foreseeable future the bread and butter of computer system vendors will be packages, including expert systems, directed ata restricted market, developed by or in close collaboration with experts in the problems and practices of workers

102

VECTOR Vol.3 No.4

in that market. There is plenty of scope here for small enterprises but packages need a large market or a rich one and programming estimates being notorious for understatement, software development is likely to be viewed suspiciously by merchant bankers.

However successful the package market, computer users will need bespoke systems to handle those parts of their enterprise which are not run of the mill’ and which give them a competitive edge. It is here that there is a major obstacle. The measure of it is the proliferation of data management packages widely called 4th generation languages. Turning over the pages of one or two trade journals will provide the names of 30-40 of these products, mostly directed at mainframe users and priced in tens or hundreds of thousands of pounds. As the market cannot support this number an unenviable job for computer department managers is to try to spot the vendors who will still be around in 10 years time.

In looking for reasons for this fragmentation, the history of software development is instructive. The transition from machine code (strings of ones and zeros) to a symbolic equivalent which the computer itself could translate into binary notation took only a few months to get started and a year or two to perfect. The need was great and although there was a difference of opinion about the choice of mnemonics for the various functions there were no issues of principle to be settled. What is more, as each manufacturer’s machine had different registers, instruction sets & word formats, they each had to develop their own assemblers (2nd generation languages). The race to come to market with a language which would be a lingua franca between different machines led to much more acrimony but, perhaps because they were more aware of the importance of catching the market or perhaps because they were backed by the US defence establishment, the COBOL team produced the product which has been dominant for 20 years. For the sequential design of computer now used it cannot be challenged  the investment in software and programmer training makes wholesale conversion to any other language unthinkable. Theoretical arguments about language design are simply beside the point. I note that ADA, a language promoted by the Pentagon for real time applications and backed by our government with money for retraining, is finding an unenthusiastic response among software suppliers. They would rather use CORAL, the special purpose language they invented in the 60s, in which there is a small but stable pool of expertise.

If COBOL is so well placed, why are so many looking for an alternative? Programs whether or not written in COBOL will run faster as the speed of the hardware increases. One reason is that cheaper hardware has carried computers down-market where organisations do not expect to spend more on the programmers, whom they perceive as clerks operating the machines, than they do on the machines themselves. Unfortunately the speed of thought not having changed since COBOL was introduced in the 60s, a page of code takes about as long to produce as ever it did. What is more, the expectations of the customers has been raised by the package software and not least by recent, highly interactive micro systems produced for the mass market.

103

VECTOR Vol.3 No.4

The heavy promotion of the many 4th generation products tempts data processing managers to use them in place of COBOL when new code is required. Many considerations influence them in this direction. They are told that the programs will require less code, that good work can be produced with less training, that the analyst himself can do the coding and stop acting as the middle man between the customer and the programmer and so avoid the delays and misundertandings that result from indirect communication. All of these claims are true but there are prices to be paid.

The relationship between 3rd generation languages and the machine code into which they are compiled is direct and easy to understand. A COBOL instruction to MULTIPLY is converted loop of many machine cycles to perform repetitive addition, Even extensions to the language used to access databases are easy to understand in principle. The instruction follows a succession of pointers navigating  among the inter-connected data- groups until the key ofits search argument’ is matched. Although most of the tedious detail of the machine code is hidden, 3rd generation code maps  quite closely to the code which it generates. This gives the coder a feeling for what he is telling the machine to do and the relative costs of different approaches. Moreover, he can choose between different paths to the same goal and plan the interactions between major sections of his job to minimise the time and resources used. It is quite otherwise with 4th generation database managers, report generators, query languages and the like. The code provided is intended to specify what is to be done, not how the computer is to do it. Some people hope that this idea can be developed to the point where the customer will be able to dispense with the analyst as well as the programmer and generate his own code. It is seen that this would require a jargon-free language directed to the expression of the job to be done and making minimum concessions to the fact that it is to on a computer. The instruction input however still has to be translated into machine code only now without a programmer to interpret the what  into how . Not surprisingly this lack of a directing intelligence often produces tortuous machine code. The difficulty of producing generalised algorithms to translate from loosely structured user code to robust and consistent machine code has led the vendors to concentrate on those facililities which are most in demand  data capture, report generation and file handling and enquiry. When used for these purposes and with a sustained attempt to keep the code simple, these tools are effective. They can be used to create some forms of bespoke system but they can never have the control over all the functions of the computer that is implicit in 3rd generation languages. In 1957, six months out of University, I answered a small, classified advertisement in the Daily Telegraph: Wanted, keen and enquiring minds, knowledge of Boolean algebra an advantage’. I had read Philosophy because it excited me and Boolean algebra as part of the course in Formal Logic. It was my good fortune that my degree turned out to be vocational training! Thirty years ago I felt priveleged to be standing at a new frontier. What is the prospect now?

104

VECTOR Vol.3 No.4

We seem to have reached an impasse. We want to produce software that is closely matched to the unique requirements of particular users yet the 3rd generation languages that have the power to produce such individually tailored software are expensive and so slow to specify that the requirement may have changed before the program is completed and attempts to modify it just start the whole slow cycle over again. On the other hand ingenious attempts to use 4th generation code to create sophisticated software are heavy on machine resource and make code hard to amend. I think there are alternative roads which we might take but which of them we do take will depend on the view that influential members of the computing industry and the organisations that support them, both public and private, have of their enterprise. They can choose to see it as part science, part engineering which will progress only if effort is put into software research to match the effort that went into hardware. Alternatively they can choose to see it as a new craft which has now matured and requires only regulation and consolidation to turn it into a profession closely related to accountancy. I think that the former is desirable but that the latter is more likely and that users who are still looking for a tool to help them think may settle for a tool to help them keep their books.

The reason that I think computing is at the moment more craft than science will sound toa layman, paradoxical. It is that mathematics has been excluded from computing. In 1957 the Chief Programmer of my organisation was a Doctor of Mathematics. That was thought to be necessary to master the complexities of binary arithmetic. I was employed though I was not a mathematician (nor any sort of scientist) because I had to talk to customers and the Company knew  that scientists would be no good at that sort of thing. Mathematicians, of course, soon tired of hack coding and commercial computer departments were taken over by people literate but mostly innumerate. They are now the driving force behind the money going into artificial intelligence’ research because they need software which will accept natural language instructions (preferably spoken, not typed). It is sad they will not live to enjoy it. Mathematics is the queen of sciences because it makes possible the communication of ideas Not easy to express concisely and unambiguously in extended prose. Advances in science are often accompanied by extensions to mathematics, particularly extensions to notation although these may not be invented by the man who breaks the new ground  Kepler managed without a multiplication sign! The inventors and beneficiaries of the new notation are often the inheritors of the new science and they use it to create a sound theoretical base for the next advance. The notation which makes the breakthrough and converts a craft into a science is not always mathematical. The modern science of chemistry owes much to John Dalton who drew up a table of atomic weights based on the proportions in which elements combined and used some crude diagrams to explain his hypotheses. As this approach seemed fruitful, others suggested a more systematic notation which has developed into the modern symbolism. Modern chemistry would not be possible without the formulae which underpin its concepts and are now so well known that H20 isa slang term and even H2S04 is recognized by connoiseurs of limericks. Is there any sign of such progress in computing?

105

VECTOR Vol.2 No.4

Some progress has been made in developing a systematic description of the raw material processed by computers. Data analysts have invented terms to describe abstract characteristics of data items such as the relationship between them. They set down the data structures to be processed as entity diagrams’ showing items grouped and the one-to-many or many-to-many relationships between the sets. While drawing up these diagrams often helps define the requirements of the system, they cannot be manipulated like formulae. What is required is an analytic notation and preferably one which can be directly executed by a computer. As so much conventional commercial computing is concerned with comparisons between sets of data, the notation needs to express both mathematical and logical algorithms but I shall use mathematical  as shorthand for both.

So long as computer departments limit their ambitions to helping the accountants keep the books a mathematica! notation is unlikely to be adopted. Systematisation in accounting is confined to double-entry balancing and little mathematics is needed beyond powers for compounding and discounting and ratios for bringing performance in different departments or companies to a common base. However, accountants directly concerned in the management of companies need tools to allow them to project performance, This calls for statistical analysis and forms the basis of what is often called a Company Model’. There are, of course, other fields where modelling is appropriate from Astronomy to Zoology and such models are usually coded in a 3rd generation language like FORTRAN or more recent 4th generation statistical packages like SAS. Unfortunately such code, although executable, is not analytic. Using the analogy with chemistry these are the languages of alchemists. They also have all the drawbacks identified above. Therefore accountants needing models are abandoning the mainframes and learning to adapt micro-computer packages, usually some variety of spreadsheet. This has the advantage of being | or 2 precent of the price of mainframe software and allows them to by-pass the rigidities of DP departments. However, to get the power necessary to model a large company may require a network of micro-computers and file-servers and needs technical know-how in the complexities of micro-computer hardware.

My wisdom of hindsight is therefore that users will continue to be frustrated until they use a mathematical notation to analyse and specify their requirement and a notation that is executable to enable the computer itself to prove their algorithms. Micro computers currently share the language limitations of the mainframes and have additional limitations in speed. However, the new, cheap mass market will respond more quickly than the traditional, expensive and small one. This should enable an analytic and executable language to penetrate fast and deep. Is there any reader who thinks ] am saying there is no road worth travelling until someone has invented such a notation for computer science? I am not saying that because there is a notation. Thirty years ago it was called Iverson s Notation’ but now it is known as APL. To penetrate it must of course, like chemical notation, be taught in every school. Unfortunately, while textbooks with non-alphabetic notation are more expensive than others, they are not prohibitively so but as yet there is no cheap, readily accessible APL interpreter for the most common micro-computers. However if my ambitions are realized we shall have one long before I end my working career.

106

VECTOR Vol.3 No.4

TECHNICAL SECTION

This section of VECTOR is aimed principally at those of our readers who already know APL. It will contain items to interest people with differing degrees of fluency in APL.

107

VECTOR Vol.3 No.4

Technical Editorial: Mind your language

by Jonathan Barman

What other languages should APLers learn, and why? There is concern that the APL community is closed and does not take account of the real  computing that is going on. APL is, after all, a tiny part of the overall computing activity. Naturally, as this is an APL periodical, we think that it should play a much more important role.

Previous editorials have raised the issue of where APL should or should not be used, and we were hoping that articles would be written on the subject. So far there has been very little, and we feel that one of the reasons could be that there are very few APLers who are comfortable in using another language.

If this is true, then it could explain why APL is such a small part of the computing world. If someone does not know another language reasonably well, and is not aware of the way in which the majority of computing is carried out, it is then very difficult for them to describe the benefits of APL ina rational and convincing manner.

Standard APL is a non-looping language. Part of its charm to those who love it is the amazing solutions that are available where, at first sight, looping would appear to be essential. The for each’ operator in the extended APLs allows looping solutions to be defined naturally, but extended APLs need lots of memory and computing power. If a looping solution is the easiest to implement, and extended APL is not available, what are the alternatives? BASIC is so horrible after the elegance of APL that most of us shudder at the thought, although compiled BASIC is quite fast. In fact pretty well all the options come down to a compiled language. PASCAL and C seem to be the most popular alternatives. C seems to have the edge in our view as you can, if needed, get down to basic machine operations, and it is easy to prepare lots of modules which can be pulled off the shelf when needed. This is similar to the the way in which functions can be copied from a utility workspace in APL. PASCAL is used for teaching programming and may be the best for a relative novice. Many APLs now allow ASSEMBLER routines to be called, and if the added speed is worth the considerable investment in programming time, then itis relatively easy to include special functions in the workspace.

There are masses of specialised languages with much the same level of use as APL, some of them stich as PROLOG are much further away from the normal computing traditions. Which ones should we be looking at, and what are the problems that they can solve more easily than APL?

Fourth generation languages are much in the news, and we need articles about them so that we can see if they really do offer the advantages claimed, and if we should seriously consider their use in place of APL for specific problems. Has any reader of VECTOR ever used a fourth generation language?

Please write to give us your personal experiences of successful (and unsuccessful) use of other languages, particularly their use alongside APL, or in applications that might be considered natural  for APL.

108

VECTOR Voi.3 No.4

Technical Correspondence

APL2 bug update From David Piper 18 February 1987 Sir,

Following my letter to the last edition of VECTOR, Iam pleased to say that IBM have seen fit to cure some of the bugs I reported in APL2. Three of the four bugs I reported last time have been fixed. The fourth is claimed not to be a bug anyway, and who am I to argue,

The following problems have been fixed:

!" Fractional line numbers in Editor 2. !" Problems with APL WSID after COPY. = Problems with APL QUIET (IBM claimed this was nota bug, but then fixed it). Thave also found some undocumented changes in the most recent release of. APL2 (Version 1 Release 2). Since these may be of interest to other users, a brief resume follows.

1, QSAM AP 111 The QSAM AP has been upgraded to allow multiple writes to be driven from one assignment to the RECORD variable. The cover functions I have already implemented allow advantage to be taken of this feature simply by enclosing the entire left argument (see my article in the VECTOR Vol.3,No.3).

Ifa text array is assigned to the record variable, each line of the array will be processed as a record, WITHIN THE AP. I have done some benchmarks, and it looks as though this enhancement can save upto 75% of the CPU associated with writing a file. Unfortunately this technique cannot be easily used with the VAR conversion option, variable length records. No enhancement has been made to reading data.

2. )CHECK system command This system command allows various invocation options of APL2 to be changed in-flight . )CHECK SYSTEM displays the current settings. )JCHECK SYSTEM option (value) will change the value associated with the relevant option.

3. )CHECK TRACE If the SYSDEBUG level is set above 128 (using )CHECK SYSTEM), a new type of trace can be placed on functions. This trace counts the number of times each line of code is executed and the total cpu time used. The trace can be set up as follows:

JCHECK SYSTEM SYSDESUG(128) )CHECK TRACE TIME 17 D1B *Poot a trace option on function FOO 19 Ore tFoat 6 Check the initial values of the counters

109

VECTOR Vol.3 No.4

The function (FOO in this case) can now be used normally. Any further reference to 19[]IB FOO  will display the updated trace results, Note that if either of the )CHECK commands is omitted, the trace will not work. In fact trying to reference [IB without setting SYSDEBUG > 128 results ina SYNTAX ERROR.

I hope the above will be of interest to other users of APL2,

Yours sincerely

D.B. Piper Cocking and Drury, London.

Use of WIN

From Mr A N Wiggins

Sir,

I have just read Martyn Adams review of APL*PLUS release 6. I agree with his comments about the WIN functions and their descriptions in the manuals.

Maybe the following function will be of help to any readers trying to get to grips with this area. V RES+SCN ARGLINP:WND [1] AVSCN - CREATE OR EDIT A FULL SCREEN PANEL : A N WIGGINS 12 FEB B7 2] a THE GRAPHICS CHARACTERS ARE IN THE 'F! KEYS (3] 9 WHEN YOU ARE STAISPIED WITH THE SCREEN, EXIT USING THE <INS> KEY [4] a THIS IS WRITTEN AS A BASIC DESCRIPTION OF THE WAY IN WHICH (s) A THE OW FUNCTIONS WORK ... ARD NO MORE i! ® 8 [6] E.G. RESeSCH'' A START CREATING A NEW SCREEN (71 9

E.G. AES+SCN RES a EDIT AW EXISTING SCREEN Cel (3) GKEYS AVAILABLE IN THE SUPPLIED <APLDEMO> WORKSPACE {10] DrevF » CLEARS THE SCREEN (i1] woe 00 25 80 NEW WINDOW SHAPE 142] wwD OWPUS ARG # PUT UP THE SCREEN [13] p-1 DWKEY 433 a ©

REDEFINE THE <INS> KEY (SEE PELOW) (14) LooP:INPMWIW WwD [2] +(433FNPL2])/LO0P a CAN ONLY BREAK OUT OF LOOP WHEN <INS> IS PRESSED (16) RES+UWD OWGET COLLECT THE WINDOW AND OUTPUT v Yours,

AN Wiggins,

Lombard North Central, Lombard House, London, WIA JEU.

110