[Paul-Craft]

Lol, yes! That language looks like it was optimized for code golfing or something.

[Avshalom]

It was optimized for interactive use by people that already know it.

[whalesalad]

have you ever wanted to hand write minified javascript? boy have i got the tool for you.

want an ip address as an integer?

    .z.a
    -1062731737i

what about TLS connection status?

    0N!h".z.e";
    `CIPHER`PROTOCOL!`AES128-GCM-SHA256`TLSV1.2

absolutely beautiful language

[TeMPOraL]

Which is a nice target to have. Makes me want to learn the language.

Modern tech is so obsessed with high-turnover, sale-by-first-impression user growth toy software mindset, that it completely forgot about the idea of creating and optimizing tools for people who use those tools day in, day out.

[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))