Ken Thompson wrote an APL interpreter in the early days of Unix, named APL\11. That interpreter went through a number of iterations and has had a number of wonderful contributors.

I started using it in grad school on early Unix machines, and have continued to have it on every machine since then. I would rebuild it from source on every new machine I used, from early PDP-11's running ATT Unix, through FreeBSD on x86, and now Linux on basically everything.

Some time in the early aughts, I lost the ability to build the APL binary from source, and started copying an existing binary from linux box to linux box. Surprisingly, I was able to get away with this for quite a long time without thinking about it very much.

Last year, I decided to re-commit to building from source. To my dismay, I discovered that this had become basically impossible. The code used 70's style puns involving integers and pointers all through the code, and 64-bit machines and compilers simply would have none of that.

I have spent a good bit of time updating the code and bringing it back to life. This has been an act of love and appreciation. This program is something I have used on innumerable projects over the years, and I am grateful to its many authors and contributors. It is currently at

    http://github.com/gregfjohnson/aplette

and is a work in progress.

I would refer to this project as "heirloom software". It is touchingly old-fashioned in some ways, a bit dusty, and still fully serviceable.

It is a bit like owning and flying an Ercoupe. A bit quirky, an ongoing effort of love, but a joy to fly.

Aplette uses an optional ascii APL character mapping dubbed APL-touchtype.

If you can write APL with your eyes closed, you can use APL-touchtype. "rho" is "R", "iota" is "I", etc. Trig is "O". Log is "O@*". (APL-touchtype uses "@" instead of backspace, and with that trivial substitution, all of the APL overstrikes become APL-touchtype ascii.)

This scheme makes it possible to think of APL as something close to a standard, handy utility language on a linux box. ssh from here to there, use it wherever you are, on whatever machine you happen to have handy.

I believe Gnu APL is a great effort, and would encourage people to check it out and use it. It is much more within the mainstream of APL thinking.

However, from early on APL has had a philosophy that it was the entire interactive environment you lived in. It was shell, editor, tool belt, SDK, and bathtub. While all of these things were unique to APL and Lisp environments in their time, the world has come a long way. There are now better and more convenient ways to do most of these ancillary activities.

When these SDK-ish aspects of APL are de-emphasized, the true jewel-like beauty at the core of APL emerges resplendent.

I have come to love the Unix small-is-beautiful approach to development. Multiple tools, elegant composition mechanisms, a bazaar with many booths and a heterogeneous riot of ideas.

So, I would like to see APL find a place in the unix/linux ecosystem as a sibling of awk, sed, binutils, vim, perl, python, bash, lua, ruby, etc.

Edit your APL with vim, run APL files like scripts from the shell, pipe inputs and outputs, copy an APL binary or build it anywhere with a C compiler, run it immediately and conveniently.

This is the direction in which I would like to see a derivative of APL grow and develop.