Statistics with the array language Klong | Hacker News Reader

Statistics with the array language Klong

t3x.org

33 pointsnils-m-holm12 comments

Despite only occasionally hacking around with array programming languages, I have always enjoyed the terse syntax. But I admittedly find weird syntax somewhat engaging.

I have wondered what was happening with statistics in the larger group of array languages. Do other HN readers know of J, Q/KDB+, Klong, or others in use by teams outside of the normal financial folks using Q/KDB+? I'd be quite interested in hearing any stories from the business world where it isn't a "lone hacker" situation, but rather even a small group of programmers were using array languages in production situations.

The terse syntax is totally off-putting to most people and it makes it a hard sell at work or to a research group. I suspect the only reason it found a niche in quant finance is that those guys are geniuses and can kinda do whatever the hell they want. They also don't have to share their code all that often AFAIK.

There's also no reason for it. Heck, you could even give each function an alias, write a "verbose language", and have it compile to the short form before being processed further. Then you could even write both long-form and short-form, and interleave the two if you really wanted.

Q is exactly that for K. Almost everyone switched from Q to K sooner or later, because once you grok the ideas, the verbosity gets in the way of both reading and writing.

There's also kerf, which is verbose; AFAIK it was not met was the same success that APL, J or K have -- though likely for unrelated reasons.

Dammit, another array language with cryptic syntax. It seems to be an unfortunate side effect of APL's custom character set that all languages inspired by it adopt the terse notation, minus the elegant symbology that made it work in the first place.

The only array language I've ever found that bucks this tendency is Nial, with the result that it's an extremely fun language to play around in, if impractical due to its ancient interpreter. J claims to have English synonyms for everything, but only as second-class citizens (no working interpreter support). Numpy, sadly, is probably the closest thing.

It's a shame because I think it's holding the paradigm back.

It's only cryptic until you get used to it! I, for my part, would not want to go back to anything else after having used terse syntax for a while, even if it was not linked to the array paradigm.

Of course, the syntax requires a different way of reading/writing code. It is a bit like reading a math book versus reading a novel. In a novel, you can skim over a few sentences or paragraphs, in a math book you get lost when you do this. Personally, I think this is a feature. :)

"Personally, I think this is a feature."

That is how I see it.

The more terse the better.

If there is a downside to APL-inspired language interpreters, it is that too many are closed source.

Kerf also uses keywords, I believe.

It isn't holding the paradigm back. I do not have time to repeat the examples I often give, but a short analogy might help:

'I think mathematics is being held back because people write cryptic syntax like "xx + 2x + 1 == 0" instead of the easily readable "multiply your unknown by itself, then add twice that very same unknown, and finally add 1 -- the result you get should be zero; that's the constraint satisfied by the very same unknown"; it's a shame'

There is very little difference. The reason it seems like the cryptic syntax is the problem is because that's the first thing you see -- but it's just the top of the iceberg. The problem is that most people don't grok the paradigm regardless of the syntax; and the very few which do grok the paradigm but don't grok the syntax are not enough to get rid of the syntax, which has significant symbiosis with the paradigm (much like Leibniz's differential notation is symbiotic with the ideas, much more so that Newton's "simpler to use" one)

The "cryptic syntax" of math was an organic outgrowth over hundreds of years by researchers from all over the world.

And yes, long and complicated mathematical expressions are cryptic. That's why you often see constants being combined and equations being re-expressed in "simpler" terms, even when those terms are themselves relatively complicated functions. It's partly about conceptual abstraction, but it's also about visual clarity. Math can get very, very hard to read.

> Math can get very, very hard to read.

That's exactly my point: Math gets hard to read, but it's because of the math, not because of the notation.

When new notation simplifies things, and is quickly adopted by practitioners - e.g. Einstein's tensor notation. I am not aware of a single case in history where a more verbose notation was preferred to a terse notation in mathematics - except perhaps in the case of Leibniz' notation for calculus, which is slightly more verbose than Newton's but it address a significantly larger set of concepts, and does so with regularity and orthogonality.

I don't know these others, but I love Matlab (for its intended use-case of course). I'm fortunate enough to have it as part of my job. I do wish that it was less clunky in how it accommodates functional programming styles.

If you wonder what the license is, it is Public Domain:

Klong A Simple Array Language By Nils M Holm, 2015--2017

Nobody owns this code. It's in the public domain or whatever you call it.

Disclaimer, just in case:

THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Reply on news.ycombinator.com