[StreamBright]

I think we have to separate two things here.

a, array programming concepts

b, apl like syntax

I think the combination of these two makes J and co interesting. I am just not sure if the second is required. Not sure how much is lost if we use the following:

    kmc =: right (step power infinity) initialise
    initialise =: (left deal tally at right) from right
    step =: (left groupby allocate rank 1 2) then (mean every)
    allocate =: euclidean then (equal minimum) then indices then head
    euclidean =: (minus then square then sum) vectors

I totally agree with you that nested loops should not be the way to express mathematical computation over matrixes. I was just curious that we need the (for me) obfuscated syntax or we can use more of the plain English version without performance differences. After reading about J more the biggest difference between J and APL is that J is restricted to ASCII characters.

[yiyus]

> Not sure how much is lost

We lose manipulability.

I can perfectly read an expression like this:

    (a add b) multiply (a add neg b)

Even I can easily rewrite (with just a few keystrokes, if I have the right editor), into this equivalent expression:

    (square a) minus (square b)

But, when I make the conversion in my head, I see the mathematical formula. I can easily parse the English version and I can easily write it, but in my head I work with the formula, not with the words.

APL languages have a considerable number of symbols to memorize (with the exception of k, which has very few primitives, J in particular has many of them), but the core is always the same and relatively small (see the APL Dictionary, by Iverson), and many symbols are related so they are easy to remember. Nevertheless, it takes a while. Once you learn the symbols, you need to learn common idioms and constructions, which takes even more (J, with a prevalent tacit style, makes this quite difficult) but once you start getting it and can manipulate the symbolic expressions in your head, the English version does not matter any more.

There are other reasons, like keeping a large amount of the program on screen (see the videos of arcfide), but mental expression manipulation is what convinced me.

[paliilap]

I take your point that these are two separate concerns, and we do certainly see a) without b) with Numpy, Julia, Matlab, R and the like. Using these languages is a very productive experience, and I agree that a) is definitely the main driver.

With J and APL, one pragmatic benefit I do see of the symbols over the words is the ability to see and use patterns if one is familiar with the language. This is harder to do with the words, which spread concepts thinner. I think Iverson expresses these ideas very nicely in Notation as a Tool of Thought.

The APL/J/K family strongly assume that readers of the language are familiar with their parsing and semantics, so idiomatic usage of each language makes no concessions for what is felt to be unnecessary. It's a different mindset for sure. When the users of the language share an understanding of what the symbols mean though, they no longer think it's obfuscated.

J takes such strong inspiration from English (to the point that it calls functions "verbs", operators "adverbs" and "conjunctions", and arrays "nouns"), that I once thought J would be better written entirely as English words instead. After having made such attempts, I actually found it harder to read and maintain the English versions. I couldn't attach strict behaviour and meaning to the words like I could with the special symbols. Perhaps I didn't entertain this idea long enough, but the words felt considerably less malleable.

[StreamBright]

I see your point, the ability of taking in symbols that are used in math as they are (quite often Greek alphabet letters) makes the syntax more familiar to people who are in this field.

That is interesting that you have this experience with maintaining the two versions. I guess I should try it out as well.