4 ms·

Not to rain on your parade here but, in what world is a interpreter "fast and efficient"? Embeddable, minimal footprint and zero external dependencies etc are a

Not to rain on your parade here but, in what world is a interpreter "fast and efficient"? Embeddable, minimal footprint and zero external dependencies etc are all excellent real selling points here.

weberc2 8y ago
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.
- projectramo 8y ago
  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...
  - weberc2 8y ago
    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).
uryga 8y ago
IIRC, the K language's interpreter is/was really fast because it's tiny and fits in the processor's cache.
- one_thawt 8y ago
  That is generally true, but it's painfully slow for any operations that aren't vectorised or waiting on I/O.
  - textmode 8y ago
    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.
    - one_thawt 8y ago
      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.
- willtim 8y ago
  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.
  - uryga 8y ago
    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!
sctb 8y ago
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.

Not to rain on your parade here but, in what world is a interpreter "fast and efficient"? Embeddable, minimal footprint and zero external dependencies etc are all excellent real selling points here.

weberc2 8y ago

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.

projectramo 8y ago
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...
- weberc2 8y ago
  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).

uryga 8y ago

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

one_thawt 8y ago
That is generally true, but it's painfully slow for any operations that aren't vectorised or waiting on I/O.
- textmode 8y ago
  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.
  - one_thawt 8y ago
    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.
willtim 8y ago
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.
- uryga 8y ago
  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!

sctb 8y ago

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.