Yes; the CBQN interpreter has a number of specialised vectorised codepaths. It picks a good one for the arrays at runtime.

In K the arguments are named x y z by default, so you just write:

    { foo[x, bar] }

Looks like K to me!

> I didn't understand how this connects to the first paragraph at first, but I think you're saying this playthrough is an analog to someone making such documentation, thus saving DF from such a fate?

(Not OP) Possibly, but one of the repeated themes in Boatmurdered is a number of fortress defenses (some with considerable collateral damage) attached to a variety of scattered and unmarked levers.

Does pulling this lever lower the drawbridge, irrigate the fields, or douse the world in cleansing magma? Only one way to tell!

> For character-based movement, simply press 'z' to enter the column mode.

I did eventually find this in the documentation, under the "regexp selections" section. I think it should be more prominently displayed in other sections, since it's a natural thing to want (at first).

I am enjoying the editor (as a current helix user), and looking forward to trying it more.

In this respect, probably nothing, and they probably all mean Q.

Q is a different language to K, implemented in K. There are more versions of K than Q- kdb+ is the only Q implementation, but there are others like shakti, ngn/k, and kona that implement K.

Or indeed just results*:2

It returns it for 404 as well: https://http.cat/does/not/exist

I don't want to do the same things for boolean operations, or arithmetic, or pointer (de-)referencing in C like languages. Why would I want to do so when equally familiar with a larger range of symbolic operations?

Somehow the usual culprits of +-/*|^&% get a free pass on this, and are somehow less arcane than symbols like ⍋ or ⊃.

There's nothing inherent about this, it's about familiarity, and once familiar, everyone always prefers the symbols over spelling it out like plus, minus, divide, multiply...

It’s funny because lisp enthusiasts will say “yes, lisp is harder to learn with all the parentheses, but trust me, it’s worth it” And then list some actual benefits.

Whereas APL fans will insist it’s not hard while listing no benefits besides dense code.

well yeah, dense code is the whole argument. It means you don't have to know any library, because it's so dense you can just write the whole thing from basic elements. You never have to look up anything!*

* except for the fact you're supposed to remember the idioms for everything : https://aplwiki.com/wiki/FinnAPL_idiom_library

The usual culprits show up on standard keyboards. That’s a huge advantage.

The lack of familiarity was exactly my point? If you make a new language with a + symbol but spelled out the other functions, newcomers would understand it immediately. If you have whatever that Christmas tree symbol is, newcomers will be continuously looking up what they mean. You are making the language harder to learn for the sake of code golf.

And if you had a toggle-able mode, you could still have your code golf.

For what is worth, you can use the keywords 'and', 'or', 'xor' etc. in C an C++ like you can in python. I for one greatly prefer them.

I'm solving in BQN, and my workflow is repeatedly re-phrasing a line until it does what I want in the repl, and then naming it, and then moving on.

Most often I end up with some enormous one-liner that I then break down into functions again.