Using single-character symbolic operators is only one of the ways that APL achieves compact code using a limited repertoire of symbols. It’s one thing to achieve terse code by eliminating boilerplate and using short operation names. APL’s dedication to terseness goes beyond these measures, so that it is really a code golfing language. And that’s something to consider when comparing APL to other languages (like R).
APL overloads each symbol with multiple meanings. Eg, the + in a+b means addition, but in the unary case, +a means complex conjugate (negate the imaginary component). For another example, a≠b tests if a and b are unequal, but ≠a is the “unique mask” of array a (a boolean mask with a 1 for each array element that isn’t duplicated by an earlier element). In general, most functions have both a unary meaning and a binary meaning (for both built-in and user-defined functions. There is additional overloading beyond the unary/binary overloading. The article mentions the ∨ operator: this is a binary function that means both logical or, and greatest common divisor. The ⍨ operator returns a constant function if its left operand is a value, but it performs the “commute” operation if its left operand is a function.
So when the author points out that there are only 80 glyphs in Dyalog APL, that doesn’t tell the whole story.
There aren’t that many glyphs in APL - there are far more unique functions in most big libraries from any mainstream language. Looking at the top of the ‘ride’ editor for Dyalog APL there are 80 glyphs. To make a slightly unfair example, there are a lot of exported functions (288 of them) in {dplyr}…
All this overloading makes APL harder to read. It can be quite a bit of work to figure out which meaning a symbol has, based on its compile-time and run-time context.
I saved the most absurd example for the end. The ○ function is overloaded to provide all of the trigonometric functions. ○a is pi×a, 1○a is sin(a), 2○a is cos(a), and so on. Sure, “1○” is one character shorter than “sin”, but come on, seriously?
In summary, the use of many single character non-ASCII operator symbols is not the problem I have with APL.
GCD is logical or when you treat 0 as false and 1 as true: gcd(0,0)==0, gcd(1,0)==1, gcd(1,1)==1.
Overloaded x - -y is more readable than subtract(x, negate(y)), and much more readable if you don’t speak English. Similarly if(x) is more readable than if(x==true).
We usually mean “readable” subjectively, which is fine. But - bear with me - when code is terse more of it fits on the screen so terse code is objectively more readable by some definitions of “more”.
APL was originally designed to run on a printing terminal. There was a hardware limit to how many glyphs would fit on an IBM Selectric typeball. Since glyphs were a scarce resource, the overloading was a reasonable engineering design tradeoff.
Today we don’t have a glyph shortage. We could use one glyph or name per concept without sacrificing terseness.
The overloading of − to mean subtract or negate is easier to defend than any of APL’s other overloadings because it is taught in highschool algebra and used in almost every programming language. It’s familiar. But if you want to see what algebra would look like without that overloading, it would be: x − ⁻y. This is just as terse. APL already has a raised minus sign (⁻) used as a high precedence negate operator (but only for numeric literals).
It’s refreshing to see that comments here focus on the semantics of the language, rather than “it looks weird so I don’t like it”. However I’d like to make an observation.
I’ve used APL for jobs like post-processing database output, before equivalent operations were added to the SQL implementation. In my opinion the worst thing that happened to the language was moving away from glyph composition by overstriking (originally on mechanical terminals) to having several precomposed glyphs on each keycap (i.e. on CRT-based terminals).
It’s relatively easy to remember the positions of around about 40ish extra glyphs. It’s far more difficult to remember the position of the hundred or so you get when a keyboard on which the keytop designer has really let rip, particularly when also trying to develop the mindset required for an alien language.
As fun as looking at APL is, the main issue i have with it is the need for unicode symbols i dont even have access too with my keyboard. I think id prefer R in this case.
(post author here) I actually went the slightly cheaper route and got stickers which I now have on my laptop - can be seen in this post https://jcarroll.com.au/2023/12/10/advent-of-array-elegance/ - but it’s good to know there are keycaps out there.
There is a plugin for every editor. I believe the point is to get to a level where you can intuit the symbols in a manner that the density can convey way more information on a line which would make the mastery worthwhile.
Using single-character symbolic operators is only one of the ways that APL achieves compact code using a limited repertoire of symbols. It’s one thing to achieve terse code by eliminating boilerplate and using short operation names. APL’s dedication to terseness goes beyond these measures, so that it is really a code golfing language. And that’s something to consider when comparing APL to other languages (like R).
APL overloads each symbol with multiple meanings. Eg, the + in a+b means addition, but in the unary case, +a means complex conjugate (negate the imaginary component). For another example, a≠b tests if a and b are unequal, but ≠a is the “unique mask” of array a (a boolean mask with a 1 for each array element that isn’t duplicated by an earlier element). In general, most functions have both a unary meaning and a binary meaning (for both built-in and user-defined functions. There is additional overloading beyond the unary/binary overloading. The article mentions the ∨ operator: this is a binary function that means both logical or, and greatest common divisor. The ⍨ operator returns a constant function if its left operand is a value, but it performs the “commute” operation if its left operand is a function.
So when the author points out that there are only 80 glyphs in Dyalog APL, that doesn’t tell the whole story.
All this overloading makes APL harder to read. It can be quite a bit of work to figure out which meaning a symbol has, based on its compile-time and run-time context.
I saved the most absurd example for the end. The ○ function is overloaded to provide all of the trigonometric functions. ○a is pi×a, 1○a is sin(a), 2○a is cos(a), and so on. Sure, “1○” is one character shorter than “sin”, but come on, seriously?
In summary, the use of many single character non-ASCII operator symbols is not the problem I have with APL.
counter arguments:
GCD is logical or when you treat 0 as false and 1 as true: gcd(0,0)==0, gcd(1,0)==1, gcd(1,1)==1.
Overloaded
x - -yis more readable thansubtract(x, negate(y)), and much more readable if you don’t speak English. Similarlyif(x)is more readable thanif(x==true).We usually mean “readable” subjectively, which is fine. But - bear with me - when code is terse more of it fits on the screen so terse code is objectively more readable by some definitions of “more”.
As for ○… nah I got nothing. It’s terrible.
APL was originally designed to run on a printing terminal. There was a hardware limit to how many glyphs would fit on an IBM Selectric typeball. Since glyphs were a scarce resource, the overloading was a reasonable engineering design tradeoff.
Today we don’t have a glyph shortage. We could use one glyph or name per concept without sacrificing terseness.
The overloading of − to mean subtract or negate is easier to defend than any of APL’s other overloadings because it is taught in highschool algebra and used in almost every programming language. It’s familiar. But if you want to see what algebra would look like without that overloading, it would be: x − ⁻y. This is just as terse. APL already has a raised minus sign (⁻) used as a high precedence negate operator (but only for numeric literals).
Not an array language (AFAIU), but here are some of the mentioned problems solved in (glorious) Factor:
It’s refreshing to see that comments here focus on the semantics of the language, rather than “it looks weird so I don’t like it”. However I’d like to make an observation.
I’ve used APL for jobs like post-processing database output, before equivalent operations were added to the SQL implementation. In my opinion the worst thing that happened to the language was moving away from glyph composition by overstriking (originally on mechanical terminals) to having several precomposed glyphs on each keycap (i.e. on CRT-based terminals).
It’s relatively easy to remember the positions of around about 40ish extra glyphs. It’s far more difficult to remember the position of the hundred or so you get when a keyboard on which the keytop designer has really let rip, particularly when also trying to develop the mindset required for an alien language.
https://web.archive.org/web/20200216181909/http://www.aplusdev.org/keyboard.html
As fun as looking at APL is, the main issue i have with it is the need for unicode symbols i dont even have access too with my keyboard. I think id prefer R in this case.
You can try J or K! Both are ASCII-only APLs.
The keyboard problem can be solved :-)
Tangential aside: the Cherry MX APL keycaps linked from that page are a style called “Olivia” named after its designer Olivia Briggs. Briggs designed another keycap set called Olive and was one of the creators of the VIA keyboard configuration software.
(post author here) I actually went the slightly cheaper route and got stickers which I now have on my laptop - can be seen in this post https://jcarroll.com.au/2023/12/10/advent-of-array-elegance/ - but it’s good to know there are keycaps out there.
There is a plugin for every editor. I believe the point is to get to a level where you can intuit the symbols in a manner that the density can convey way more information on a line which would make the mastery worthwhile.