A Personal History of APL (1982)

The easiest way for non-APL programmers to begin to understand APL is to see what it hasn't got: boilerplate and loops. If you discard those from any other programming text you're left with the essence of what the code does. APL is only explicit about that essence, the rest is inferred by the interpreter. That's why it is so compact and that's why if you're used to step-by-step instructions with a ton of air in between you will initially find it hard to read. But that gets easier over time and before you know it you'll think of other languages as hopelessly verbose.

The inventor of APL, Ken Iverson, also made the language J which is very much influenced by APL but does not use the special characters of APL. Think of it as ASCII-APL. It is a very nice language to program in and they have a decent user community. It is open source and is incredibly fast and looks at the first glance as cryptic as APL.<p><a href="https:&#x2F;&#x2F;www.jsoftware.com" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.jsoftware.com</a>

I used APL professionally for about ten years. One of the most interesting applications I worked on was the analysis of DNA sequencing data during the Human Genome project.

The language is interesting, but the management ideas in this are very strange.<p>Example: tin flippers. Items are being checked manually and miscounted. The numbers are inherently inaccurate. And he makes the point that this applies in many other situations - some where the inputs are mechanical, so &quot;Use a machine&quot; isn&#x27;t a solution. (&quot;Use a better machine&quot; might be. But how would you know without being able to monitor output quality?)<p>How is a programming language supposed to fix any of this? Finding gross inconsistenicies shouldn&#x27;t be too hard, but automating broken processes algorithmically means you have automated broken processes.<p>This is not at all the same problem as formally specifying software in ways that make it more reliable.<p>The other problem is that it sees software as strictly sequential in-&gt;stuff happens-&gt;out.<p>This is basically batch mode, not real time. As soon as you need real time I&#x2F;O everything gets a lot more complicated. I don&#x27;t see anything in APL that solves that.<p>And that&#x27;s even more true of business processes. To add: it&#x27;s not that analytics can&#x27;t be useful. But APL won&#x27;t somehow magically guarantee that your analytics are any better or more useful than output from some other language or system.

It&#x27;s at least reassuring to learn from the 1952-1954 section that the phenomenon of doing things without having any clue about them easily predates the microprocessor.<p>(btw I second the recommendation of the 1962 <i>A Programming Language</i>)<p>Edit:<p>&gt; <i>The third page had an illustration that, in a few short lines, described George Dantzig&#x27;s simplex algorithm simply and precisely.</i><p>&gt; <i>That was the overwhelming, crucial experience.</i><p>This is the crucial feature of the APL family for me: they permit algorithm discussions via inline, not block, content.<p>eg: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28970345">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28970345</a><p>Edit 2: Upon reflection, it&#x27;s probably also the Achilles&#x27; Heel of the APL family: most people vastly prefer easy and DWIMy over simple and precise.<p>Edit 3: found the paper containing the simplex algorithm: <a href="https:&#x2F;&#x2F;www.jsoftware.com&#x2F;papers&#x2F;DFSP.htm" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.jsoftware.com&#x2F;papers&#x2F;DFSP.htm</a> Note that 1960 was before &quot;structured programming&quot; so we now have (with the benefit of hindsight) much better ways to express the control flow of this calculation.

I tried J (Iverson&#x27;s successor to APL) in earnest but struggled to understand what I was supposed to do when I needed data structures other than arrays. E.g. tries, trees, hash tables and so on. The majority of the out-of-the-box vocabulary is centered on arrays, so it seemed that either you convert your problem to some kind of an array representation, or go somewhere else.

We had APL on our Prime minicomputer at Swarthmore when I started there in 1978.

Can APL can be used to implement Machine Learning algorithms? It seems like a good fit.

J influenced the creation of Pandas by Wes McKinney.<p>Ah, I sometimes have the wild thought that if he had just stuck with J or APL, Python may not be where it is today in ML. Python has become the Borg.

Someone in the HN comments called out that J is the proof that Iverson&#x27;s &quot;Notation as a Tool of Thought&quot; is a failed idea. Even Iverson himself, the inventor of &quot;Iverson Notation&quot; (proto-APL) as a better math notation, the inventor of APL, who used it to design the IBM 360&#x27;s processor and then turned it into a programming language, abandoned it for ugly ASCII scribble (J) because that was more convenient.<p>I guess the ideas, not the notation, turned out to be the important part after all.<p>&quot;<i>I have only made this letter longer because I have not had the time to make it shorter.</i>&quot; - It&#x27;s Advent of Code[1] (AoC) season again; take a moment to look at the answers people put in the big Reddit answers threads e.g.[2]. The comments are all a beautiful&#x2F;awful zoo of languages - wildly varying in programmer experience level, familiarity with the language, choice of approach and algorithm, runtime, focus on a tidy solution or a quick answer. I wish we could see how much time people put into their solutions - I suspect this famous quote applies and it takes longer whether you polish a plain language or write directly in a terse language. I think the hurried or inexperienced answers tend to be long and garbled, the experienced and polished answers tend to be clean and clear. The racing leaderboard entries that I&#x27;ve seen - people seeing the problem and getting an answer ASAP - tend to be Python, and tend to be short and clear. They&#x27;re almost never (APL, J, K, Q, R, uiua, Haskell). Does that say anything of value about the ability to quickly and clearly express ideas in a language?<p>I feel like there&#x27;s enough of these answers now after years of AoC for someone to analyse and compare the languages. My gut feeling is that non-golfed Python still comes out the most easily writable and easily readable, the nicest balance between density and verbosity.<p>[1] <a href="https:&#x2F;&#x2F;adventofcode.com&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;adventofcode.com&#x2F;</a> - daily puzzles through December, solved with code using whatever language you like, however you like, the site only checks your answer not your working.<p>[2] <a href="https:&#x2F;&#x2F;old.reddit.com&#x2F;r&#x2F;adventofcode&#x2F;comments&#x2F;1883ibu&#x2F;2023_day_1_solutions&#x2F;?limit=500" rel="nofollow noreferrer">https:&#x2F;&#x2F;old.reddit.com&#x2F;r&#x2F;adventofcode&#x2F;comments&#x2F;1883ibu&#x2F;2023_...</a>

I find it sad that APL nowadays means Dyalog. They appear to do amazing work. Unfortunately, the license isn&#x27;t open. Why would I invest time learning it only to be locked in? I wonder how much licensing plays in APL not being more popular and used in the present day. There are open variants, like GNU APL2 and J. However, GNU APL2 has none of the advancements made in the past 40 years and J is J, not APL. The notation is simply different.

GPU programming looks like the modern incarnation of APL.