And here's another demo, showing the creation of a voronoi diagram from points. This might better illustrate how one can use iKe to iteratively develop programs: https://i.imgur.com/7JNU2r3.gif
The primary page linked to would be improved it linked to any kind of documentation like what you've mentioned. I followed the link, saw a pretty much blank page and left.
I think a link to the Readme.md might be more useful because it explains in detail what it is, why you might find it useful, and how to use it. The Readme.md contains a link to the sandbox fairly early on, but the sandbox doesn‘t seem to provide an easy way to get to the documentation (language info, API info, etc).
k doesn't have any valuable documentation to begin with, so language info wouldn't be much better than what you could get by doing a WWW search. The best way to learn is by doing, and the examples are really well commented.
My take: I don't think this is an issue. "What it is" is a sandbox for graphical K programs, which is already provided in the title. Given that K is already rather niche, and sandboxes are meant for playing with rather than general use programming, it seems like this toy isn't targeted towards a general audience and has no obligation to explain itself further than "K in your browser".
And apple is a horrible name for a computer because you may find fruit, amazon fire will give you trees in flames, and word, office, windows... It is difficult to find things when you do not know what you are searching for.
I really like the K language after reading through the ok tutorial listed below.
I just wish there was a free and open source K engine written in C that would work on Windows or Linux. I've tried J, but I think I like K much better. Ok and Kona don't seem to be production worthy (performance or correctness I would guess). I like the concept of a tiny interpreter though with no install (kinda what Kona has for Windows, but better supported).
At the end of the day, that's the immovable object. A free, open-source, high-performance interpreter for K would get cease-and-desist-ed into oblivion by virtue of competing with the commercial implementation. That's why I made mine a toy: fun to tinker with, but not fast enough to give anybody ideas. Kinda sucks, huh?
There's an AGPL k that works on Linux (ngn's), but not one that works on Windows. "Production-ready" is a misnomer for this, though; if you want production-ready k, just buy it from atw.
Every time I see one of these array-processing languages, I'm always baffled at how small you can make the code, but then am further baffled and wonder how anyone is able to read/debug it.
To people here who know APL/J/K rather well, does it become second-nature and easy to find mistakes?
My experience is only with J, but I imagine it carries over to APL and K as well.
The code ends up reading a lot like an algebraic sentence after a while:
x (1/u + 1/v) = x/(uv) (u - v).
Spot the error?
Once you are familiar enough with the orthography that the symbols dissapear and you see the concepts, once you have some familiarity with the common ways these concepts interact, then J/APL tend to feel refreshingly clear in their expressiveness.
This is similar to how an algebraic equation feels a lot clearer than its rendition into "more readable" prose. Take the above equation and contrast it with this:
The sum of two inverses, when scaled by some factor, equals the difference between the two reverted numbers, scaled by the quotient of the original factor with the product of the reversions.
You start to see "idioms" in the code. Common ways of doing things. You learn that taking the first element of a reverse of a list is the last element, per se. Like any language, with experience it becomes very easy to read.
And here's another demo, showing the creation of a voronoi diagram from points. This might better illustrate how one can use iKe to iteratively develop programs: https://i.imgur.com/7JNU2r3.gif