APL – a Glimpse of Heaven (2006)

I did quite a bit of APL programming when I was younger.<p>When describing APL, people talk about the strange symbols, the mathematics, etc... but I have never seen anyone describe something I only realized after some time: APL makes you approach problems quite differently, when you are familiar with it.<p>I stopped thinking in &#x27;steps&#x27; applied to the individual data points, but rather I solved the problem in my head (and writing the line along the way) by aggregating the data points into larger data objects, and then letting the data objects expand in a many-dimension universe, always larger and larger... and then I simply looked at the resulting mega-thing from a different angle, and started crushing it back along different dimensions until I finally got my answer (and my line completed). The resulting one-liner was very hard to read ... but gave me the correct result.<p>Inflation, Change of view-point, Big Crush. That is the core of APL.<p>Yeah I know... sounds crazy. But that was how APL programming felt to me, and I bet I am not alone. No other language I worked with ever triggered in me that kind of mental problem-solving process.

I&#x27;ve dabbled in J, and it&#x27;s left me with a permanent sense of slight disillusionment with regards to every other numerical programming language I&#x27;ve used. It seems mind-boggling that NumPy, MATLAB, and even Julia lack the versatile broadcasting rules of APL family languages. In J, if you write a simple function that composes several built-in operators, your function is fully vectorized and can act on lists and arrays properly, and even arrays of arrays. In MATLAB, the same function stands a pretty good chance of only accepting scalar inputs unless you put extra effort into making it vectorized, and almost certainly won&#x27;t do the right thing when given higher-dimensional arrays. Julia seems to likewise default to being mostly scalar-oriented, and only makes it less painful by having efficient JIT, but still lacks the expressiveness advantage.

&quot;To believe that “plain language” programming would be more readable is Utopian, even intellectually dishonest. For if I say, “a linear function of a variable is equal to the sum of a constant and of the product of a variable and a second constant”, it is incontestably English but completely obscure, even incomprehensible!&quot;<p>This is absolutely true. People try to make a big deal out of natural language for both programming and simply interacting with computers. Rarely would a natural language description be easier, clearer, or faster than a more precise interface (e.g. text for programming, mouse&#x2F;keyboard for interacing with computers).

But only if you have the digital flexibility of a monkey.<p>That said, this is always worth watching as a demo of the language&#x27;s power: <a href="https://www.youtube.com/watch?v=a9xAKttWgP4" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=a9xAKttWgP4</a>. I&#x27;m not afraid to admit that I wish my language could do that.

I have an issue with APL. My grandfather who is a researcher in forest science (sorry English is not my main language), made his own software in APL to manage his own forest. Now, he is becoming old, and trying to get me to get the software, and to understand it for when he will pass.<p>The thing is, I&#x27;m a C++ dev professionally, but whenever I see his code in APL, I cringe. I can&#x27;t get to make him understand that building what is basically a dynamic spreadsheet in APL is kind of complicated for me, coming from an OO side of programming. Also, that&#x27;s the only language he knows.<p>I have a hard time telling him that all the work he did and still does in APL (I guess now there are like thousands of lines) will just go to trash and my uncles will just use Excel to do that when they&#x27;ll take over the forest business.<p>Edit: I have another issue with DyalogAPL. When my grandfather sends me a workspace , I can&#x27;t open it because DyalogAPL is not that much backward compatible ! So if we don&#x27;t have the exact same version, I just can&#x27;t open his workspace. It&#x27;s 2014 , damn !

From a PL standpoint:<p>1) APL clearly made good use of an extensive symbol set. Now that many languages support unicode, this is totally do-able.<p>2) APL is in love with overloading. It&#x27;s not totally my cup of tea, but you could definitely fit this into many modern languages.<p>3) I see a whole lot of MATLAB in there.<p>4) Did... this article actually define any functions at all? Perhaps I missed this.<p>5) It looks you could easily implement APL as a DSL within an existing language with an extensible parser. Racket, for instance.

Another descendent of APL is the K programming language from Arthur Whitney (whose One page APL interpreter inspired the J implementation)<p>I would say that K:J is like C:C++ in terms of complexity (not of heritage). I personally prefer the K and C to J and C++ but to each their own.

The writing is kind of verbose.

If you like APL or are in general interested in material like this then you should definitely check out the J language (which is sort of the successor to APL).<p><a href="http://www.jsoftware.com/" rel="nofollow">http:&#x2F;&#x2F;www.jsoftware.com&#x2F;</a><p>and<p><a href="http://en.wikipedia.org/wiki/J_%28programming_language%29" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;J_%28programming_language%29</a>

All I could think of while reading this was, how am I supposed to type all those weird characters?

He is missing the middle generation - he jumps straight from the 70s (mainframe) to the 90s (Internet) while missing the people like me who grew up with 8-bit systems in the 80s.