General Correspondence
Vector 4:2, page 9
Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 9
The VECTOR working group welcomes correspondence on any topic affecting the APL community. All letters should be addressed to the Editor, and should indicate whether they are for the general or technical section. (Letters containing APL code will normally be classed as 'technical'.) The Editor reserves the right to edit any letter unless the writer states that it is to be published in full or not at all.
Experience of 4GLs¶
The VECTOR 3.4 Technical Editorial mentioned 4th Generation Languages, and asked for experience/opinion (well, maybe you didn't, but here are a few words anyway).
Firstly, several years ago I did get a little exposure to what I'm told is a reasonably successful example, called UFO; it wasn't a very happy experience for many reasons, not all of them technical. Nevertheless I can recall one or two things about it which I believe are relevant and may be of general applicability.
a) the panel design process (called for some obscure reason 'screen painting') was slightly simpler and faster than the 2 FSC124/6 <DESIGN> process which most IBM-based APLers will be familiar with. But not so much so that I ever felt I wanted to write an emulation to use in my APL work.
b) the system provided absolutely no feedback about whether or not it was working (being used) correctly - if it worked everything was fine, but if not there never was any information about why (my favourite was a message along the lines that 'the information being displayed may not be the information requested' - I really loved the word 'may', it did so much for my confidence).
Now maybe I'm not totally fair on the product, and the UFO vendors could have reasonable cause to get mad at me; but the point is that I've never felt that this product had any advantage to me over using APL and all the utility workspaces which sit around in any well-endowed system.
But I think that beyond particular instances there's a more general topic about APL and where we're going with it that we should be thinking about (and I'm quite happy for the APL community to do its thinking in public).
Back when I started with APL (and it's longer ago than it ever seems to have been) there seemed to be two sports which the community engaged in: IBM-baiting and Cobol-knocking. The first seems still to be with us, which is increasingly unfortunate, but the second has evolved over the years (were we ever seriously in competition with Cobol?), and now seems rather belatedly to have turned into worrying about APL usage being eroded away by fourth-generation languages.
I predict that you could get a number of contributions like mine above, from APLers who took a look and didn't like what they saw; what you won't get (and what you probably need rather more) is contributions from people who did like what they saw and moved away from APL of their own volition (let's not get distracted by people who had to move because their managers got hyped/threatened/bribed into adopting non-APL solutions).
But that's all beside the point - which is that it's TOO LATE to get bothered about this sort of thing - if we were going to do anything to make sure that APL was regarded as the major tool for solving the sort of problems which fourth generation languages are being applied to then we should have done it four or five years ago. What were we doing then? Mostly snarling at anyone who had the audacity to use ADRS ('real men don't use ADRS').
If we go around on the defensive all the time then we'll lose out (did the Vietcong win by building nuclear bunkers?) - in any case since everybody knows that APLers are offensive why not act like they expect?
What we don't do is to build APL-based fourth-generation packages (the opposition has a size advantage, their fifty assembler coders are going to beat our one APLer every day).
What we ought to be doing is looking forward, and finding niches in the application world which aren't filled (yet?); our strength lies in the processing power of APL and in the speed with which we can utilise it; I for one am not going to get upset if I never again have to write one of the form-filling/file updating applications which I used to do in APL but which can now be handled economically by someone else using a fourth-generation language - the world is full of interesting and difficult jobs which we can handle and these guys can't.
I suggest that the threat to APL is a more subtle one than that of taking away some of our existing work - what the package suppliers want to do is take the DP department onto a roller-coaster of their own proprietary products regardless of the eventual cost to the customer. There are one or two questions which the APLer ought to be asking in situations which bring them close to things like fourth-generation languages:
a) Are all foreseen requirements handled by the package as it presently stands - or are future add-ons likely?
b) Can the data be processed with existing 'standard' languages?
c) Is there a requirement for portability/comparability across a variety of hardware/software environments - how is this met?
d) How long is this solution supposed to last?
I think that APL can give pretty good answers to these sorts of questions; the impression I've received has been that what you get with a fourth-generation language is a very good response to a very limited class of problem. Now some people only have limited problems and good for them - what APL needs to look at is the more ambitious problem where the fourth-generation answer only goes part way; we can eat them for breakfast here if we try (and are allowed to).
Dick Bowman
CEGB
85 Park Street
LONDON SE1
Comments on APL¶
I'm taking advantage of the opportunity to renew my subscription to offer a few comments on items I noticed in the 1987 April issue of VECTOR.
Regarding Norman Thomson's postscript to his letter on page 9, the issue of the name of Johns Hopkins University's Applied Physics Laboratory is discussed in Eugene McDonnell's introduction to 'A Source Book in APL' (APL Press, 1981). Mr. McDonnell also mentions that here in the San Francisco Bay Area, "APL" is known to most people as "American President Lines", a Pacific Basin shipping company.
Two articles discussing approaches to compiled APL appear in the IBM Journal of Research and Development, Vol 30 (November 1986) on pages 583 and 594, respectively. One may obtain a copy of that issue from IBM, Order number G322-0150.
For what it's worth, I feel that APL compilers have a limited place for a while. I find the hurdles facing the handling of shared variables and of loose typing in general rather formidable.
I too am concerned about the thin appreciation of APL. I believe part of the problem is that we APLers and others take the full name too seriously. This leads to publicity in the wrong places. We should be emphasizing APL less or not at all in computer science curricula. One of APL's great virtues is that its effective use doesn't require technical knowledge of computers and software. It is an excellent language for the end user. Hence, I think our educational efforts should reach the potential end users: those who are studying statistics, engineering, economics, almost any discipline requiring numeracy.
History can perhaps provide lessons
APL appeared in the rather early days of that hardy survivor FORTRAN. One of the reasons that FORTRAN caught on and remains valuable is that it too is user-friendly. I've trained countless engineers, geologists and chemists to use FORTRAN, and I haven't had to talk much about computers. They became enthusiastic because they could go right to work with it. I venture to say that FORTRAN wouldn't have enjoyed its continuing success had most of our efforts gone into teaching it to professional programmers. Professional programmers, quite naturally in order to keep their jobs, prefer "programming" languages.
One of the factors behind the growth of the desktop computer industry is that many of the successful languages - Lotus 1-2-3, WordPerfect, etc., also require no professional programmer.
There will and should be a place for the APL "programmer" to create hardware- and software-oriented auxiliary processors, for example; but the real future and most of the added value lies on the APL user.
The preceding remarks about our audience may have some relevance to Mr. A.N. Wiggins' complaint about the marginal costs of distributing APL programs. If we sell the user properly on APL, he'll look upon it as a worthwhile investment in itself, and there should be a growing demand for workspaces from small developers like Mr. Wiggins. I know that Mr. Wiggins will find this observation cold comfort; but we must start somewhere, or else we'll see the continued decline of one of the finest aids to productivity ever hooked to computers.
I also take this opportunity to congratulate you and the Committee on your fine publication.
Richard L Connor
[address omitted]
San Francisco
APL Hand Calculator¶
Re the editorial of VECTOR Vol 3 No 4: it strikes me that what is required, in order to promote the language, is a cheap hand/pocket calculator. This should provide the APL notation, except the programmatic ones del; goto etc., indexing keys and indication to step a one-line display through tables and alphabetic keys for variable assignment. 36 multi-function keys should do it OK, which is comparable with current 'scientific calculators'.
The problem, it seems to me, being that whilst APL was devised as a maths notation, before being accepted as such, it became the big blue programming language of the elite.
E J Sargeant
[address omitted]
Nr. Nottingham
The Failure of the APL Community to Market Itself¶
I have been involved with APL since 1973. In the first instance I used the STSC time-sharing service and after spending six years with APL*PLUS LIMITED, Gareth Brentnall and I formed Mercia Software at the beginning of 1985.
In the whole of my professional data processing career I have never come across a community so dedicated to contemplating its own navel.
I have observed over the years that many of the people involved in promoting APL vary from the technical nutcase to the megalomaniac. There is no doubt in my mind that the major reason for the lack of growth in APL is that the product has never been sold. On the one hand we have the technical types who consider APL a thing of beauty, an end in its own right, which should certainly not be debased by allowing it to be used commercially. Whenever these individuals find the time to speak or to write then it is to chunter on about the overwhelming pleasure to be obtained by transposing the reshape of the dyadic form of the whatsit operator. I suppose at the end of the day if that's what turns you on fair enough, but I am quite certain that this is not what industry, business and commerce want to hear.
At the other extreme there are those who claim to be commercially oriented. Here I have noticed two phenomena. First of all there is the desire to concentrate on excluding all others from the market place. The APL market today is tiny in terms of the total software market place. For a vendor to concern himself primarily with the exclusion of competition from the existing market place is narrow-mindedness the like of which is in my experience unparalleled. Secondly the majority of products tend to be APL interpreters or APL utilities. Such products will be of interest to the APL community but not to business people. Why do those who talk endlessly about APL as a powerful and productive development tool not use it to develop application software? Do they not see that the Finance Director of a company looks for financial applications software, and the Production Director looks for Materials Management software? Is it not clear that these are the people that matter, and they have no interest in APL itself but are only interested in application tools?
I see a constant flow of self-congratulation. Success is achieved outside the APL community not within. For example the APL 86 event was to my mind a failure, it was the APL community talking to the APL community. Why was U.K. business not persuaded to attend? The reason I believe is because they were actively not wanted.
It was an ideal forum for a company to send non-APL people to an exhibition where vendors would show the benefits to be achieved with the use of APL systems. These people who would have visited the exhibition for a day were effectively barred by only providing registrations for the full week.
We are a very small company and consequently our impact is small. What you will see however is most of our limited advertising being spent on promoting products like LOGOL, a finished goods control system, in "trade" publications like BPICS and the O.R. Newsletter.
The last issue of VECTOR published a survey where surprise was expressed at the statistics showing that APL*PLUS/PC accounted for as much as 28% of implementations used. The reason is simple; in early 1983 when the IBM PC was launched APL*PLUS LIMITED set in motion a plan to actively market APL*PLUS/PC. This involved advertising in all sorts of media including "horizontal" magazines like PC USER. We organised mailshots and took the product to trade shows. In short we actively sold the product rather than waiting for the prospects to come to us pleading to be allowed to buy the product.
Back in the early seventies APL was going to be the number one language. It has not happened, the facts show that it claims a tiny proportion of the market. Stop kidding yourselves it is growing and the problem is with the shortage of APLers. That is rubbish, demand drives production in almost every environment, it is not the other way around.
To address the problem of penetration of APL in the market place the community needs to totally re-think its strategy, It must provide application products and it must sell. Let me emphasise the word "SELL", this means going out into the big wide world and persuading company executives to buy your products.
Barrie Webster
Mercia Software Ltd
Aston Science Park
Love Lane
Birmingham B7 4BJ
APL '90 in Copenhagen¶
At APL '87 in Dallas the ACM accepted the Danish offer to host the APL '90 Conference. I wrote the following introduction to the Danish APL Group for the ACM. It might also be of interest for the readers of VECTOR. The postal address of the APL '90 Group is:
APL '90 Gruppen
Dansk Databehandlingsforening
Kronprinsensgade 14
DK-1114 Copenhagen K.
For any questions, you are welcome to contact me through Sharp mailbox code [mailbox code omitted], or the other members of the organizing committee, Gitte Christensen [mailbox code omitted] and Kim Andreason [mailbox code omitted]. The group also has the common mail box code <APL90IG>.
The History and the Organization of the Danish APL Group¶
In 1968 Dr. Kenneth Iverson demonstrated APL at an international summer school at the Technical University near Copenhagen. The following year enthusiastic Danish "witnesses" of that demonstration started the first commercial service bureaux outside the US. The number of such bureaux soon increased from two to five, thus providing Denmark with the highest APL density in the world.
As a natural consequence of that status Denmark became the host nation of the international APL Congress 73, which is still remembered as one of the best APL conferences ever held. The conference was arranged by an ad hoc group representing the three APL vendors that were active at that time. This was to last another four years until the Danish APL Group was founded.
It is a well-known fact that one APLer can often replace a dozen or more COBOL programmers. Therefore it is not a surprise that an APLer can feel lonely - even with the highest APL density in the world.
Early in 1979 two of the lonely APLers met and decided to do something about their situation. They soon discovered that they were not at all alone: Denmark had scores of lonely APLers.
After several months of discussions on How and What it was decided to create a group of six persons plus a secretary from the Danish Data Processing Association. In that way the new-born APL Group would have access to offices and files. By meetings and other arrangements the Group should work for a more widespread use of APL as well as helping APLers to a better utilization of the language. The Danish APL Group could thus be characterized as a committee making arrangements which are open for whoever might be interested rather than a club with ordinary membership.
A series of afternoon meetings on various subjects soon brought the number of attendees close to a hundred. In September 1979 the 10th anniversary of APL in Denmark was celebrated by holding a two day APL conference in the Tivoli Gardens of Copenhagen. Two hundred and fifty APLers came from most parts of Scandinavia. The following years several other conferences, exhibitions and workshops were held in addition to the small afternoon meetings.
Today the Danish APL Group has grown to eight people and a secretary, but it still works without a chairman. An ad hoc committee of three persons from the APL Group has undertaken the task of organizing the APL 90.
Working under the auspices of the Danish Data Processing Association has been a very positive experience for both parties. Arranging the APL 90 in Copenhagen is therefore looked forward to as a culmination of that good cooperation, and as a way leading to another highlight in the history of APL.
Henri Brudzewsky
[address omitted]
DK-3150 Hellebaek
Impetus flies the Nest¶
During the last three years a new Personal Computer product called IMPETUS has been developed at Boeing, based on the TABAPL hierarchical concept, but taking advantage of the economies of PCs while still providing the functionality of a system designed for a large mainframe.
IMPETUS is written in STSC's APL*PLUS/PC, with recourse to assembler where necessary to achieve satisfactory performance. It provides a framework for structuring planning and reporting systems which allows both APL novices and experts to use the inherent power of APL without the responsibility for formatting, saving workspaces, maintaining files and so on.
IMPETUS has now completed 15 months of field testing and is about to be launched to a wider market place. Unfortunately IMPETUS no longer fits the Boeing product strategy and as a result Cedric Heddle, who developed and supported both TABAPL and IMPETUS, has left Boeing to set up his own company - APL Impetus Limited, and has acquired the IMPETUS product from BCS.
Cedric Heddle has been developing and supporting IMPETUS, and before that TABAPL, for over ten years, and no doubt his new company will be offering IMPETUS products and services for many years to come.
Cedric may be reached on [telephone number omitted].
George Macleod
General Manager
Boeing Computer Services (Europe) Ltd
P.O.Box 747, 364 Euston Road
LONDON NW1 3BQ