by callinyouin on 12/12/17, 6:03 PM with 150 comments
by petermora on 12/13/17, 7:41 AM
However, I couldn't get used to Q. I understand that it is fast, and I also started to like the functional programming aspect of it. But oh boy, there is no proper error messages (no, "`type" is not helpful). The short versions of various map and apply were handy, but there are no equivalent versions with longer names, therefore there is no way to write a code which is readable to a non Q-expert. The strange evaluation order made it impossible for me to read other people's code, I often started to add parentheses and checked whether the behavior changed. There is no debugger (I used KdbStudio). Once I used more than 16 local variables, which gave a runtime error with some strange unhelpful error message.
I'm not questioning its usefulness, but I think that it could be much more developer friendly without compromising speed.
by beaumayns on 12/13/17, 1:44 AM
* If your code doesn't spend most of its time in primitive verbs operating on large vectors, it's gonna be more or less as slow as any other interpreted language. Q and kdb+ can be fast and beautiful if you can arrange your problem in the right way, but it's not magic.
* The internals are locked away. If you don't like the way something fundamental works, tough. I've known some folks to go to heroic lengths with debuggers and hacked up shared objects to get Q to do what they want. You could also get Kx to add the stuff you need (they're pretty reasonable and responsive). But, you can't really take it apart and put it back together again like you can with, say, Lua, Ruby, or Python.
* Relating to the above point, one of the weaknesses of the language is that there are a lot of useful (even necessary) features packed into weird corners. There's little room for abstractions beyond the basics, so you get stuff like CSV parsing controlled by the structure of lists passed to a function called "0:". It's getting better documented lately, but it's still not pretty.
* Various annoyances (no real module system, no lexical scoping, etc...)
In many of those cases, I'm not even sure what could be done without compromising some other aspect of the language. Most of the time (at least for me), it's really a joy to use.
by jonathanapp on 12/12/17, 6:54 PM
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 'scales')
by noblethrasher on 12/12/17, 6:51 PM
by dasmoth on 12/12/17, 6:36 PM
(Some context: http://archive.vector.org.uk/art10501320)
by nz on 12/12/17, 8:29 PM
by is0tope on 12/13/17, 1:16 AM
The columnar structure of the DB as well as its IPC layer make it very good at creating chains of processes that can be used to stream row updates and branch them out to different processes with different responsibilities. Likewise it's on disk database is great for running complex (time series) queries.
This speed and terseness comes at a cost of being fairly "old school" in its approach. It's only recently for instance the we got stack traces, and readability is definitely not for the faint of heart though this depends on how it is written.
In my view the biggest thing that is needed right now is better tooling and libraries. Some attempts have been made to do this, and I am hearing that the new initiatives by kx will be addressing this in the coming months. The lack of standardized testing library/framework also can be problematic, as every team that I have seen does it slightly differently, and a "best practice" would beneficial.
by SifJar on 12/12/17, 7:40 PM
Another useful intro to the language
by kuwze on 12/12/17, 7:57 PM
by anonfunction on 12/12/17, 11:27 PM
life:{3=a-x*4=a:2(sum -1 0 1 rotate\:,’/)/x}by aamederen on 12/12/17, 9:19 PM
by anonu on 12/13/17, 4:03 PM
1. adding more syntactic sugar to the language to improve readability
2. open-sourcing the thing or building an open-source compatible Q interpreter with all the nice features of KDB (functional programming, vector-based data structures, "scripting language within a database" approach, web features: HTTP server and websockets, etc.. etc.. )
by cousin_it on 12/13/17, 3:39 PM
by pyvpx on 12/12/17, 7:52 PM
by amypinka on 12/12/17, 6:49 PM
by fiatjaf on 12/12/17, 7:00 PM
by modeless on 12/12/17, 9:27 PM
// remove more clutter
#define O printf
#define R return
#define Z static
#define P(x,y) {if(x)R(y);}
#define U(x) P(!(x),0)
#define SW switch
#define CS(n,x) case n:x;break;
Or this wall of code:
by feelin_googley on 12/12/17, 8:22 PM
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.
by tree_of_item on 12/12/17, 10:54 PM
Smaller Code, Better Code: https://news.ycombinator.com/item?id=13565743
AMA: Explaining my 750 line compiler+runtime designed to GPU self-host APL: https://news.ycombinator.com/item?id=13797797
by http-teapot on 12/12/17, 6:57 PM
(I am not certain if my comment follows HN's guidelines, apologies if I offended anyone)
by human_afterall on 12/12/17, 9:51 PM
by johnhenry on 12/12/17, 8:59 PM
by scottyelich on 12/12/17, 7:47 PM
The license already changed once (for the worse, IMnsHO), so what's to say that won't happen again. Too risky to touch.
No, can't use it (32bit version) for commercial, so this is a non-starter. Sorry.
kOS? really? https://news.ycombinator.com/item?id=8475809