5 ms·

J has no operator precedence, and evaluates from right to left. Pretty easy to get used to.

by moeris 5y ago

civilized 5y ago
It's interesting what people find easy and hard. I find infix operators and their standard mathematical precedence rules perfectly intuitive. Equally good are the extended precedence rules of languages like R, which were designed by professional users of mathematics. I hate reading S-expressions and reverse polish notation. To me, proposals that we write in those notations are like saying that we should write assembly code. I think "No, we have compilers so that humans can write human-readable code rather than being forced to cater to the machine."
- beagle3 5y ago
  I do too, and it's fine as long as you (a) have a relatively small number of operators, and (b) use one language, or several that have conforming precedence. Does "<<" in C have the same precedence as "shl" in Pascal? How does it compare to multiplication, of which it is (essentially) a specialization? Does a<b<c in C mean what it does in Math? What about Python? When I learned APL (and J and K), the first instinctive response to the lack of operator precedence was wtf? -- all same precedence, all "right associative" / "right to left" / "left of right" / "long right scope" (same meaning, different terms). But after using it for a day, I realized all the other programming languages have it wrong. Math notation gets a pass because you handwrite it, so a set of rules that minimizes writing does make sense. Not so for programming languages. APL/J/K have tens, perhaps even a hundred, operators -- so there isn't really any other practical way. But it just works so well, that it puts the Algol/C/Pascal decision to copy math in an unfavorable light.
rak1507 5y ago
Came here to say something similar. This is the best option, and I would like this in every other language. Totally avoids any ambiguity at all.
- patrec 5y ago
  This is just untrue. You can't even parse J without knowing if something is an "adverb" or a "verb".
  - abrudz 5y ago
    But the modern APL, BQN lets you directly see the syntax from the symbol or name: https://mlochbaum.github.io/BQN/doc/context.html#bqns-spelling-system https://mlochbaum.github.io/BQN/doc/context.html#bqns-spelli...
    - patrec 5y ago
      Thanks that's interesting! They however kept what I consider J/APL's main syntactic misfeature, overloading the meaning of every symbol in pretty arbitrary ways depending on whether it is called with one or two arguments. E.g. *: x " x squared y *: x " NAND of x and y At least it made it to the Problems with BQN page ;) https://mlochbaum.github.io/BQN/commentary/problems.html#incoherent-monad-dyad-builtin-pairs https://mlochbaum.github.io/BQN/commentary/problems.html#inc...
  - rak1507 5y ago
    That has nothing to do with RTL 'operator' precedence. Ok, sure, there's some other precedence stuff in J, but the actual thing that was the topic of this post is not related to it.
    - patrec 5y ago
      The claim was that there is not operator precedence in J and that the result is "totally avoid ambiguity at all". But that's just not so. The / in `+/%#` totally is an operator, and could also have a user defined name. It does not have the same precedence as +, % and # and you can't parse the expression without knowing that beforehand. You also need to understand "trains". In fact you need two parses, because there are two essentially unrelated meanings of the expression and there is no context to disambiguate if it is monadic or dyadic.
SomeHacker44 5y ago
Came here to say the same about APL, of which J is a descendent.
userbinator 5y ago
...and yet the narrow-minded often tend to call it and the APL family "unreadable". It definitely has a learning curve, but as the analogy goes, someone who knows only English or some other non-Latin-based language seeing Chinese for the first time would probably have the same impression.

J has no operator precedence, and evaluates from right to left. Pretty easy to get used to.

by moeris 5y ago

J has no operator precedence, and evaluates from right to left. Pretty easy to get used to.

It's interesting what people find easy and hard. I find infix operators and their standard mathematical precedence rules perfectly intuitive. Equally good are the extended precedence rules of languages like R, which were designed by professional users of mathematics. I hate reading S-expressions and reverse polish notation. To me, proposals that we write in those notations are like saying that we should write assembly code. I think "No, we have compilers so that humans can write human-readable code rather than being forced to cater to the machine."

beagle3 5y ago
I do too, and it's fine as long as you (a) have a relatively small number of operators, and (b) use one language, or several that have conforming precedence. Does "<<" in C have the same precedence as "shl" in Pascal? How does it compare to multiplication, of which it is (essentially) a specialization? Does a<b<c in C mean what it does in Math? What about Python? When I learned APL (and J and K), the first instinctive response to the lack of operator precedence was wtf? -- all same precedence, all "right associative" / "right to left" / "left of right" / "long right scope" (same meaning, different terms). But after using it for a day, I realized all the other programming languages have it wrong. Math notation gets a pass because you handwrite it, so a set of rules that minimizes writing does make sense. Not so for programming languages. APL/J/K have tens, perhaps even a hundred, operators -- so there isn't really any other practical way. But it just works so well, that it puts the Algol/C/Pascal decision to copy math in an unfavorable light.

rak1507 5y ago

Came here to say something similar. This is the best option, and I would like this in every other language. Totally avoids any ambiguity at all.

patrec 5y ago
This is just untrue. You can't even parse J without knowing if something is an "adverb" or a "verb".
- abrudz 5y ago
  But the modern APL, BQN lets you directly see the syntax from the symbol or name: https://mlochbaum.github.io/BQN/doc/context.html#bqns-spelling-system https://mlochbaum.github.io/BQN/doc/context.html#bqns-spelli...
  - patrec 5y ago
    Thanks that's interesting! They however kept what I consider J/APL's main syntactic misfeature, overloading the meaning of every symbol in pretty arbitrary ways depending on whether it is called with one or two arguments. E.g. *: x " x squared y *: x " NAND of x and y At least it made it to the Problems with BQN page ;) https://mlochbaum.github.io/BQN/commentary/problems.html#incoherent-monad-dyad-builtin-pairs https://mlochbaum.github.io/BQN/commentary/problems.html#inc...
- rak1507 5y ago
  That has nothing to do with RTL 'operator' precedence. Ok, sure, there's some other precedence stuff in J, but the actual thing that was the topic of this post is not related to it.
  - patrec 5y ago
    The claim was that there is not operator precedence in J and that the result is "totally avoid ambiguity at all". But that's just not so. The / in `+/%#` totally is an operator, and could also have a user defined name. It does not have the same precedence as +, % and # and you can't parse the expression without knowing that beforehand. You also need to understand "trains". In fact you need two parses, because there are two essentially unrelated meanings of the expression and there is no context to disambiguate if it is monadic or dyadic.

SomeHacker44 5y ago

Came here to say the same about APL, of which J is a descendent.

userbinator 5y ago

...and yet the narrow-minded often tend to call it and the APL family "unreadable". It definitely has a learning curve, but as the analogy goes, someone who knows only English or some other non-Latin-based language seeing Chinese for the first time would probably have the same impression.