Skip to content

Panel Discussion: a Market Niche for APL

Chaired by Peter Donnelly, with Brian Drury, Tim Perry, and Richard Nabavi

Vector 5:2, page 71

APL in perspective conference reports

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

Brian Drury

APL has done itself a great dis-service; it has singularly failed to standardise the links to the outside world. APLers tend to feel they are superior, because they are dealing with a superior product, and interpreter writers have shown a lack of commercial awareness.

There are three important quastion marks over APL's future ...

  1. what is IBM's commitment?
  2. if the APL people are so good, and if APL is so good, then why are we so few??
  3. why don't successful software houses use APL???

In the future, most APL use will be concentrated on the superminis and micros. It will be successful only if it is more competitively priced. In particular the price of runtime APL currently precludes the hi-volume, lo-price market.

"I would trade many of the enhancements to APL over the last few years for one ⎕ORACLE or ⎕FOCUS. We are limited only by the imagination and commercial awareness of the APL developers"

Tim Perry

Of the areas where APL makes sense, the interpreter is not a critical part of the price. What do we do about writing our APL code to make it easy to change over to C? What utilities are there to help APL to interface to data maintained by other languages?

Where is the glue to take data and get it into the format we want?

Richard Nabavi

I would like to go back in history a few years. Most of what I'm going to say is based on my own experience of the smaller micro.

There's an implication that APL is in competition with something else ... are we saying that the competition is one thing (spreadsheets, Basic, Pascal) or a whole lot of application-specific tools? The truth is that APL has lost out in relation to 100's of alternatives!

APL is a very general-purpose tool. Which are the market niches where it really should have done well ....

  • Management information. Yes
  • Financial planning and budgeting. Yes
  • Insurance. Yes.
  • Forecasting and modelling. Yes.
  • Market Research bureaux. Here is a niche perfectly matched to APL's strengths, yet no success at all. I recently met a forecast of telecoms apparatus, based on tables of installed base, growth rates etc. This is what APL is for, and they used FORTRAN!!
  • Engineering and scientific. They still use HP calculators and Fortran subroutines.

What is the competition to APL? In the areas where APL has succeeded in the past, its patch is being encroached upon by spreadsheets or applications packages. The strong areas are being squeezed from both sides. All that is left to us is prototyping.

So ... I'm fairly pessimistic if we regard APL as the product we sell today. The real market opportunity was 1982-3 when the competition was MS Basic. The competition now is Quattro and Paradox and Excel! We can't just stand still ... if we were wrong in 1983 we are even more wrong now.

The competition has been putting all its effort into the things that sell packages; links and interfaces. So ... what have they got, and what have we got that they haven't?

BD .................. Lotus was a single company with a single commercial goal. Oracle has had massive marketing and promotion. We cannot hope to match that.

RN .................. The work done by ISO was extremely good, but only covered about 10% of what needed to be done. No standard covers the file systems, screen handling, printers and so on.

RN .................. Writing the package is a very small part of what a software house does - say 10% The rest is documentation, marketing and maintenance.

TP .................. I've been using a rather pathetic system called SAS which has a sort of matrix manipulation language.

BD .................. If you have 18 maintenance programmers and lose one you have 17 left. Thus you have both high visibility, and a degree of security. If you have 1 APL programmer, and lose 1 that leaves none. This could explain a lot about the average DP manager's attitude to APL.

BD .................. I would like to see APL swimming with the tide. Let's build hybrid systems, not rewrite Oracle in APL every time.

TP .................. we need a common set of tools we can use on m/c a, m/c b and so on. With these we will be able to build systems that will last.

RN .................. A lot of emphasis at this conference has been on the user interface. This must fit with the other systems on the same machine - APL must look right to the user.