Seize the Time

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

People have accused me of being very quiet recently; or busy at other things. Well, maybe, but I’ve come to some sort of conclusion about APL, and it’s one that I feel bears the seeds of being potentially a very positive conclusion. Of course, we don’t have a foregone conclusion. Let’s think about revolutions, and the climate which causes revolution to happen…

Basically we have two ingredients in the revolution which might interest us most within our technical domain; an external situation where there is (or may soon be) a need for vastly increased productivity in building computer applications, and an internal situation where the tools at our disposal have improved significantly in the recent past. Of course, I’m writing here from a very narrow perspective, not one that sees APL as a notational advance for human thinking, just one that builds software to do useful, interesting, or paid-for things.

The first thing that made me realise we have to do something was seeing a flyer for a ‘Rapid Application Development’ conference, which conspicuously (to me) omitted any reference to APL. Now, don’t I remember ‘Rapid Application Development’ being one of the keystones of our existence? Are we being frozen out, or are we freezing ourselves out?

Productivity¶

At APL92 one of the regular APLxx attendees made a rather surprising remark; I paraphrase him as saying that his company (an APL consulting house) was doing very well out of the recession. So he said it again. Why? Well, where he operates companies are very concerned about getting the most for their money, recognise the productiveness of APL, and as a consequence the demand for APL is at a premium over demand for less productive application building tools.

Here’s one avenue to exploit.

Equally, to stay with this newfound optimism, let’s believe that one day this recession will come to an end. It may happen sooner than we (and our employers, actual or potential customers) expect; the pace of recovery may be much faster once it begins. At this point there are going to be a lot of projects to plan, process models to update and so forth; all things where computing application development is a crucial precursor.

But where’s the mainstream computing world nowadays? Look around yourself and you’ll see the vast majority of ‘for sale’ development happening in C; which is fine for a final product to be sold by the truckful, or to be run over and over again. But have you costed out development in C against use of a high level language? Watch out though, the gap is narrowing.

APL Advance¶

The new generation of APL interpreters is more interesting than many of us realise; what’s important is that in their various ways they recognise the true significance of both human and software interfaces. Dyalog and Manugistics bring us integration into Windows and other GUIs; APL2 comes as a family of more-or-less compatible products; Sharp APL for the PC provides a realistic APL at a realistic price (take a look at this one, it really is quite something); and MicroAPL gives us access to the Mac. What it’s up to us to do is to begin capitalising on the tools available to us.

Here’s a quote from the latest (November 1992) Byte magazine. ‘… what you mostly need to develop Windows applications at the moment is patience…’ (their italics, page 253). Well, I don’t have a lot of patience, but I do have some tools that let me build Windows applications using APL pretty well. They could be better, but so could everything. We have an advantage right now, we may not have it this time next year.

Choose Your Applications¶

One of my never-ending problems with APL is affordability, and it’s a situation that probably can’t change overnight. Some of us find scenarios where a single run of an application can justify not only the high-price APL interpreters but also the Sun workstation to use it on; not all of us are so lucky. But generally speaking I think there are two major application scenarios for APL to capitalise on.

• High value, non-repetitive modelling applications; the sort of place where a program never runs the same way unchanged. These are the people who can afford Dyalog as it’s priced now; they have an excellent starting point.
• Personal programming, filling in the holes left by ready-made packages, where the programming team is y-o-u; Sharp APL/PC (I forget the precise name) looks good here.

Of course there are other application profiles, and you may very well find that APL is an excellent fit for your purposes in these; but I think that the two above are the most likely candidates for significant growth.

Tools¶

This is really my point; I think we have to take it upon ourselves to do a lot better here than we have in the past. Look at what the ‘average’ professional C programmer draws on: in addition to the base compiler there are debuggers, profilers, forms designers, utility libraries and so on. It’s all very well for a prominent APL vendor to say that we get all of these inside their package, but my credibility is strained.

My impression of the typical APL programmer’s toolkit is that it takes one of three forms:

• The stuff that came with the interpreter
• A ramshackle collection accumulated over the years, or homegrown
• Nothing at all

This has to change, and pretty dramatically. I think we have to begin a collective programme to build a more comprehensive and universally accepted toolkit. What I want to see develop is a situation where instead of APLers being able to agree on 20% of their known universe they can agree on 80%.

Here’s what I suggest as some significant categories for toolkits:

• Meta-APL, which expands the common language core (all those APL2 emulations of ⎕VR and so forth)
• Interfaces, both in the form of software and tutorial documents, so that hooking up APL to popular packages becomes a no-brainer activity
• Code management systems, for the mega-applications

Of course, this is not going to be a trivial pursuit. It may be a lot less ‘fun’ than exploring J. But it just may be part of the route to earning a better living with APL. It’ll take time and it’ll take money. These tools will have to be paid for, and I’d hope that we move into a mode where APL software is both inexpensive and readily bought and sold. We have to build it for ourselves and sell it among ourselves (just like the antique shops) so that when newcomers arrive they’ll walk into a richer environment.

At the end of the day one of the prime indicators of health in an industry is the amount of third-party activity that surrounds the centre; at present I perceive APL as having very little. I think this will change. I think it has to change.