Enough APL hate!

Ron Garret, while talking about something else, brings up APL for a fashionable slander:

But the drawback to APL is so immediately evident that the mere mention of the language is usually enough to refute the extreme version of the short-is-better argument: APL programs are completely inscrutable, and hence unmaintainable.

I don't mean to pick on Ron especially - a lot of people repeat this, because it's easy and satisfying, even when they know better. Ron evidently does, as he says a few paragraphs later:

Most people find APL code inscrutable, but not APL programmers. Text from *any* language, programming or otherwise, is inscrutable until you know the language.

So why the reputation? APL's one-character names give it an opaque surface, but there's nothing difficult there. Once you learn the names (and there are only a few dozen), there's no more mystery. If this were all there were to APL, the mysterious hieroglyphs would correspond to familiar concepts, and would be easy to learn. But there is something else going on: APL is a functional language.

Despite its prominent assignment operator, APL has very few side-effecting operations. Its programs are usually in a functional style, and are therefore much shorter than their imperative equivalents. To a reader who doesn't expect functional code, this completely obfuscates them, and makes it impossible to find a correspondence between the mysterious operators and familiar concepts. In addition, there are two features that further shorten programs:

1. map is implicit. Values are arrays, and scalar operations (e.g. +) are mapped across arrays without any need to say so. Together with a large supply of predefined array operations (with one-character names!), this makes a heavily collection-based style practical.

2. There are several high-order operators. / is reduce; \ is scanl; . is a combination of Cartesian product and map. As it turns out, high-order operators are especially handy when they have short names and high precedence. (APL's successor, J, takes high-order support even further: it supports some points-free function definitions.)

Here's the real reason I'm talking about APL: both of these features are easily adaptable to other languages. You can get a considerable amount of implicit map just by adding methods to the arithmetic primitives. Libraries of collection operations are even easier. I suspect that if you add these features to a language, you can get much of APL's brevity, even without syntax or inscrutably short names.

And APL may even begin to look less mysterious.

By the way, Ron also said:

a web server in APL would probably be an awful lot of work

Googling... it appears to have been done, but not in public. But I doubt it's especially long. APL can do most of the same things other languages do, so while it might look verbose to an APLer, I doubt it would be longer than in imperative languages.