[giraffe_lady]

No it didn't come on. Languages and libraries are still written by developers, who make tools based on their experiences and preferences using tools. A dense tersely named standard library is simply not pleasant to use for most people, and so most people won't develop one for themselves or others to use.

Something that's easy to understand on a first impression is easy to understand on every subsequent impression as well. At least in terms of languages and libs no one is optimizing for that first impression, it's just a byproduct of making it easy to use in all cases.

[Jorge1o1]

As a daily user of kdb+/q, I can say that at least for me, it's one of the "best feeling" and most ergonomic tools i've ever used.

I can actually query and understand tables in a very fast REPL in a way that would require 20-30 lines of SQL, nested subqueries, etc.

Even things like the way "left joins" work in KDB feels more natural than left joins in other SQL databases. https://code.kx.com/q/ref/lj/

[rsrsrs86]

I second that. It feels like an abacus after a while

[orhmeh09]

Interesting. This syntax reminds me a bit of the R package data.table's terseness for joins:

  B[A, on="x"] # A left join B
  B[A] # same, assuming x is the key column on both, like K's lj [x;y]
  A[B, on=.(x, y<=foo)] # right non-equi join

[nivertech]

That's because kdb tables are much more similar to R dataframes (ordered maps of vectors), rather than to relational algebra used in RDBMS/SQL (logically sets of rows). That's for in-memory only (RDB), ignoring historical data (HDB) and persistence since kdb is a real database.

  // kdb+/q
  t: ([] sym:`AAPL`IBM`GOOG; price: 139.09 124.23 948.82; vol: 123456 98765 54321)

  # R
  df <- data.frame(sym=c("AAPL", "IBM", "GOOG"), price=c(139.09, 124.23, 948.82), vol=c(123456, 98765, 54321))