A consequence of this is that the language has many severe limits. For example, number of function parameters, number of local variables, amount of code inside a conditional branch etc. Working around these limits can often feel like being a human-compiler.

To be honest I just repeated back stuff I read about K, as I haven't gotten into K enough to hit these limits. Commentary from someone with actual experience is great, thanks!

That is generally true, but it's painfully slow for any operations that aren't vectorised or waiting on I/O.

Is this comment suggesting it is slower than other languages for those operations? If so, which languages? How much slower? Recommended tests?

Is it possible that mandating vectorised solutions and avoiding I/O were in fact design goals of the author?

Not disputing the comment. Looking for more details.

k/q/kdb+ are often touted as having C speed, and the architecture of the interpreter is always cited. In my experience raw performance can be compared to python (or R) for iterative work and numpy for vectorised workloads.

It is an array language and focused on storage and numerical processing of large vector oriented datasets. Its speed as a general programming language is overrated and we often offloaded things to C.

I personally love APL derived languages, but its mystique has fostered a lot of hype.

A simple example, write a for loop with dependent data flow. There is not much optimization.