|
It's brilliant language, and all, but I don't buy it. Here's why: 1) languages with this high level of abstraction are very nice if your scenario maps perfectly to its usage (e.g. the wikipedia analysis given in the video). Everything is nicely vectorizable, etc. But if there is some quirk in your data, then sometimes you need to go the usual way, and the Q is of no help (no better than any other language), with the difference that now you do some very inefficient things with those "stinky" loops. 2) it's a question of taste, but I find Q syntax a bit unusual. Probably more time you need to think how to fix your simple problems with this clever one-liners than simply, well solving them... 3) legibility: for all of us working in software developement, we know how much time we waste due to illegible code. Finding bugs, etc. Here this is raised to the new level... of difficulty 4) this is a bit exaggerated, but I don't see how I could use Q in something bigger? Is Q only a scripting languages for one-off mini-batch programs? For instance R has this problem of not having any well-defined project structure, and it is hard to do many things, for instance: bigger programs are hard to maintain and debug, stream processing with R is pain in the ass. Server-side stuff is a little bit shoehorned (Shiny server is cool, but then it's just one-thread thing for serving filtered dataframes to ggplots) It is cool niche language, but for smart simple analyses, nothing too complex, as it will abstract you from details to your loss. |
I had previously built similar games using other technologies, but found developing in q to be far faster, even given the more primitive debugging capabilities.
I understand that this is a relatively small example, but building it was enough to convince me the APL/k/q approach is useful beyond its supposed niche.