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.

Depends. APL is the OG. Try a few and see what you like. If you learn one Iverson language, it's pretty easy picking up the others.

Here's a gentle guide to APL by the same author (me):

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

Dyalog APL is likely the best supported in terms of tooling, debugging etc. If you're looking for static typing, you're in the wrong place.

APL's use of 'monad' predates Haskell's existence by decades.

APL is the perfect mind blower: https://xpqz.github.io/learnapl/intro.html

It is Dyalog APL.

If you’re interested in learning APL, I wrote an intro for people coming from another language:

https://xpqz.github.io/learnapl

[reference needed]

For people discovering k for the first time, I wrote https://xpqz.github.io/kbook as a gentle intro.

I’m happy to have contributed in some small way to growing the APL community. Thanks for the shoutout.

If you are interested in learning APL, take a look at https://xpqz.github.io/learnapl/intro.html

Disclaimer: author