> I'd argue very little of what makes K and Kdb special has to do with
the language per se, but with the focus on array operations, and with the
particular runtime environment of Kdb
I'm also not convinced that K as a language is essential to kdb as an
application but it's undeniable that they have "proven themselves in the
market", eh? It's a niche, but a well-paid one, and they don't have any
competitors (with e.g. easier syntax.)
Are you familiar with arcfide's Co-dfns compiler?
https://github.com/Co-dfns/Co-dfns I ask because it might serve as a
counter-example of a "killer app" that relies on the concision of the
syntax.
> I think you need to decouple the syntax from the underlying
array-programming model. K-level terseness and the semantic structure
that makes K well suited to vector programming are pretty much entirely
orthogonal.
FWIW, I think so too. You could say that things like Numpy and Pandas are
moving towards integrated array processing, eh?
They have proven themselves in the market, but it's impossible to decouple the language agnostic benefits of KDB from K's syntax in that respect. That said, they have plenty of competitors - just most of them are just run of the mill languages.
I'm also not convinced that K as a language is essential to kdb as an application but it's undeniable that they have "proven themselves in the market", eh? It's a niche, but a well-paid one, and they don't have any competitors (with e.g. easier syntax.)
Are you familiar with arcfide's Co-dfns compiler? https://github.com/Co-dfns/Co-dfns I ask because it might serve as a counter-example of a "killer app" that relies on the concision of the syntax.
> I think you need to decouple the syntax from the underlying array-programming model. K-level terseness and the semantic structure that makes K well suited to vector programming are pretty much entirely orthogonal.
FWIW, I think so too. You could say that things like Numpy and Pandas are moving towards integrated array processing, eh?