1. 18
  1.  

  2. 3

    k would be a lot more popular if good documentation were available…the only comprehensive documentation available is a technically-not-redistributable PDF that you have to find by Googling around that documents a 20+ year old version that doesn’t exist anymore.

    There’s some Shakti documentation at github.com/kparc but it’s no longer in sync with what Shakti actually provides and is very unofficial.

    (To stave off the inevitable “write it yourself!” argument: (a) I’m by no means an expert and (b) it’s a moving target right now.)

    1. 1

      Wow, that makes a lot of sense. I ended up learning J over K simply because K documentation seems to be scattered to the wind, and everything I managed to find was for a different version of K. It doesn’t help that there is another language named K for SMT modeling, which actually has a tutorial.

      1. 1

        I would recommend J. It has much better documentations and has the full source code GPL’ed, except for the actual database part, Jd. Though some motivated people could implement their own Jd.

        1. 1

          Sure, I’m having fun with J so far. It’s not bad at all. I think it’s unfair to compare the quality of documentation though.

          For instance, one thing I’ve never figured out how to do with J is how to use dictionaries (aka associative lists aka records). K has always had them built-in. Meanwhile the J mailing lists are filled with debates and hand-wringing over the lack of dictionaries.

          I’m pretty sure J requires you to define your own equivalents of get and set. I think get is get =: >@(}."1@] {~ {."1@] i. <@[), which I can’t say I’m fond of. I can’t imagine for the life of me what set would look like.