Suggestivity and Idioms in APL

> can't quickly fact-check the answer

If you would like to, visit https://tryapl.org/ and enter:

      ⎕IO ← 0
      bools ← 1 1 1 1 0 1 1 1 0 1 0 1 1 0 0 0 1 1 1 1
      {⍸(⊃⍵)@0⊣¯1⌽0 1⍷⍵} bools

The website will only(I think) let you copy-paste line by line, or it has the symbols in a bar along the top you can click on to enter them, and it has a backtick prefix system for typing them, so `L will enter the quad square on the first line and `[ enters the left arrow. Left arrow is variable assignment and the variable with a quad is a system one. The top line sets array indices count from zero instead of the default indexing from one. The curly braces {} make the code into a scriptblock/anonymous function which is immediately executed on the argument "bools".

If you want to see it building up stage by stage it works from the right, these give the intermediate steps:

    {0 1⍷⍵} bools

    {¯1⌽0 1⍷⍵} bools

    {(⊃⍵)@0⊣¯1⌽0 1⍷⍵} bools

    {⍸(⊃⍵)@0⊣¯1⌽0 1⍷⍵} bools

> "Regardless of whether its breakdown is right or wrong, my true intended commentary is about the opacity of the syntax and the difficulty in reading it (which I elaborated on via an edit, after your comment was posted but before seeing it)."

Which is a bit of a shame because the point of the article is at the end: "I do not believe that you can leverage this kind of suggestivity with languages that are more verbose. [...] It is fundamentally easier to try out many single line expressions than it is to try out many 15 - 30 line expressions. [...] in the same way that any technique that reduces the length of the feedback cycle improves our ability to iterate and therefore learn.".

It's not saying that APL is easy to read, it's claiming that learning to read it/think in it has benefits that don't apply to longer languages - more forest less trees, more design less bricklaying. Taking that away into "I never learned it and it looks hard" is not going with the more interesting part of the claim - like, would you rewrite your Rust code to detect the end of groups, then compare both versions and see they are annoyingly clunky, then search for a version which is more pleasing and suggests variations which may do other useful or interesting things with the groups? Even if you did, doing so may be harder because the Rust code is so much longer (more effort to compare in your head) and you would be less able to because the Rust code took more time to write so you have less time left over.

[This is rather more for the world of doing a mathematical puzzle, seeing two equations look similar and realising that the puzzles share some common underlying thing which you hadn't noticed before, than the world of writing production webservers with fearless concurrency].

> “What would the APL code look like that had a similar off-by-one error? Would it be easy to spot by reading the code?”

It kinda does have an off by one error; (Dyalog) APL defaults to indexing from one and the code assumes indexing from zero. The blog author isa well known APL-er and other “modern APL” users often assume indexing from zero. And the change/fix is the quad-io in my other comment so it’s not easily visible in the code because it’s not in the code at all but it is an easy fix.

At least, that’s one kind of off-by-one error; APL doing whole array transforms in each operation tends not to have as much room for off-by-one errors when you aren’t counting through things in the typical imperative way.