A Place for Us

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

(Expanded from remarks extemporised at the open discussion that concluded the APL 2002 conference in Madrid.)

Years ago, a friend asked me what was the longest period I could recall between two cups of coffee. I was startled to be unable to think of one longer than fifteen hours. A year ago I started work in APL after being away from it for fifteen years. This is unusual and I learned some things I’m glad to know. The first is that I can give it up any time I want.

The second is that the toolset is way better than it was fifteen years ago. If you’ve been working continuously in the language, getting these improvements bit by bit, you could easily overlook how far APL has come as a software development environment. Twenty years ago it was a rogue: APL had almost no communication with other computer systems, and its programming environment was weak. Now it has a full development environment.

The third is very odd. Organisations that own APL systems almost all have ‘exit strategies’ for APL; or at least an intention to replace them with other technologies. There is something peculiar, and peculiar to APL, that our clients are willing to pay to get rid of our systems. Even more oddly, in the APL world we take this to be normal. We believe our systems are fast and cheap to develop and run. And we accept it as normal that our clients will take trouble to replace them. What is wrong with this picture?

When I was last in the APL world, people expressed hope that APL’s virtues would one day enjoy wide recognition. I no longer hear that. In contrast, speakers here have commented on how our numbers shrink year by year while our average age rises.

A shrinking user group and clients who intend to replace our systems: this makes the predictable future of APL very clear. It will disappear. This will not necessarily happen. But right now it is our predictable future. If we continue like this, APL will disappear from use.

I see no signs of J being taken up for commercial use. A+ usage is fading as Morgan Stanley slowly replaces with conventional, more cheaply maintained software the applications it developed rapidly in the 80s and 90s. K appears to be thriving modestly in close proximity to kdb.

I am interested in a different future, in which our technology flourishes. I have a self-interest: my productivity in APL commands a premium for which I cannot charge in other languages. I want to work in APL, or J, or K, or something like them. I am going to assume that all of us here are at least in favour of a future in which these languages flourish, and that the same is true of the larger group of people at past conferences.

The problem with us¶

A general principle holds that when people espouse something for years and don’t get a result, something is not being said. There is something that the group as a whole is unwilling to look at, express, consider or otherwise deal with.

Some of us inquired into this over dinner during the conference. What is so terrible about our technology that our clients want to get rid of it? Our first thoughts sounded like this. Doesn’t fit in with the IT culture. APL people’s productivity make regular IT folk look bad. Impossible to manage or control.

Which was interesting, because these are not issues about the technology, but about us. Is it possible that we are the problem? That it isn’t our software our clients are spending to get rid of, it’s us?

Perhaps it’s us, not our systems. There are real issues around managing APL software, but I suspect that rather than help IT departments solve them we have for long succumbed to the temptations of being maverick software gurus; and APL’s extraordinary productivity enabled us to get away with that for longer than anyone else could. Something like this is the thesis of an article Bob Brown and I are preparing. If that’s true, no wonder the IT boys want us out. We APLers have created a brush that I suspect J and K folk are taking care not to get tarred with.

There’s a place for us?¶

What would the future we want look like? I need a new category to even pose the question. It is not the future of APL that precisely concerns me, but of something else, common to at least APL, A+, J and K. When programmers in these languages look at a program in C or Visual Basic, we all react with "it doesn’t have to be that laborious". We have a common experience of dense, rigorously general, formal notation that gives us abstractive and expressive power. I don’t know a good name for this, so I’ll call it Dense General Notation or DGN. What divides DGNs from other languages matters more than differences between individual notations.

What would a future in which the DGNs flourish look like? Here are some suggestions:

1. A growing body of commercial developers working in DGNs
2. World-class research being done in and on DGNs
3. A vigorous annual joint conference held by a DGN SIG
4. A web-based study and coaching programme

Here’s something that’s inconsistent with that. You used to be able to smell the future at an APL conference. You could hear about work that might change the future use of computers. Some of that was being done on the language, some of it in the language. An APL conference was an exciting place to be even if you weren’t working in APL. You could sniff the future arriving, and some of it looked like arriving coded in APL. That no longer seems true. The people working on language development are now almost all working elsewhere. And if others are using APL to break radical new ground in their own fields, they’re not coming to our conferences to tell us about it.

Part of the last point must relate to the nearly complete disappearance of APL from education. We used to get a steady trickle of graduates entering the industry because they’d been exposed to APL and wanted more. That seems to have stopped in the UK. The slight use of APL or J in education in the UK is inconsistent with the claims we make for their benefits in exploring mathematics and theories in the natural sciences.

The separation between APL and J users cannot have helped this. As far as I can tell, the educators and the language developers now work with J, leaving a rump of software developers improving their tools (the current APL software development environments really are good) and managing the code base of commercial APL systems. This would explain something about our conferences. Stories of successful systems development can be instructive, but it’s hard to generate much excitement from them.

To address (1) I’ve started on a short series of articles arguing the case in systems development for maverick groups using DGNs to solve pressing problems. Morgan Stanley’s use of A+ to create complex risk-management software would be exemplary. I intend these articles for the IT sections of leading papers in London and New York.

More exposure and commercial credibility for DGNs as tools for smart software developers should stimulate interest within educational institutions and thus (2). The BAA is partly addressing (2) through its Schools Project, which is likely also to produce (4).

Conclusion¶

Bob Brown wonders whether we really are a community, and not just a minority. If we are, we never defined and promoted to the IT majority our place in the mainstream architectures. Delivering impressive systems and delighting end users has not saved and is not saving us from exclusion by the majority.

Life is never static. APL as an industry is contracting and will disappear unless it expands. Expansion requires a rapprochement with mainstream IT that defines the role we play in their architectures and strategies, and distinguishes when and why to use DGNs rather than scalar technologies.

It’s long past time we showed up as the partners of scalar technologists, not the people who make them look foolish.