GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-12-12) - page 1 of 10
 
___________________________________________________________________
The Q Language
126 points by callinyouin
https://code.kx.com/q/tutorials/startingq/language/
___________________________________________________________________
 
fiatjaf - 3 hours ago
What is this?
 
  amypinka - 3 hours ago
  Documentation for kdb+/q. MS had a posting for their new Q#
  language today on HN so that might have inspired someone to post
  this.
 
modeless - 1 hours ago
The KDB code is terse to an unhealthy extreme. Check this gem:
// 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;
https://github.com/KxSystems/kdb/blob/master/c/c/k.h#L96Or this
wall of code:https://github.com/KxSystems/kdb/blob/master/c/c.cs
 
  kolme - 1 hours ago
  Welp, you were not kidding:
  https://github.com/KxSystems/kdb/blob/master/c/c/curl.cThis code
  is basically obfuscated by hand. Absolutely unapproachable. Only
  the original author(s) can understand it.Judging by other
  comments, it seems to work well. So they seem to be good
  programmers producing working code. It's just not intelligible by
  other human beings, which is a pretty bad thing, but not the only
  factor in software quality/health.The Vim code base is at some
  parts straight batshit insane, but it's one of the most polished
  programs I've ever used.All that being said, I would find
  infuriating to work with such code. Nope!
 
    beagle3 - 53 minutes ago
    It takes time getting used to, yes.And it is not for all
    people.But it's just a foreign language; You could look at
    Japanese text[0] and make similar statements, and would be just
    as valid (or rather, invalid) as your statement.You expect to
    be able to read it because you're used to a class of languages
    which are all similar enough at the surface level -- perhaps
    you are even familiar with more than one fundamentally
    different classes, say, "lispish and algolish" or "germanic and
    latin". But that doesn't make APLish or Japanese[0]
    horrible.This is just APL using C syntax.[0] assuming, the
    proverbial you does not know Japanese
 
      IshKebab - 44 minutes ago
      APL isn't really readable by other humans either.This is
      idiotic.
 
      [deleted]
 
    kazinator - 35 minutes ago
    I don't see where this code is getting a definition for K. (The
    return type of the ctype function).It's not in the "k.h"
    header, though that references it also.Maybe the build system
    injects it through the compiler command line or a forced-
    include header. Though the gcc command line alluded to in the
    block comment header shows no evidence of that.Edit: Found it!
    It's a typedef for a pointer to a struct k0:  typedef struct
    k0{signed char m,a,t;C u;I r;union{G g;H h;I i;J j;E e;F f;S
    s;struct k0*k;struct{J n;G G0[1];};};}*K;
 
  geocar - 1 hours ago
  I'm a vocal convert.This approach helps me find bugs and
  repetition in my programs which makes my code shorter and faster
  as a result.
 
    IshKebab - 48 minutes ago
    You're joking right?
 
    modeless - 23 minutes ago
    I can see the argument for terseness. In fact I loathe how
    verbose Java is, I try to minimize LOC, and I enjoy using ?:.
    However, I don't think it's a good idea to use this extreme
    single-character, single-line style in languages not designed
    for it. If you really want this style, you should use APL or
    design your own language.
 
      tree_of_item - 12 minutes ago
      They are using APL. This style is used in APL/J/K/etc
      implementations as well as the languages themselves.
 
      kazinator - 9 minutes ago
      Basically, this really wants to be using a custom
      preprocessor for a cleaner notation.
 
  [deleted]
 
  alexeiz - 1 hours ago
  It's so terse, it's gotta be fast!
 
johnhenry - 2 hours ago
Not directly related, but Microsoft just released a new language
for developing quantum languages, Q#, which doesn't seem to be
related at all. I hope this doesn't cause too much confusion.
 
kuwze - 3 hours ago
On github kiyoto worked on this project[0] to help others
understand Q code.[0]: https://github.com/kiyoto/ungod
 
nz - 2 hours ago
Found this illuminating interview with Arthur in the ACM queue:
http://queue.acm.org/detail.cfm?id=1531242
 
dasmoth - 4 hours ago
Aside: has anyone heard any recent news about the K5/K6 rewrites of
the underlying interpreter?  There was a fair amount of chatter
about these a couple of years ago, but all gone rather
quiet...(Some context: http://archive.vector.org.uk/art10501320)
 
  RodgerTheGreat - 1 hours ago
  Currently it looks like k7 is going to be an actual commercial
  product in the near-ish future. Arthur is still hashing the
  details out, but the language design is substantially similar to
  k6. If anyone ideas or strong opinions about how to make k7
  better, now would be a pretty good time to email Arthur.For those
  not already in the loop with respect to k6, the reference card
  (http://kparc.com/k.txt) provides a good overview. Note that it
  is neither exhaustive nor completely representative of the
  current state of the language.
 
tree_of_item - 5 minutes ago
More APL threads for anyone interested:Smaller Code, Better Code:
https://news.ycombinator.com/item?id=13565743AMA: Explaining my 750
line compiler+runtime designed to GPU self-host APL:
https://news.ycombinator.com/item?id=13797797
 
amypinka - 4 hours ago
The next time you buy some stock, thank the Q language for making
it happen.
 
SifJar - 3 hours ago
https://learnxinyminutes.com/docs/kdb+/Another useful intro to the
language
 
noblethrasher - 4 hours ago
Q was the subject of an awesome presentation by Tim Thornton at
YOW! Lambda Jam 2016.[1]
https://www.youtube.com/watch?v=ZGIPmC6wi7E
 
  geocar - 1 hours ago
  His description of primality testing in that video is really
  quite good[1]. If it starts too slow, maybe that's a good place
  to start?[1]: https://youtu.be/ZGIPmC6wi7E?t=9m56s
 
jonathanapp - 4 hours ago
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 'scales')
 
  _acme - 3 hours ago
  Hedge funds would be the ones to use kdb over Oracle, wouldn't
  they?
 
  flukus - 16 minutes ago
  Any other downsides? Management has been convinced and we're
  apparently switching to it at work soon but there is so little
  information and most of that is marketing, so it's hard to get an
  idea of what we're walking into.
 
  geocar - 3 hours ago
  > 1) The in-memory DB .exe was around 500 KB. Imagine thatIt
  still is, but the hot path is much smaller than that.> 2) The Q
  language syntax, while consistent, is fairly arcane and throwback
  to decades past.I can't comment about this. I don't mind the
  syntax. I prefer k syntax though.> 3) The documentation and
  driver support is abysmal.This is getting a lot better. The
  fusion API[1] goes a long way towards better "drivers", and the
  new documentation site[2] shows a lot of energy being put into
  organization. There's also Q for mortals[3] which is linearized
  for people who like that.[1]:
  http://code.kx.com/q/interfaces/fusion/[2]:
  http://code.kx.com/q/[3]: http://code.kx.com/q4m3/preface/> 4)
  It's supposedly extremely fast, but I can't help but wonder if
  this is a lot of successful PR and hypeThere are a lot of good
  benchmarks of kdb[4] unlike Oracle :)[4]:
  https://stacresearch.com/m3
 
  amypinka - 3 hours ago
  Seems plenty fast to me:
  http://tech.marksblogg.com/benchmarks.html
 
  tluyben2 - 3 hours ago
  2) I like K better (fitting the ideals of APL); I feel Q was done
  by Arthur to please some big client as it doesn't feel like he
  would choose that kind of thing (that's from reading interviews,
  seeing the iterations and his basic code philosophy)
 
  ktamura - 2 hours ago
  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 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...?
 
    nkurz - 2 hours ago
    1) Yes, but that's not huge by modern standard.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.
 
      beagle3 - 59 minutes ago
      > Instruction cache misses are rarely going to be a limiting
      factor.k's performance is a combination of a lot of small
      things, each one independently doesn't seem to be that
      meaningful. And yet, the combination screams.The main
      interpreter core, for example, used to be <16K code and fit
      entirely within the I-cache; that means bytecode dispatch was
      essentially never re-fetched or re-decoded to micro
      instructions, and all the speculative execution predictors
      have a super high hit rate.When Python switched the
      interpreter loop from a switch to a threaded one, for
      example, they got ~20% speedup[0]; I wouldn't be surprised if
      the fitting entirely within the I-cache (which K did and
      Python didn't at the time) gives another 20% speedup.[0]
      https://bugs.python.org/issue4753
 
    hpcjoe - 1 hours ago
    It is worth pointing out that really fast is ... well ...
    really fast.  See [1] for some benchmarks they did for small,
    medium, large data sets.The machines that $dayjob-1 used to
    build dominated the STAC-M3 for a few years (2013-2015) because
    we paid careful attention to how kdb liked to work, and how
    users liked to structure their shards.  Our IO engine was built
    to handle that exceptionally well, so, not only did in-memory
    operations roar, the out of memory streaming from disk ops
    positively screamed on our units (and whimpered on others).I
    miss those days to some degree.  Was kind of fun to have a set
    of insanely fast boxen to work with.[1]
    http://kparc.com/q4/readme.txt
 
    oskarth - 1 hours ago
    Would be really interesting to read a write up on your
    experience. What do you program in now? How do you look at
    other PLs now? What do you miss and what are you happy "just
    works"? What do you think other PLs (especially languages like
    Lisp, which are very high in terseness) can learn from Q?
 
aamederen - 1 hours ago
As an outsider, my initial reaction is "does every new database
system have to come up with their own SQL-like language?"
 
  beagle3 - 1 hours ago
  SQL's only virtue is that it is well known; It is otherwise not
  very good compared to other query languages, and every SQL engine
  extends it somewhat differently, extensions which you can't avoid
  cause the standard is too limited. I agree most query languages
  would be better off as minor extensions to SQL - but kdb+/Q is
  different.Unlike SQL which pays lip service to Codd's relational
  model but breaks it with things like TOP, ORDER BY, LIMIT and
  others, the Q language embraces the order between tuples to great
  effect, making e.g. "as-of" queries which are quite common
  trivial; whereas in SQL and the relational model, as-of queries
  are inefficient in either execution time or storage space
  (usually both), and reasonable execution speed schemas cannot, in
  fact, guarantee their integrity (which is often quoted as one of
  the the main advantages of the relational model).As another
  example, Q implements "foreign key chasing" also called
  "reference chasing", which is also implemented in the web2py DAL
  and surely others; compare[0] the equivalent tpc-h query:in q:
  select revenue avg supplier.nation=`BRAZIL by order.date.year
  from lineitem     where order.customer.nation.region=`AMERICA,
  order.date.year in 1995 1996, part.type=`STEEL  in sql:   select
  o_year,sum(case when nation = 'BRAZIL' then revenue else 0
  end)/sum(revenue) as mkt_share    from(select year(o_orderdate)
  as o_year,revenue,n2.n_name as nation     from
  part,supplier,lineitem,orders,customer,nation n1,nation n2,region
  where p_partkey = l_partkey and s_suppkey = l_suppkey and
  l_orderkey = o_orderkey      and o_custkey = c_custkey and
  c_nationkey = n1.n_nationkey      and n1.n_regionkey =
  r_regionkey and r_name = 'AMERICA' and s_nationkey =
  n2.n_nationkey      and o_orderdate between date('1995-01-01')
  and date('1996-12-31') and p_type = 'STEEL')      as all_nations
  group by o_year order by o_year;  [0] bottom of
  http://kparc.com/d.txt
 
scottyelich - 3 hours ago
... and can you use the 32bit version in commercial use?  (Last I
checked, no...)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
 
  beagle3 - 1 hours ago
  You can purchase a license if you want to be unaffected by future
  license changes. It might not be the right price for you, but it
  is for some. They are, in fact, courting only rich customers.Some
  languages are worth learning to expand your horizons. Lisp is one
  of them, even if you never use it, and the APL family (of which
  K/Q are members) is another. My C code has become faster,
  simpler, shorter and less buggy after I dabbled in K. YMMV, but
  using it in a commercial setting is not the only reason to look
  at it.> kOS? really?
  https://news.ycombinator.com/item?id=8475809Really. What exactly
  is your "really?" question?
 
    vram22 - 40 minutes ago
    >My C code has become faster, simpler, shorter and less buggy
    after I dabbled in K.Interesting. Can you explain why you think
    that has happened?
 
human_afterall - 1 hours ago
For a second I thought you meant Q# - got pretty excited there :)
 
http-teapot - 4 hours ago
Imagine being French and having to explain you code in Q.(I am not
certain if my comment follows HN's guidelines, apologies if I
offended anyone)
 
  atrudeau - 3 hours ago
  Or the query execution plan: Plan Q
 
  xamuel - 3 hours ago
  The French got their revenge by giving us Coq
 
pyvpx - 3 hours ago
what makes kdb so special and why isn't there an open/libre
alternative?
 
  JadeNB - 3 hours ago
  > what makes kdb so special and why isn't there an open/libre
  alternative?Maybe I'm reading too much into this, but it seems
  like you expect the answer "nothing much" to the first part of
  your question.  I have done nothing more than read lots of
  articles on KDB's lineage and play around a bit with J, so take
  my answer with a considerable lump of salt, but my impression is
  that the answer to the second part of your question is "because
  there's something 'so special' about KDB"; my understanding is
  that it provides blazing-fast access to memory-compact databases,
  from a tiny codebase, building on the APL/J legacy.  Why can't
  this be done in an open sourced way?  Well, surely there's no
  inherent reason, but the fact that it hasn't been is probably
  evidence that it's not just a problem of trivially cloning
  existing work (or else someone would have done it).
 
  dasmoth - 3 hours ago
  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.htmlI
  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
 
    ColanR - 2 hours ago
    I'm not aware that kona is working on the speed aspects of K,
    though, which seems like one of the major reasons to use K.
 
  pgtan - 2 hours ago
  > why isn't there an open/libre alternative?see
  here:http://t3x.org/klong/
 
  beagle3 - 1 hours ago
  But there are:k variants:kona (C, interpreter):
  https://github.com/kevinlawler/konaklong (C, interpreter):
  http://t3x.org/klong/kuc (C++, JITted): http://althenia.net/kucoK
  (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.htmlGnu APL (C, interpreter):
  https://www.gnu.org/software/apl/apl.js (JS, interpreter):
  https://github.com/ngn/aplThere's also NARS2000 and a few other
  APL interpretersrelated:Numpy and R provide similar
  functionality, albeit with more verbose (and less fluent)
  composability. They are usually slower.
 
  coliveira - 2 hours ago
  J language is also an open source APL-derivative and offers
  similar features.
 
feelin_googley - 2 hours ago
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 as a potential security issue these
days.
 
  oskarth - 2 hours ago
  > This is only software I have ever seen that actually got
  smaller over time.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).
 
    beagle3 - 1 hours ago
    Libmill/Libdill (go coroutines) are not on the
    AMPQ->ZeroMQ->Crossroads->Nanomsg (socket abstraction) path ;
    in fact, they have essentially nothing in common except
    sustrik.
 
      oskarth - 1 hours ago
      I wish you'd actually read the article before shooting your
      mouth off with a Well Actually. FTA:> Next one: nanomsg. An
      alternative to ZeroMQ.In comments:> How would you split
      nanomsg, then?> [...] 2. coroutine library, e.g. libtask,
      libmill [...]Not to mention that this is obvious if you
      understand what the core of each thing is in terms of
      capabilities. If you are gonna be the "technically..." guy,
      at least do it right.It's about decomposing things, which is
      the essence of good design, and - supposedly - the UNIX
      philosophy at its heart.
 
        beagle3 - 1 hours ago
        As an actual user of ZeroMQ, nanomsg and dabbler of
        libdill, I assure you I know what I am talking about.
        Libdill/libmill is NOT on the same arch. It could be used
        to implement the next generation of zeromq/nanomsg, but it
        does not, in fact, provide any functionality that these
        provide today - it would be an internal implementation
        detail if sustrik followed through on that comment. But it
        would not be a nanomsg rewrite, likely something completely
        new - nanomsg has been rewritten, several times in several
        ways, by Garret D'amore who has taken over. D'amore
        explicitly rejected using e.g. libuv (mentioned in that
        comment) as a basis for a nanomsg rewrite. There's an
        "uncertainty" principle at work here - separating of
        concerns generates dependencies which in the grand scheme
        of things are not necessarily good.In fact, one of
        D'amore's rewrites used native OS threads in lieu of a co-
        routine library, which worked perfectly well on FreeBSD and
        Solaris, and abysmally on all other OSses. The main reason
        to use a coroutine library in a messaging library is
        actually that the underlying OS threads implementations
        scale so badly on most modern systems.