-
There's a niche out there where this kind of technology is appreciated. I can even appreciate the technical challenges in making an array language interpreter run fast!
However, unfortunately, the notation is so terse that I can't imagine spending the time to learn this. This looks write-only.
Is there an obvious reason to prefer a k-like language like Klong, over e.g. Futhark[0] or Accelerate[1]?
[0]: https://futhark-lang.org/
[1]: https://hackage.haskell.org/package/accelerate
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
I understand the appeal of array languages — they provide very convenient shortcuts to common loop operations in traditional scalar language. Their usefulness is manifest in the popularity of NumPy (and its derivatives, e.g. TensorFlow, PyTorch, JAX, etc.), MATLAB, Julia, R, and other Iverson Ghosts [0]. The rise of map/reduce/filter operations in common scalar programming languages is also testament to array languages' usefulness.
I can understand (though do not personally agree with) the appeal of extreme terseness — there are arguments to be made that maximizing information density minimizes context switching, since it reduces the amount of scrolling. Personally, I find that the rise of large displays and split buffers mitigates this issue, whereas the mental overhead of using my short-term memory to map of dozens of single letter variables to semantic definitions is much higher than having to flip between splits/marks in my text editor. (The fact that the aforementioned Iverson Ghost languages are popular whereas APL and its derivatives are not is evidence that I'm aligned with most people in this regard.)
I don't understand why people rarely make the terseness argument for non-array languages, even though it's just as easy to write tersely in them — the Obfuscated C Competition is a prime example [1]. Is it just due to the influence of APL, or is there something special about array languages that gives them a unique proclivity for terseness?
[0] https://dev.to/bakerjd99/numpy-another-iverson-ghost-9mc
[1] https://www.ioccc.org, https://github.com/ioccc-src/winner/blob/master/2020/ferguso...
-
I understand the appeal of array languages — they provide very convenient shortcuts to common loop operations in traditional scalar language. Their usefulness is manifest in the popularity of NumPy (and its derivatives, e.g. TensorFlow, PyTorch, JAX, etc.), MATLAB, Julia, R, and other Iverson Ghosts [0]. The rise of map/reduce/filter operations in common scalar programming languages is also testament to array languages' usefulness.
I can understand (though do not personally agree with) the appeal of extreme terseness — there are arguments to be made that maximizing information density minimizes context switching, since it reduces the amount of scrolling. Personally, I find that the rise of large displays and split buffers mitigates this issue, whereas the mental overhead of using my short-term memory to map of dozens of single letter variables to semantic definitions is much higher than having to flip between splits/marks in my text editor. (The fact that the aforementioned Iverson Ghost languages are popular whereas APL and its derivatives are not is evidence that I'm aligned with most people in this regard.)
I don't understand why people rarely make the terseness argument for non-array languages, even though it's just as easy to write tersely in them — the Obfuscated C Competition is a prime example [1]. Is it just due to the influence of APL, or is there something special about array languages that gives them a unique proclivity for terseness?
[0] https://dev.to/bakerjd99/numpy-another-iverson-ghost-9mc
[1] https://www.ioccc.org, https://github.com/ioccc-src/winner/blob/master/2020/ferguso...
