I had the same concern as you regarding the readibility of APL and J. But there is a wonderful quote in an interview with Arthur Whitney (0) of kdb+ fame in relation to this:
BC To ask a slightly broader question, what is the connection between computer language and thought? To what degree does our choice of how we express software change the way we think about the problem?
AW I think it does a lot. That was the point of Ken Iverson's Turing Award paper, "Notation as a Tool of Thought." I did pure mathematics in school, but later I was a teaching assistant for a graduate course in computer algorithms. I could see that the professor was getting killed by the notation. He was trying to express the idea of different kinds of matrix inner products, saying if you have a directed graph and you're looking at connections, then you write this triple nested loop in Fortran or Algol. It took him an hour to express it. What he really wanted to show was that for a connected graph it was an or-dot-and. If it's a graph of pipe capacities, then maybe it's a plus-dot-min. If he'd had APL or K as a notation, he could have covered that in a few seconds or maybe a minute, but because of the notation he couldn't do it.
Obfuscation is not the goal of this style of programming, even though it looks like it's been deliberately golfed. Being able to express complex operations in terse but well-defined ways makes the intention clear. If you know the meaning of the primitives in +/ . * then there's little to debate that the combination is the matrix product. Whereas, if you have this operation expressible only with multiple explicit loops and intermediate variables, there are greater opportunities for error and a greater reading overhead.
I don't think J/APL are suitable for every sort of programming, and the sort of domains where J/APL excel are array-focused. J/APL's notation are a poor fit for writing a frontend single-page application (SPA), for example, and I would never want to maintain a SPA that merged all their functions into one line. I would not write complex integrals in English, and equally I would not write a medical document in mathematical notation.
But the goal of these languages is to improve the readibility of array manipulation by using composable and well-defined operations, not to obscure it. There is a large upfront cost to learning the notation, no doubt about it, and this is a necessity before you can use the language at all. But the intention is not for it to be harder to read - it's for it to be easier.
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.
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.
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.
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.
BC To ask a slightly broader question, what is the connection between computer language and thought? To what degree does our choice of how we express software change the way we think about the problem?
AW I think it does a lot. That was the point of Ken Iverson's Turing Award paper, "Notation as a Tool of Thought." I did pure mathematics in school, but later I was a teaching assistant for a graduate course in computer algorithms. I could see that the professor was getting killed by the notation. He was trying to express the idea of different kinds of matrix inner products, saying if you have a directed graph and you're looking at connections, then you write this triple nested loop in Fortran or Algol. It took him an hour to express it. What he really wanted to show was that for a connected graph it was an or-dot-and. If it's a graph of pipe capacities, then maybe it's a plus-dot-min. If he'd had APL or K as a notation, he could have covered that in a few seconds or maybe a minute, but because of the notation he couldn't do it.
Obfuscation is not the goal of this style of programming, even though it looks like it's been deliberately golfed. Being able to express complex operations in terse but well-defined ways makes the intention clear. If you know the meaning of the primitives in +/ . * then there's little to debate that the combination is the matrix product. Whereas, if you have this operation expressible only with multiple explicit loops and intermediate variables, there are greater opportunities for error and a greater reading overhead.
I don't think J/APL are suitable for every sort of programming, and the sort of domains where J/APL excel are array-focused. J/APL's notation are a poor fit for writing a frontend single-page application (SPA), for example, and I would never want to maintain a SPA that merged all their functions into one line. I would not write complex integrals in English, and equally I would not write a medical document in mathematical notation.
But the goal of these languages is to improve the readibility of array manipulation by using composable and well-defined operations, not to obscure it. There is a large upfront cost to learning the notation, no doubt about it, and this is a necessity before you can use the language at all. But the intention is not for it to be harder to read - it's for it to be easier.
(0) https://queue.acm.org/detail.cfm?id=1531242