4 ms·

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

by NOGDP 7y ago

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.

inimino 7y ago
You seem to have missed the point of the original remark that (x + y) is a statement, and you're missing the point of my clarification. > "(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.
- DougBTX 7y ago
  J has a big focus on array manipulation, the libraries in Rust for arrays provide implementations of the Add trait, so I’d disagreed that it is not “idiomatic” https://docs.rs/ndarray/0.13.0/ndarray/struct.ArrayBase.html#impl-Add%3CB%3E https://docs.rs/ndarray/0.13.0/ndarray/struct.ArrayBase.html...
  - inimino 7y ago
    Well yes, but ndarray is a library, which is what I said. You certainly don't get this "for free" in the language, which means you aren't forced to think this way as a beginner in the language, which is why libraries like ndarray generally have a learning curve, in whatever language you find them. In J you have to get over that learning curve much earlier, because, as you said, the language is focused on it. (Which is the point the article is making, about how J changes the way you think. If you were writing an article about how Rust changes the way you think, I don't think you'd mention ndarray.)
- theamk 7y ago
  I can tell you that at least in Python, for loops are not common for math. In fact, if I saw a C-style for loop counting indices, I’d defect it in any code I review. For simple things, you have list comprehensions and things like “sum”, while for complex things one should reach for numpy.
  - misterdoubt 7y ago
    A list comprehension is still a for loop. Using `for x in list` instead of `for i in len(list)` is a nice bit of sugar, but still a for loop. That said, high-performance Python does generally discourage the use of loops in favor of vectorised operations.
    - deleted 7y ago
      [deleted]
    - brudgers 7y ago
      I agree Python list comprehensions have loop semantics. But in fairness, a list comprehension in Python is an expression not a statement. Maybe it's best to think of Python's list comprehensions as loops with an implicit return.
- NOGDP 7y ago
  > 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. 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 http://arma.sourceforge.net/docs.html#part_classes [2] http://hackage.haskell.org/package/linear http://hackage.haskell.org/package/linear [3] https://www.jsoftware.com/docs/help701/dictionary/ctrl.htm https://www.jsoftware.com/docs/help701/dictionary/ctrl.htm
  - inimino 7y ago
    > This seems like a pretty low-effort write-up. 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?

by NOGDP 7y ago

inimino 7y ago

You seem to have missed the point of the original remark that (x + y) is a statement, and you're missing the point of my clarification. > "(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.

DougBTX 7y ago
J has a big focus on array manipulation, the libraries in Rust for arrays provide implementations of the Add trait, so I’d disagreed that it is not “idiomatic” https://docs.rs/ndarray/0.13.0/ndarray/struct.ArrayBase.html#impl-Add%3CB%3E https://docs.rs/ndarray/0.13.0/ndarray/struct.ArrayBase.html...
- inimino 7y ago
  Well yes, but ndarray is a library, which is what I said. You certainly don't get this "for free" in the language, which means you aren't forced to think this way as a beginner in the language, which is why libraries like ndarray generally have a learning curve, in whatever language you find them. In J you have to get over that learning curve much earlier, because, as you said, the language is focused on it. (Which is the point the article is making, about how J changes the way you think. If you were writing an article about how Rust changes the way you think, I don't think you'd mention ndarray.)
theamk 7y ago
I can tell you that at least in Python, for loops are not common for math. In fact, if I saw a C-style for loop counting indices, I’d defect it in any code I review. For simple things, you have list comprehensions and things like “sum”, while for complex things one should reach for numpy.
- misterdoubt 7y ago
  A list comprehension is still a for loop. Using `for x in list` instead of `for i in len(list)` is a nice bit of sugar, but still a for loop. That said, high-performance Python does generally discourage the use of loops in favor of vectorised operations.
  - deleted 7y ago
    [deleted]
  - brudgers 7y ago
    I agree Python list comprehensions have loop semantics. But in fairness, a list comprehension in Python is an expression not a statement. Maybe it's best to think of Python's list comprehensions as loops with an implicit return.
NOGDP 7y ago
> 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. 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 http://arma.sourceforge.net/docs.html#part_classes [2] http://hackage.haskell.org/package/linear http://hackage.haskell.org/package/linear [3] https://www.jsoftware.com/docs/help701/dictionary/ctrl.htm https://www.jsoftware.com/docs/help701/dictionary/ctrl.htm
- inimino 7y ago
  > This seems like a pretty low-effort write-up. 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?