It is wherever '+'/(equivalent function) overloading is a thing - C++, Haskell, Rust, etc. There isn't even a good reason to think of it as a loop, because for different types it may not be a loop at all.
> "(x + y) is an expression rather than a statement".
The point isn't that (x + y) wouldn't be a statement in other languages, rather than point is that in languages the reader of the article is most likely to be familiar with, you would use a for loop to solve the problem, and obviously a for loop is a statement, not an expression. You can't compose statements as you can expressions. That was the only point the article was making there.
You clearly missed it, because you went on saying that (x + y) is an expression in almost any language, which while true, is irrelevant for languages where (x + y) isn't the way you would express the operation in question. Which, by the way, includes idiomatic C++, Haskell, and Rust, in all of which overloading (+) to do something so specific would at best be seen in a purpose-specific library (like numpy) only, but isn't automatically present in the language. That means it doesn't force you to think in that way, which J does, which is the point the article is making.
In most languages that most programmers use, for loops are common, and if all of those are replaced by expressions, you get a more expressive language (for dealing with arrays). That's the point that the article is making, and you haven't addressed it at all.
For simple things, you have list comprehensions and things like “sum”, while for complex things one should reach for numpy.
That said, high-performance Python does generally discourage the use of loops in favor of vectorised operations.
No, in other languages you would write one function that specifies how to perform an operation per type, then reuse that, and most linear algebra/numerical libraries come with these defined for you. In languages without polymorphism, such as C, you might have special names for these functions instead, such as vector_add. The actual use of these would look like '(x + y)' in Haskell, Rust, C++, etc. and 'vector_add(x, y)' in C, and would (or at least could) be expressions.
> . Which, by the way, includes idiomatic C++, Haskell, and Rust, in all of which overloading (+) to do something so specific would at best be seen in a purpose-specific library (like numpy) only, but isn't automatically present in the language.
Linear Algebra types/functions aren't automatically present in most languages. A library can be implemented to use this syntax to add vectors/matrices/whatever very easily, and many are [1][2]. Even if the library doesn't use '+' as the operator for eg. vector addition, it could, and it chooses to not use '+', but that is not very important.
> In most languages that most programmers use, for loops are common, and if all of those are replaced by expressions, you get a more expressive language (for dealing with arrays).
I'm not sure what you mean by 'more expressive'? Maybe you prefer a more declarative/functional programming style but for loops have their place in imperative languages. J doesn't actually force you to write all of you code in that style - the language has constructs that can be used to construct loops that look like imperative C [3].
> That's the point that the article is making, and you haven't addressed it at all.
The features described in this article are equivalent to a library implemented on top of Haskell, Rust, C++. The usage of such a library would even look almost exactly the same.
[1] http://arma.sourceforge.net/docs.html#part_classes [2] http://hackage.haskell.org/package/linear [3] https://www.jsoftware.com/docs/help701/dictionary/ctrl.htm
You're not the audience for the article and that's what this entire thread shows. You missed the fact that you were not the audience, and that makes this a low-effort dismissal. Rather than trying to get the point of the article, you're picking on minutiae and trying to pick it apart. This is why we can't have nice discussions about programming languages.
The audience for the article is: people using, learning, or interested in J, who want to know how to think about loops in a "loopless" way, which the language encourages. The fact that you're talking about linear algebra libraries shows that you're not the audience the article is written for.
None of your points are wrong, in some cases you are literally restating my points, but you're not getting the emphasis. Rather than try to prove the article wrong, why not try to see it for what it is, and who it is aimed for, and leave it at that?
> J's approach to iteration is vastly better than other languages.
Those are opinions.
> not well written
That's yours.
Opinions and claims are not mutually exclusive.
> That's yours.
Yup, thanks.