
Statistics with the array language Klong - nils-m-holm
http://t3x.org/klong-stat/index.html
======
tom_b
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.

~~~
nerdponx
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.

~~~
beagle3
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.

------
dTal
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.

~~~
nils-m-holm
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. :)

~~~
feelin_googley
"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.

------
jonnycomputer
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.

------
a-nikolaev
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.

