K: We need to talk about group (opens in new tab)

And with regards to hotkeys, let's say you do Ctrl+alt+shift+esc+e to insert a unicode symbol, is that really better than just having a programming language where the common hotkeys are spelled out with a few ASCII characters?

- k has much fewer primitives. it's easier to remember a smaller set of operations.

- k is statically parsable. APL is not. we know the program structure simply by reading the code.

this is completely subjective. because you find APL more intuitive doesn't prove anything. to each their own.

Yeah, I’d love to discuss with colleagues how square-c works together with right double crowbar.

No, thanks.

eg, instead of "echo yo >> file" you would "echo yo ≥ file"

https://mlochbaum.github.io/BQN/

In the Raku Programming Language there are several non-ASCII operators, although each of them has a pure ASCII equivalent. Some examples: ≤ vs <=, ≠ vs !=, ∈ vs (elem), etc.

The full list: https://docs.raku.org/language/unicode_ascii.html

Part of those two days of commenting was that since K is interpreted all of the developers would hand-obfuscate all of the code so that the variables were a, b, c, etc. so that they would be slightly faster to parse than a multi-character string. This sort of thing is done all the time now, with JS to make it load faster, but his team at least didn't have any scripts to automatically turn developer-friendly code into interpreter-friendly code, they worked with the interpreter-friendly code version.

mine was matlab. thinking of everything as an array, especially things that aren't arrays, was the first pattern I ever learned. I've never used APL in anger but for the most part it comes very easily to me. Maybe not the code golfing and/or idiomatic APL style that people like to post but, like, using the primitives to create increasingly elaborate arrays before discarding anything I don't want, that part has always felt very straight forward.

I think the right intuition for APL-family languages is that they mostly do numpy-like operations except their set of operations tend to compose very nicely. So the idea is that one can quickly and interactively figure out a composition of the operations which will do the calculation you want, but you don’t have a complicated compiler and spend most of your time in the operators rather than the interpreted language, and the operators tend to make the cpu happy – they work on contiguous memory, tend to be vectorized, don’t branch unpredictably, etc – so even if you have to compose many steps, you win on the time to write and the time to execute can be hard to beat because the constant factors of each individual operation are good.

For obvious reasons, things like numpy, pandas, dplyr, etc are more popular as their syntax is a bit more readable and it is easier to get data in/out. I think they do lose a bit by not having lots of the useful compostable APL-style operators because those things don’t have comprehensible names.

https://en.wikipedia.org/wiki/Gather/scatter_(vector_address...

My maths notebook from high school looked like that. I'm having flashbacks. (At least in text files you can't cram 4 lines of text into 1.)