What Ever Happened to APL?

geophile asks: "Is it still supported? Are there new applications being written in it? Has it been extended? Did it die? When and why? Whatever happened to those funky keyboards?" APL ^[?] has the distinct reputation of being one of the most cryptic programming languages ever invented, due to the fact that it's a language based entirely on symbols. Is anyone out there still using it? If so, for what types of projects?

Comments

nlp

[XneznJuber]

Its still being used in our research division for natural language processing. It's symbolic nature makes it a good choice. And a lot of the new people that come on to the project already know LISP, so its not too bad of a transition for them

It Lives!

[beanyk]

... well kind of. My old company, FX analysts, used it, and their trading system was entirely APL. (It was also a Y2K nightmare, but I think they got that sorted out ...) I grew to love that language - much better than Matlab, for instance.

We got our APL from a company called Dyadic: http://www.dyadic.com/ . They're still in business (more than I can say about my ex-employers).

Note

[Kaufmann]

APL per se uses a non-ASCII character set, which means you need a really funky keyboard. However, there's an APL variant called J which has the same semantics, but a textual (i.e. ASCII) syntax. I remember seeing a J primer somewhere on the Net; you can look for that.

Re:Note

[Apotsy]

Actually, the original APL symbols are in Unicode! Starting with the "I-beam" character at hex value 0x2336. The section they are under is called "Miscellaneous Technical".

Re:APL, the relational language

[crumley]

I know several languages that allow operations to be done on matrices. Surprise, sursprise, its a common feature in language tilted towards numerics. Fortran 90, IDL, etc.

--

Re:It scared me...

[SIGFPE]

It's probably slower that most programming languages you could find today, but it makes really small programs...

This is often true but not for the reason you might think. In principle it should be damn fast if you have a smart optimising interpreter. APL is very good for manipulation of large matrices, say. As the code tends to be very compact the amount of time actually spent interpreting the code itself is small compared to the time spent performing the operations themselves. Also, as the operations tend to be higher level than in C, say, the interpreter has an opportunity to optimise sequences of operations and concatenate them together. In addition APL lends itself nicely to lazy evaluation. On the other hand it's often extremely easy in APL to come up with extremely inefficient algorithms that nobody would even dream of writing in C, say, but are very tempting in APL because they only require 3 or 4 keystrokes! Just a simple example: suppose you want to sum along the diagonals of a matrix - it can be easier to simply resize the matrix to be one wider or one narrower than before and then sum down the columns. With a bad APL interpreter the whole matrix has to be rearranged in memory before summing can take place. Nobody would write code like that in C. On the other hand a good APL interpreter wouldn't really rearrange the array but simply change the way the data is indexed making it potentially almost as efficient as C. I think it's the best language for numerical work and it's a hell of a shame that it's not used more. I wish there were a reasonably priced (eg. free) and easy to install APL interpreter that came with decals I could use to upgrade the keyboard!
--

It even ran on a "portable"

[human bean]

Had to deal with an IBM 5100 for a while, it was the fastest thing I could get my hands on, weighed thirty pounds, but at least it came with a decent handle.

Had a choice between APL and BASIC, I finally settled on the APL as the higher-level operators gave us better performance, and the workspace-based nature of the language was very good for allowing the equipment to be shared out.

What ever happened to Dr. Iverson, anyway?

Special Interest Group on APL

[Sara Chan]

The Association for Computing Machinery has a "special interest group" devoted to APL: SIGAPL. SIGAPL publishes an informal journal, much of which is available online at their website.

APL, the relational language

[K-Man]

APL has some unique ideas that I haven't seen in other languages. One of the most powerful is to allow arrays of arbitrary dimension to be combined or processed using the same operators that apply to scalars. For instance, "A+B" is the same whether A and B are integers, matrices, or 3x10x4 arrays. In either case the result is another object of the same dimension, which can be fed into another operator, and so on.

Other operators allow collapsing or aggregating along one dimension, eg +/A sums up A along its "first" dimension and produces an array of the results. Another operator transposes the array to put the dimensions in the order needed to match other arrays, etc. By transposing and aggregating, complicated relational operations can be performed in one line of code.

In fact, I realized recently that APL has many of the capabilities of SQL, but it is many times more concise. The reason is that, while SQL demands writing out join conditions for every "dimension" (join key) in an expression, APL works by knowing which dimensions are supposed to match in each operation. For example, say A and B are "tables" with 3 "keys" (dimensions) d1-d3, similar to A and B above. If we want to add up A+B elementwise, we have to write out something like:

select A.d1, A.d2, A.d3, A.value + B.value from A, B where A.d1 = B.d1 and A.d2 = B.d2 and A.d3 = B.d3

This is cumbersome and varies according to the number of key fields in A and B. Hopefully you can see that APL is a better solution in this case.

Someday I hope to come up with an APL-like shorthand for doing relational queries. The main idea would be to have joins, cartesian products, aggregations, operators, etc. that work by implicitly matching keys rather than by listing them. In fact, a lot of the APL operators would work if applied directly to tables, eg

select * from A+B

or

select * from +/A where d1 > 17