skruger

Cormac McCarthy gets my vote.

The 'unit of thought' thing is a nod to the Ken Iverson paper on APL that won him the Turing Award ("Notation as a Tool of Thought"), also referenced by Dyalog's tag line "The tool of thought for software solutions"). Variations of that phrase are endemic in the array languages space.

It has a huge RoI, even if you never use it in anger. It’s a bit like Lisp in that regard — it shapes your thinking.

A more concise intro to APL for the modern era: https://xpqz.github.io/learnapl

(author)

I faced exactly this situation a few years ago - I went with APL as the “OG”, but it probably doesn’t matter that much. Learning k or j once you know APL is much easier. I wrote a bit about this (apl and k)

https://xpqz.github.io/learnapl

https://xpqz.github.io/kbook

It makes parsing tricky. But for the programmer it’s rarely an issue, as typically definitions are physically close. Some variants like BQN avoids this ambiguity by imposing a naming scheme (function names upper case, array names lower case or similar).

Yes, it's either an array (if A, B and C are arrays), a function derived via the dyadic operator B, with operands A and C being either arrays or functions, a dyadic function call of the dyadic function B (A and C are arrays), or the sequential monadic application of functions A and B to array C, or a derived function as the tacit fork (A, B and C are functions). Did I miss anything?

Whilst LLMs still perform weakly in APL, the situation is improving at pace, and giving it a “skill” to evaluate code makes a dramatic difference. I gave a conference talk about it recently (video): https://youtu.be/H_wdKeJ8gt4

Start here: https://xpqz.github.io/learnapl

or here:

https://xpqz.github.io/kbook

QinetiQ?

The author also wrote an APL for Plan9: https://apl.pmikkelsen.com/

As to the training set's depth of APL, yes, it's an issue. However, it's worth seeing how well MoonBit[1, 2] works with LLMs, faced with exactly the same problem -- integrating the LLM directly into the parser pipeline.

1: https://www.youtube.com/watch?v=SnY0F9w1xdM 2: https://www.moonbitlang.com/blog/moonbit-ai

The learning curve isn’t steep. I’d argue the opposite. K is a tiny, tiny language. Put your mind to it, and you’ll be reading it just fine in a weekend. It’s just different. It’s optimised for its wheelhouse.

Here is a gentle start: https://xpqz.github.io/kbook/Introduction.html

Would you mind sharing what you did? stefan@dyalog

Thanks for saying that. I will update it at some stage for the new array notation stuff.

Should you ever decide to take that leap, maybe start here:

https://xpqz.github.io/learnapl

(disclosure: author)

That’s nice of you to say so.

How’s your Korean?

Yeah—true. I wrote it as “the missing manual” for ngn/k, enough to get someone over the initial hump. It’s not a “Mastering k” tome.