← Home ← Back to Blog

Common misconceptions about APL

This page will be updated later, and without notice.

APL and other array languages are often unfairly judged by developers on the internet for the qualities that make them differ from what most programmers daily use. This attempts to counter some common misconceptions and predisposed ideas about APL people like to repeat on any APL related media.

APL is so unreadable!

This often comes from people who have not learned APL, and there is usually a response asking them to read the fucking manual. The real problem is that programmers expect every language to be same-ish. Expecting to understand a language without learning it is entitled nonsense. Most languages use familiar keywords and operators, and they contain long words everywhere. This is the worst lens to view APL from, as it was made by a mathematician. APL in some sense acts like a linguistic language, and it contains its own identity. If you learn the identity, you can then do informed criticism, which is much more productive. You can even look at genuine criticism of Array languages from informed people (like Daniel Sockwell does here and here) to gauge if you want to learn it. Even that is better than simply dismissing it altogether.

APL is similar to Regex, APL is an esolang, et al.

APL is not designed to experiment with language development ideas, to be hard to program in, or as a joke. It was carefully designed by Ken Iverson to be usable as a programming language, and it has gone many evolutions to come to its current matured state. Many people like to say that APL is ideal for golf and horrible for production. This has been proven wrong in practice time and again by the many companies productively using APL and its successors commercially. Any language can be successfully used in code golf. APL’s conciseness helps with low byte count, but understanding well-written ungolfed APL is understandably much easier, just like any other language. Many programmers cite the conciseness of APL as a prime reason for why they love programming in it—the obvious idea is that it takes less time to write, but understanding how purposeful this conciseness is makes reading APL easier. Going a step beyond, there are programmers like Elias Martenson who like to write verbose APL with copious amounts of whitespace. If that doesn’t fit your programming philosophy, please just state that instead of making unfounded claims about APL.

The most important thing I want to say is: learn to hate on APL. Correctly.

This doesn’t require learning APL thoroughly as much as understanding how other languages have limitations that APL covers, and how APL has limitations that most of the languages you use cover.

There’s problems with APL, both in and outside of its design, some of them being the fact that most production ready array languages are proprietary, and the various problems with several legacy features that cannot be removed. There are people seeking to elminate these problems, however. There’s many advancements and important discussions happening around APL, and useful criticism from people outside of the APL spectrum is very much needed. I hope that this article was of some help in addressing the biases that prevent people from contributing to a language I love.