Loopless Programming

> Looping - performing a computation repeatedly - is what programs do. In most computer languages, all loops are expressed by one of two statements:

> Do While - repeat a code block until a condition is met

> For - repeat a code block, with a loop index indicating how many times the block has been repeated.

> Programmers trained on scalar languages have spent many years internalizing the Do-While and For paradigms. Discarding these paradigms is the biggest re-think they need to make when they learn J.

A lot of languages have these kinds of semantics and arguably in a more streamlined / better organised way - Haskell typeclasses for example. I don't know if it's true that 'most languages' only support for/while loops, but probably not. It also doesn't take 'many years' to internalise for/while loops, these are fairly basic constructs which are learned by most novices in the beginning of an introductory programming course.

> (x + y) is an expression rather than a statement. The J programmer can embed (x + y) in a larger expression, perhaps a matrix multiplication (w +/ . * (x + y)) which adds the equivalent of three more nested loops, but is still a single expression. Expressions can be combined; statements cannot.

(x + y) is going to be an expression in almost any language...

> Many modern languages have iterators, which slightly streamline the For loop, but without addressing its fundamental deficiencies.

What are the 'fundamental deficiencies'?

This seems like a pretty low-effort write-up.

J is APL in ASCII. My first PC was a hand-me-down from a family member who had installed APL on it and put a bunch of stickers on the keyboard for typing all the strange characters.

Where I work, we have some production code in another APL-family language, q, which is the main interface to kdb - a remarkably fast time-series database in a remarkably tiny binary, with a remarkably expensive price tag.

I think APL and its kin disprove the "Blub Paradox." Here's a language that in certain aspects is far more powerful even than Lisp, and in others falls down on tasks that are trivially simple elsewhere. And that's fine. Horses for courses.

Loops of known size is the one of the best hints you can give to your compiler though. If the computation inside the loop isn't too complicated, the compiler will unroll these, often resulting in amazing speedups. In fact if you know that your array is pretty long but don't know its size, it's often worthwhile to structure the computation as a nested loop, where the inner loop processes chunks of known length (which should be fairly short, and picked to utilize the widest SIMD on your target CPU, e.g. 8 for fp32 on most Intel chips). Then when you run out of chunks you "mop up" at the end. Furthermore, if your chunk size is a power of 2 (which it should be), don't be afraid of the modulo operator (which is normally very slow): the compiler will automatically apply the x % chunk_size == x & (chunk_size - 1) trick for you. All of the above obviously only works if chunk size is known at compile time.

> (x + y) is going to be an expression in almost any language...

But the equivalent for loop is not.

> In J we do this by creating a Boolean list, one value (0 or 1) per item of z

Does the word "creating" here mean you can't do a relatively simple check across array elements in J without allocating memory? E.g., soft realtime scheduling for such a simply operation is essentially just not possible in J?