Are there any?
Are there any lower-level operators hidden from Q namespace in K namespace?
Thanks.
Are there any reasons to write something in K today (not in Q)?
Anyone?
As far as I understand, there was a period when Q was non existing, and only K existed, that’s why we sometimes see people today preferring K.
Why I am asking this: should I learn K deep enough to find something in it (from optimisation point of view) which is not in Q?
I like K brevity, comma instead of enlist, etc etc, but apart from that, what are benefits of K?
learning k or q is a lot of fun. As q and k compile to the same byte-code, there’s little to be gained by writing in k vs q. Some users coming from other languages find q more approachable than k, so this might influence your choice too.
We document and support q.
hth,
Charlie
Thanks for answer.
p.s. i agree about fun.
As far as I understand it, q is simply syntactical sugar on top of k. You can see what your q code translates to under the hood in k by just entering the q function.
For example,
q)each
k){x’y}
q)peach
k){x’:y}
q)ungroup
k){$[#x:0!x;,/+:'x;x]}
Given that q is much easier to read and write, I don’t see any strong argument for using k. There is also very little documentation on k so it’s not easy to learn either.