Hacker News Reader

Comment by moeris | Hacker News Reader

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."

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.

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.

This is just untrue. You can't even parse J without knowing if something is an "adverb" or a "verb".

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-spelli...

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#inc...

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.

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.

Fair point. The equivalent of regular 'operators' +-*/&|etc in J are verbs, and restricting yourself only to verbs, there is no precedence and it is unambiguous, but with operators, it does get a bit more tricky.

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

...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.

Reply on news.ycombinator.com