Unlike other concatenative languages, the order of operation is right to left, and it supports infix operators. This gives the language a very conventional array language feel, while also giving you the power and flexibility of the stack.

As far as I'm aware, there's really nothing like it. Would love if someone gave it a try!

Here's an example, the factorial function:

  xs> fac:(prod 1+til);
  xs> fac 4
  0: 24

  xs> add:{+.};
  xs> 3 add 2
  0: 5

  xs> (x:;x%2) fixes 12
  0: [12 6 3 1 0]

for boosting popularity:

1- would be nice to use in tryit online or repl.it

2- would be nice to have a link to the implementation repo in the docs

3- have you tried winning some golfscript contests on stack overflow?

4- main improvements over K, with small code samples?

I hadn't heard of golfscript, but those would make some really great examples. I do have a couple Advent of Code 2019 solutions though.

Thanks!

off topic, is it just me? Or a thing informed by silly memes to see this letter and immediately think oh man, Rest in Peace?!

The name of this site is "nsl" for No Stinking Loops.

Here is an array programming challenge for the K programmers reading this thread.

There are two large files A and B.

   File A
   AAAbjhOJxxxWXrCHt
   AAAsofxxxLqKbYOAwLMHG
   AAACgxxxOea
   AAAwfHjDtoJc
   AAAiCfYnbVXWhuvtEx
   AAAkzzQwvf
   AAAdjLalKFapoYAcGE
   AAAthGazmnfK
   etc.

   File B
   AAAwfHjDtoJc
   AAAbjhOJxxxWXrCHt
   AAAiCfYnbVXWhuvtEx
   AAACgxxxOea
   AAAkzzQwvf
   etc.

What are the lines in B that are not in A?

Something like

   grep -vf B A

EDIT: File A,B formatting

    echo@> (2{ARGV) -.&([: <;._1 LF, 1!:1) (3{ARGV)
    NB.    2nd arg                          3rd arg
    NB.              g&f execute f for each, then g on both
    NB.                              1!:1 read file
    NB.                          LF, prepend newline
    NB.                 [: <;._1 split based on first char
    NB.             -.  remove right elements from left array
    NB. echo@> echo each line
    exit 0

    $ time j9 -c ./pseudo_grep.ijs test_b test_a
    …
    real   0m0.064s
    user   0m0.032s
    sys    0m0.017s
    $ time grep -vf test_b test_a
    …
    real   0m5.815s
    user   0m5.234s
    sys    0m0.576s

    set(open('file_b')) - set(open('file_a'))

    real    0m0.128s
    user    0m0.078s
    sys     0m0.063s

I did not know that. Assumed you had to somehow wrap them first. Very useful, thanks!

In my simple test, that resulting in grep running in 44% of the prior amount of time it required (still more than python though).

I tested with files just over 2 MB on a small Digital Ocean VM. Depending on disk speed, based on running time I suspect you ran on files at least an order of magnitude larger. What time did python run in for those? Seeing memory usage from time might be illuminating for these tasks too. Using 4x the disk size in memory is fine for a couple MB file, but less so for a couple GB file (in which case creating a bloom filter or trie might be better, but I really have no idea if Pythons set functions do that already).

          A←⊃⎕nget 'C:\test\a.txt' 1
          B←⊃⎕nget 'C:\test\b.txt' 1
          A~B
    ┌─────────────────────┬──────────────────┬────────────┐
    │AAAsofxxxLqKbYOAwLMHG│AAAdjLalKFapoYAcGE│AAAthGazmnfK│
    └─────────────────────┴──────────────────┴────────────┘

If the components of your company's system never are longer than a page or two of code, rewrites become trivial, making planning for the future unnecessary. This is the real promise and value of array languages.

Or put more simply, the size of a code base is the dominant factor in its complexity. Less code is less complex code, is better code.

Also, loops imply mutation, which is the second biggest indicator of complexity. Mutation kills code bases and kills projects. When you decide to never use a loop and to never mutate, you're on the right path. Now the next step is to try and remove as many lines of code as humanly possible.

A good way to measure how you're doing is by comparing the size of your gzipped (or zipped or whatever) codebase to its uncompressed form. If they are close in size, you know you are on the right track. Or in other words, you want the size of your code base to be close to its Kolmogorov complexity.

What about someone who thinks "if" is a big source of software complexity? https://www.youtube.com/watch?v=z43bmaMwagI - talk is "If considered harmful: How to eradicate 95% of all your bugs in one simple step - Jules May".

[1] in interpreted languages, anything you can push down for the runtime to do instead of writing that same code in the interpreted language, tends to execute faster. e.g. my_string.count('c') in Python compared to a `for` loop over the characters written in Python.

For that sort of comparison I usually use

   diff -y A B

    comm -13 A B

   echo AAA_not_in_A_xxx >> B

   fgrep -vf A B

    AAA_not_in_B_xxx

    A_B

     `A 0: ("some";"lines";"are";"here");     / write to file A
     `B 0: ("more";"lines";"follow";"here");  / write to file B
     _/ 0:' `A`B                              / read files A, B and find lines of B that are not in A
    more  
    follow

Can someone ELI5 what this is about, why it's interesting, and why someone would want to learn or use this language?

(I'm coming from the perspective of someone who builds user-facing web & mobile applications in Ruby, Crystal, Python, JavaScript, Swift, etc.)

BTW - I'm asking not because I doubt there are good answers to any of those questions - but because I truly don't understand and wish to.

I read the opening paragraph and without spending an hour looking up the definition of each term, I'm more confused than when I started :)

Thank you in advance!

You're working in a very different space (business oriented, needs networking protocols, probably no major number crunching, your collection of languages do fine for your job etc.)

Some languages are just explorations of the language space, disjoint from your language-using space therefore irrelevant to you directly, and may be (currently) only of academic interest. I'd learn this if I had time, to understand different paradigms, and for fun. Sometimes this is useful. Sometimes not.

http://www.nsl.com/k/f/

(via comments from 2015)

Yet it prints stuff to the terminal.

> Expecting a wide use of neural network algorithms in the near future, our objective is to get a complete software development environment for programming and testing new applications. We intend to produce a high level language for neural network specification, as a part of such an environment.

> The language we propose is characterized by a high degree of modularity, based on parameterizable data structures, with functionalities in the form of update methods attached to them. Composition rules of structures and methods enable to build, step by step, more complex structures from smaller ones previously defined. Objects are viewed as autonomous modules which are linked through plugs for communications. We particularly cared for the parallelization of methods running concurrently on different objects of the network. The syntax is largely related to those of the C and C++ languages.

https://link.springer.com/chapter/10.1007/978-3-642-76153-9_...

M omits the language also known as MUMPS, and also there was a second .Net based language informally called M#, apparently developed by Microsoft Research as part of Midori project, and called "C# for Systems Programming" in public communications from the developers.