> 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 runt

> 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 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?