> our native language is much more embedded in the brain than programming languages.
I think it's possible that might have more to do with the fact we use "our native language" more.
> Yes. And I'd cause even more grumbles if it was written in Haskell, and even more if it was on K. That's the point.
I don't know. I work in a place with a lot of q/k programmers, so this isn't a problem I face.
> Yes, and that changes how you access the data. So the evaluation was not fair, as the OP was not using sorted data.
You're mistaken. They did use sorted data, they just didn't know about the presorted file so they also wrote code to sort it.
> is 100b a value or a vector?
It's a vector of three elements (bits: zeros or ones).
> What if "f:42 1 2"? f=42 returns 100b … so under the common "and" definition "(f=42)&(g=69)" should return 000b
Yes that's right, and q/k would return 000b in that case.
> under the "less than" returns 010b?
100b
f g k
--------
10 9 kf
20 8 je
42 69 kf
42 0 lk
That's written like this:
t:+`f`g`k!(10 20 42 42;9 8 69 0;`kf`je`kf`lk);
k has tables as a data type. You can think of them as a list of dictionaries if you want:
q)a:`f`g`k!(10;9;`kf);
q)b:`f`g`k!(20;8;`je);
q)c:`f`g`k!(42;69;`kf);
q)d:`f`g`k!(42;0;`lf);
q)(a;b;c;d)
f g k
--------
10 9 kf
20 8 je
42 69 kf
42 0 lf
but I only do this to reinforce the idea this is a basic data type in k.
I can write t.f=42 and get 0011b and t.g=69 and get 0010b. I can do queries like this:
q)select from t where (f=42)&(g=69)
and that's basically the same as this:
t@&:(t.f=42)&(t.g=69)
+`f`g`k!(,42;,69;,`en)
(&: is "where" and not to be confused with &)
And from there it should be clear why we need this "and" behaviour. The question is what should a&b do when they're not bit vectors that would be compatible with this behaviour? 42&69 should return 42 because it's the lesser; 0b&1b returns 0b because it's the lesser... Mathematics is already quite comfortable with the relationship between logical-and and min, so this has a precedent.