User:Devon McCormick/ArrayThinking/JConference2014-Slides

Here are the slides for my talk, at the 2014 J Conference in Toronto, on array-thinking. A fuller exposition of the ideas behind these slides may be found here.

Before I introduce “array thinking” by way of some examples of what it is and what it isn’t, I’d like to give some background and provide context about why this is important. The following blog entry from Scott Locklin sets the tone.

Array-thinking is a one of these forgotten, important ideas. There are a number of reasons this idea has been overlooked. In part, it's because of its association with APL and the hostility this language has provoked, even from those who ought to have embraced it. Edsgar Dijkstra provides a notable example of this ill-conceived hostility, as noted here.

Simplifying Code with Array Thinking

Here we see an example of conventionally-written, sequential code for gathering information about nesting levels of parenthesized expressions.

Sequential Code

This code continues below. Note the complexity introduced by the conditional branches. Under each branch, separate scalar variables are updated according to which section of conditionals have been met.

Array Code

The following illustrates how simply we can express much of the above conditional logic in a line of J code. The code - +/\(1 _1 0){~'{}' i. ... - is entered - as indicated by the three-space indent - interactively. The line of numbers following the code is the result of this simple expression applied to the sample string "@{ foo; if (abc) { if (q) {m; } } }" to illustrate its use.

Following this initial illustration, we provide some test cases after assigning the tacit version of the code to the name countNesting.

These test cases give us examples of some likely error cases which we could incorporate into a test suite or flag as errors in the further elaboration of the base expression.

Next, we round out the illustration of how we can use this code to simply generate some of the statistics required in the original problem statement.

Interestingly, this particular example relates back to the afore-mentioned example of Dijkstra's feud with APL, as indicated in these notes by Alan Perlis. Here, he relates how he was struck by the power and simplicity of this notation upon being shown an example, in APL, equivalent to the J expression shown above, for indicating the depth of nesting levels in parentheses.

The author of the motivating example for this exercise was similarly struck by the power of the modern incarnation of this simple array expression. However, continuing below with Perlis's note upon encountering this expression fifty years ago, we find the genesis of Dijkstra's feud with APL.

The picture above of the drink sloshing out of the glass reminds us how hard it is to keep a complex set of thoughts in our working memory. The code example illustrates how an interactive, succinct, array-based notation aids our short-term memory by allowing us to display code and a result together: we can refresh our memories from the display on the screen which shows us a static image of what we're doing.

Compare this simple illustration to the complexity of the numerous states of the sequential code earlier. The array expression requires minimal mental overhead because it encompasses the problem at a high level whereas the sequential code imposes the mental burden of keeping track of

. 1) which branch we are in; . 2) which of the multiple scalar values we must modify in this particular branch; and . 3) how we must modify each of them according the particular section in which their updates reside.

The next example demonstrates how unnecessarily-complicated conditional logic can be simplified by putting it in an array notation. We look at an elucidation of the Euclidean algorithm for working out the least-common multiple of a pair of numbers.

-- Devon McCormick <<DateTime(2015-01-04T18:18:59-0200)>>