what makes kdb so special and why isn't there an open/libre alternative?
see here:
21–30 of 161 posts
what makes kdb so special and why isn't there an open/libre alternative?
see here:
Notes from my KX/kdb experience: 1.) The in-memory DB .exe was around 500 KB. Imagine that. 2.) The Q language syntax, while consistent, is fairly arcane and throwback to decades past. 3.) The documentation and driver support is abysmal. 4.) It's supposedly extremely fast, but I can't help but wonder if this is a lot of successful PR and hype (like hedge fund bosses insisting on Oracle because it's the only db that '…
Based on that experience...
1) Yes, but that's not huge by modern standard.
2) Q is a DSL version of K. As others have commented, K is a pretty clean implementation of APL, and Q makes K more approachable.
3) I have to agree here, but Q for Mortals makes up for it.
4) It is really fast. As we all know, a vast majority of us actually don't have terabytes and terabytes of data, especially after a reasonably cleanup / ETL / applying common sense. I suppose it helped that I worked in finance, which meant my desktop had 16GB of memory in 2009 and 128GB of memory on a server shared by 4-5 traders.
Finally, Q was never intended for general-purpose computing nor a widespread adoption. At least when I was an active user, the mailing list had the same 20-30 people asking questions and 3-4 people answering them, including a@kx.com (= Arthur Whitney, the creator). Back then, I'd say there were at most 2-3k active users of Q/K in the world. Now that Kx Systems is part of First Derivative and has been working on expanding their customer base, perhaps they have more...?
what makes kdb so special and why isn't there an open/libre alternative?
Not only that, it is the only software I have ever seen that used a GUI and then ditched it in a subsequent version.
Few programs are so aligned with my own software sensibilities.
Only complaint is that they used to have a FreeBSD port and now only have Linux and macOS but no BSD.
Unfortunately Linux compat in BSD is being perceived by some as a potential security issue these days.
what makes kdb so special and why isn't there an open/libre alternative?
There’s an open source impl of an earlier version of K: https://kona.github.io/#/ There’s also a JS implementation that aims to implement K6: http://johnearnest.github.io/ok/index.html I don’t believe either implement all the “database” side of kdb+ though. Edit: The J language is similar in some respects, and is GPLed. They've also got a columnar database... http://www.jsoftware.com/jdhelp/overview.html
This is only software I have ever seen that actually got smaller over time. Not only that, it is the only software I have ever seen that used a GUI and then ditched it in a subsequent version. Few programs are so aligned with my own software sensibilities. Only complaint is that they used to have a FreeBSD port and now only have Linux and macOS but no BSD. Unfortunately Linux compat in BSD is being perceived by some…
I agree, this is admirable!
Even if it is under different names (which I think is a far better approach), Sustrik does this too: http://250bpm.com/blog:50 He went from AMPQ (not his own creation) -> ZeroMQ -> nanomsg -> Libmill (essentially Go in C/UNIX style)
Also, OpenBSD comes to mind (LibreSSL for example).
Notes from my KX/kdb experience: 1.) The in-memory DB .exe was around 500 KB. Imagine that. 2.) The Q language syntax, while consistent, is fairly arcane and throwback to decades past. 3.) The documentation and driver support is abysmal. 4.) It's supposedly extremely fast, but I can't help but wonder if this is a lot of successful PR and hype (like hedge fund bosses insisting on Oracle because it's the only db that '…
I used to use KX/kdb/Q/K daily for several years. I wrote a full implementation of reinforcement learning (15 lines), a lightweight MVC framework (to show reports and tables in an internal webapp) and even a Q syntax checker (abusing table as a data structure to hold parse trees). Good or bad, for the longest time, Q was my "go-to" programming language. Based on that experience... 1) Yes, but that's not huge by moder…
OP could have phrased it better, but I presume his point was that 500KB is extremely small by modern standards. The whole executable fits comfortably in L3, so you'll probably never have a full cache miss for instructions. On the other hand, while it's cool that it's small, I'm not sure that binary size is a good proxy for performance. Instruction cache misses are rarely going to be a limiting factor.
what makes kdb so special and why isn't there an open/libre alternative?
k variants:
kona (C, interpreter): https://github.com/kevinlawler/kona
klong (C, interpreter): http://t3x.org/klong/
kuc (C++, JITted): http://althenia.net/kuc
oK (JS, interpreter): https://github.com/JohnEarnest/ok (see also iKe by John Earnest)
cousins:
J (C, interpreter) http://jsoftware.com/
A+ (C, interpreter, unmaintained): http://www.aplusdev.org/index.html
Gnu APL (C, interpreter): https://www.gnu.org/software/apl/
apl.js (JS, interpreter): https://github.com/ngn/apl
There's also NARS2000 and a few other APL interpreters
related:
Numpy and R provide similar functionality, albeit with more verbose (and less fluent) composability. They are usually slower.