Well, it’s not hard to beat Python and Ruby and PHP these days; I wouldn’t be surprised if this were quite a lot faster than those languages (or at least the reference implementations).

EDIT: Do downvoters think I’m wrong? Mine isn’t really a contentious point of view—-Python and Ruby and PHP have a lot of features that make optimization difficult. Python pays my bills, so please don’t interpret my remarks as language smugness.

I didn't downvote you but you waded into a holy war.

The main charge that python and ruby launch at each other is that the other is slow, then it doesn't matter because server costs are cheaper than human costs, then something about time to maintain and add features are the true costs and so on.

So when you mention anything about those languages being slow, and someone just walked out of a four day internet dispute on reddit...

Lol, thanks for the explanation. Usually the Python people just say, "Yeah, Python is slow; just write the hotpath in C", which is somewhat disingenuous but they aren't exactly denying that Python is slow (which is why I assumed my point of view was pretty garden-variety).

We've reverted the title from the submitted “Gravity: a fast and efficient programming language” to what the main page actually claims. Submitters: please don't editorialize.

IIRC, the K language's interpreter is/was really fast because it's tiny and fits in the processor's cache.

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.