[yiyus]

I want to like J, but I find that most of my programs get too cluttered with @: all over the place. I see the k-means example shown here has a similar problem (7 usages of @: in only 4 lines of J). I find implicit programming a more elegant paradigm, but lambdas with pre-declared argument names (like x,y,z in k or α and ω in Dyalog APL) more comfortable to work with (and, at least for the time being, more productive).

I think part of the reason is that J's syntax for function composition is too heavy. In an improved visualization of J like the one shown here, I would find very interesting to try something like, for example, composition by simple juxtaposition and trains with under(or over)lining, maybe even playing with colors to indicate if verbs form a train or other composition. I understand that is a quite different problem from just substituting @: with o̲.

Nevertheless, very nice work. It is interesting to see the English and APL versions next to each other. The video is also very good.

[stepvhen]

> maybe even playing with colors to indicate if verbs form a train or other composition. I understand that is a quite different problem from just substituting @: with o̲.

With regards to how different of a problem that would be, J's syntax is context-sensitive. If you were to accurately identify trains and forks, you could not use regex, and would probably end up implementing a subset of the J parser.

[rscho]

J has a first-class citizen self tokenizer in the standard lib as a dedicated state machine ( ;: ) https://www.jsoftware.com/help/dictionary/d332.htm

For an example of a very incomplete and largely suboptimal parser that uses the above: https://github.com/Rscho314/J-compiler/blob/master/ast.ijs

[6thaccount2]

Charles Moore did that with Color Forth and even though only he was using it, I remember several comments on how that is unfair to the color blind or visually impaired which is an interesting point.

[yiyus]

ColorForth has a color-blind mode, but I do not remember the details.

The main idea is to change visual representation instead of using delimiters. Different fonts or text sizes sizes or cursive/inverse/underline are also valid ways of displaying different "colors".

[6thaccount2]

Yes I remember that reply which came from him, but forgot to mention. It is an interesting idea.

[StreamBright]

For me the biggest question is: how much do you gain by not using proper function names and just jamming all you function definitions into these write once read never sort of functions? Is there really a practical gain?

[paliilap]

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.

(0) https://queue.acm.org/detail.cfm?id=1531242

[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.