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

Re:nlp

[X]

Does anyone else see the humor in APL being used to do work on "natural languages"? ;-)

Of course, depending on how you look at it, APL is significantly more straightforward and natural than English.

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).

It sorta lives on...

[cmowire]

I learned a dialect of APL that works with SML in a compilers class.

I haven't heard of it otherwise. For hardcore mathematical coding, it seems like people are using one of the CAS systems like Maple, Matlab, or Mathematica. It seems that a lot of those systems have a lot of the same sort of operators that I learned when I learned APL.

It scared me...

[cluening]

I'm taking a Numerical Analysis class this semester, and one day my professor came in with an example of a program he had written to solve some horrible problem. He put it up on the overhead, and most of the class gasped at the screen full of diamonds, arrows, overscores, and circles. After class I asked him what it was he had shown us, and he proudly said "Oh, that was APL. It's probably slower that most programming languages you could find today, but it makes really small programs..." Ever since then I and a few other students bring that up when we want to bring to mind strange funkiness...

Re:It scared me...

[CaptainCap]

"but it makes really small programs..." I'm a little rusty, but try this on for size Program A [1] -> [0] Translated: Statement [1] goto beginning of program Simply type the program name A and you were on a loop

Re:It scared me...

[CaptainCap]

I also think that APL was the first language to generate the slogan "If you've seen one APL program, you've seen them all."

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!
--

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:Note

[Force]

There is also a derivative language of J, called (wait for it) "K", which also uses ASCII syntax. (www.kx.com)

It's not free, or even cheap :-(

On the plus side, you can download nice PDF versions of their reference manual and user guide for free, and hopefully the syntax is close to J.

Not the most cryptic

[stephend]

I think you'll find that the most cryptic programming langage is actually Intercal. APL is easy by comparison.

J language

[sohp]

It has been re-incarnated as J. Essentially APL without the need for a special keyboard/character set. It looks like fun, if you're into that kind of thing.

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:Soliton

[agardner]

I don't know whether this is before Roger Hui created J; but, he worked for a time at a financial firm that had developed it's own APL variant: A+. Arthur Whitney was also a primary author of A+ -- he later developed K for another financial firm. I'm a big A+ fan and it still lives (barely), despite management discomfort with reliance a proprietary non-standard language. A+ improves on APL is several ways: namespaces, better control structures (no "gotos"), symbol types (that are usable as: variables references, or keys in association lists, or enums, or to ease string manipulation), a good event model (dependencies for lazy evaluation, and callbacks for variable validation/ assignment/ formatting, etc.), a strong gui package, and reasonable performance. A+ in an Emacs IDE is the fastest development environment that I've personally experienced -- that said, it does require some care. A+ does a poor job of enforcing encapsulation and doesn't support inheritance. A+ applications tend to have a lot of global variables and frequently become memory hogs. Also, the APL font set limits portability and puts some people off. And finally, as a proprietary language it doesn't have all the glue to other packages that something like Python or Perl does. I haven't worked with K; but, I understand that it improved execution performance, improved integration with external packages (DBs, spreadsheets, etc.), replaces the APL keyboard w/ ASCII, and added nested namespaces, at the expense of some of the A+ gui eye-candy.

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 was fun

[inicom]

I used to use APL on a Univac 1100. Not only was it a pretty cool language to code in because of the cryptic symbols, I had a teleterm-1030 APL portable printing terminal with a dual apl/ascii keyboard. Just being able to identify all of the symbols was an accomplishment, and serious programs only took up a few lines of code. IMHO, it was more fun than lisp, and less parenthesis-counting. But a completely different programming paradigm than any other language I ever used. aem

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