3 ms·
> Unless everybody is born learning a language, no we don't. Even 'The one they use the most' varies over time. Nobody is born having learned a language. It's
by geocar 7y ago
> Unless everybody is born learning a language, no we don't. Even 'The one they use the most' varies over time.
Nobody is born having learned a language. It's something even babies have to learn and they know nothing!
People can even "switch" their native spoken language up to a point although it seems to get much harder as they get older and more experienced with one language, as they're constantly comparing their aptitude to their "native" one -- just as they do with programming.
> An easy use case: you're in your company and you need to do a simple script for some computation. The more readable the language you use is, the more coworkers will be able to find a bug/reuse it/modify it without requiring your help.
The decision to bring another language into a company requires different considerations for every company. The one I work for has a lot of q/k programmers, so this isn't a problem for me. I like programming in k, so it makes sense I might want to be around other k programmers.
I think if you decided to write your "simple script" in even a well-known language like JavaScript, you'd cause some grumbles in a Python+C# shop; k isn't special in this regard.
> I read more of the parent comments on that link. I didn't notice that the OP started with an unsorted dataset, you did binary search on a sorted one.
HIBP offers the data pre-sorted, so I used that. I could have used asc (actually sort) instead of `s# (an assertion that it is already sorted) if I'd used a different file, but I value my time.
> I thought that it the "kdb native format" meant more database magic that just serialization.
No. It's literally just mmap. There's a header on the file describing the array shape, and indicating that it is sorted (so bin will be accelerated), but that's it.
kdb is a database in exactly the same way that Python could be if you just pickle/unpickle everything, except it's actually fast enough that people do this, even for large data sets.
> "harmonises" in the sense that it takes one of the most common programming symbols and changes it? I don't know of anyone that sees "2 & 3 = 2" and thinks "yeah this makes sense".
If you write something like (f=42)&(g=69) you expect "&" to mean "and" here, right? Well if f is an atom, then f=42 returns either a 0b or a 1b based on whether f is 42. What if f is a vector? Well, let's see:
f:1 42 2
g:4 69 4
f=42 returns 010b and g=69 returns 010b -- do you see why? Now 010b & 010b should return 010b for the same reason that 1b & 1b should return 1b (and 1b&0b should return 0b).
"&" is just generalised from here to work the same way non-binary values. Having it convert to binary-and would be very confusing for vectors, and although I can see a consistent way it could work, I don't see the value in that operation.
- gjulianm 7y ago> Nobody is born having learned a language. It's something even babies have to learn and they know nothing! I meant a programming language (it gets confusing, sorry). But anyways, our native language is much more embedded in the brain than programming languages. > I think if you decided to write your "simple script" in even a well-known language like JavaScript, you'd cause some grumbles in a Python+C# shop; k isn't special in this regard. 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. > HIBP offers the data pre-sorted, so I used that. Yes, and that changes how you access the data. So the evaluation was not fair, as the OP was not using sorted data. > db is a database in exactly the same way that Python could be if you just pickle/unpickle everything, except it's actually fast enough that people do this, even for large data sets. That's nice, I'd actually wish Python had better serialization facilities. > f=42 returns 010b and g=69 returns 010b -- do you see why What if "f:42 1 2"? f=42 returns 100b (is that a value or a vector?) so under the common "and" definition "(f=42)&(g=69)" should return 000b, under the "less than" returns 010b?
- geocar 7y ago> 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<010b is 010b. We need something that gives us 000b and that operation is "and". Say I have a table that looks like this: 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.