[jodrellblank]

Dyalog clicks a lot more than J; "the best syntax"? "Easiest to learn"? Can you expand more on these positions?

And "a lot of the modern additions Dyalog has made to the language make it (in my opinion) worse as a notation" this one. I don't know when you mean modern but as a casual user, {} functions, trains, nest ⊆, rank adjustment ⍤ (like J), seem to make things more convenient?

[kick]

"the best syntax"

Yes, absolutely. By a long shot. For starters, J can actually be parsed. (k can also be parsed, for what it's worth.)

"Easiest to learn"?

Spend ten minutes using J's built-in Labs feature. Or read J for C Programmers (also ships with the language), if you come from a non-array background. Iverson was able to teach this stuff to public school children in no time at all; modern array languages seem to deliberately make themselves obtuse to outside observers. APL was doomed to obscurity because the people making it decided to please existing customers rather than try and make it approachable.

I don't know when you mean modern

Pretty much every APL2 feature and everything that came after it that they didn't borrow from J.

While J has English control statements, they generally aren't used, but nearly every time I come across something written in Dyalog APL it's full of :If :EndIf and all sorts of atrocious English words which mock the ideal of a better notation than ALGOL.

[mlochbaum]

> J can actually be parsed

Don't know where you got that one. J source can't even be tokenized except during execution!

  NB. Compute n from reading a file of something
  n : 0
    Is this the source of a function, or a string?
  )

Besides that, J has the same contextful issues as APL with regards to the value of variables determining how the syntax fits together. It's missing a few dark corners like niladic functions, but these are small differences; it's still fundamentally unparseable.

[rscho]

Regarding that, I am surprised that a 'more limited APL' lacking this ambiguity and opening the way to easy compilation never appeared (to my knowledge). I essentially use J for data wrangling and pretty much never use the metaprogramming features of the language (". and the like). An 'APL NumPy' would be quite nice, IMO.

[beagle3]

K can be parsed. Even Q (the English version of K) can be parsed if you consider the prelude a part of the language (rather than part of the runtime environment).

[rscho]

An area that's still pretty different between J and APL (IMO) is that ⋄ makes APL much easier for procedural programming while J is easier for functional code. As a result, I (a journeyman in J and beginner in APL) tend to procedural much more in APL. I also get this impression from APLcart where ⋄ and ← are not at all uncommon. Of course, you can do that with J also using [x=. A second area of difference is that J is arguably more math-oriented, which is ironic considering the origins of APL, but I mean look at the primitives! J's 'higher-math' primitives are really useful for preparing datasets.

Also, I'm mainly doing preparatory data wrangling with J (i.e. quick&dirty work) and not having to activate the APL keys everytime is a nice feature. The ability to write a simple #! script and dispensing with the 'APL machine' of workspaces also counts (a feature that just appeared in APL). As a data wrangler though, the true killer feature of J is Jd, the integrated columnar store. Of course you can mmap through it all in APL, but having a completely integrated solution does the trick for me! Actually, I find the concept of 'fetch your data SQLish and model it with J' such a good idea that I'm playing with the idea of extending the concept to the Racket data science world (which is mostly non-existant) :-)

So if you're doing serious programming as done in Fortune 500 companies I'm pretty sure APL wins due to consistency and tooling integration, but for one-off work J is a killer!