3 ms·

Programming practically requires a willingness to continue learning. But his statements are deeply troubling: > I’m not annoyed by the way statements are forme

by byuu 10y ago

Programming practically requires a willingness to continue learning. But his statements are deeply troubling: > I’m not annoyed by the way statements are formed, or even by the precedence order (which I readily admit to not knowing or understanding or even caring much about) > And don’t complain about how I parenthesize my arithmetic statements. I already mentioned precedence order. All those parens are the result of yet another lesson I learned to avoid working weekends. ... his example is saying (a×b)+(c×d)+e->f. I understand it being a learning curve to memorize that bit-shifts have higher precedence over bitwise operators, but ... you learn that multiplication happens before addition in elementary school! It's a pre-requisite to learning pre-Algebra in middle school. This isn't even some arcane programming thing you have to learn. Sure, you can pepper all your code in parentheses, but sooner or later you're going to come across code that doesn't. And a person like that working on such a codebase is a huge danger. I don't say this to be mean, but I really don't think programming is the right profession for this guy.

chriswarbo 10y ago
Whilst the delivery could be better, I agree with the sentiment that operator precedence is a waste of time. It's exactly the kind of mundane, error-prone work that machines should be doing for us, whether it's via a sophisticated structured editor, or a simple hack like Emacs's various paredit-like modes. > Sure, you can pepper all your code in parentheses, but sooner or later you're going to come across code that doesn't. And a person like that working on such a codebase is a huge danger. I can certainly imagine someone who doesn't care about precedence using an editor which disambiguates such things automatically; either by adding parentheses, colouring the background, etc. I can also imagine such a person spotting precedence bugs introduced by a colleague who considered themselves to be above such tooling. Lisp, Forth and friends do perfectly well without having to consult precedence tables, and whilst I appreciate that some would prefer more syntax than those provide, I think precedence rules should still stick to the meta-level, parser-directing stuff like block delimiters, statement separators ("x ; y"), and maybe syntax sugar like "," ".", "=", etc. If it can be written as a library (which certainly includes things like numeric procedures) then it shouldn't have any precedence. Even this minimal amount of precedence should be avoidable if desired, e.g. to avoid ambiguities like "a = b xor c". In PHP this parses to "(a = b) xor c", which is a perfectly valid PHP expression and caused the most egregious waste of my time to date. Whilst it's true that learning and applying "BODMAS" is simple enough to do in high school arithmetic, the context of high school arithmetic is vastly impoverished compared to computer programming. For example, which has the higher precedence: integer multiplication or list append? What about floating-point division compared to image convolution? Tree construction or matrix subtraction? I think such questions are silly, yet they're a legitimate concern in languages with heavy use of infix notation (e.g. Haskell). Languages which define a fixed set of infix operators to avoid such problems (e.g. C) cause an unnecessary asymmetry between operators and every other procedure (e.g. think about the number of times "function(x, y) { return x + y; }" has been written by Javascript programmers!), and are impoverishing their domain of discourse much like high school arithmetic (e.g. compare introductory C material to something like https://code.world/doc.html?help/codeworld.md https://code.world/doc.html?help/codeworld.md or http://www.bootstrapworld.org/materials/spring2016/tutorial http://www.bootstrapworld.org/materials/spring2016/tutorial )
- masklinn 10y ago
  > Lisp, Forth and friends do perfectly well without having to consult precedence tables It helps that they have "alien" syntaxes (prefix or postfix but not infix). Smalltalk is also a language which did away with precedence almost entirely: it has a strict right-to-left evaluation model, and only three precedence levels[0]: unary messages (aSubject aMessage), binary messages (aValue <operator> anOtherValue) and keyword messages (aSubject aMessage: aValue) but because it has "infix operators" the effect is much weirder. [0] or possibly a fourth, the cascading `;` operator is not a message, and can become really, really weird when used with different message types e.g. 7 + 4 squared; factorial; yourself. binds like this: 7 (+ (4 squared)); factorial; yourself. so it computes 4 squared, adds it to 7, then computes the factorial of 7 and finally returns 7.

by byuu 10y ago

chriswarbo 10y ago

Whilst the delivery could be better, I agree with the sentiment that operator precedence is a waste of time. It's exactly the kind of mundane, error-prone work that machines should be doing for us, whether it's via a sophisticated structured editor, or a simple hack like Emacs's various paredit-like modes. > Sure, you can pepper all your code in parentheses, but sooner or later you're going to come across code that doesn't. And a person like that working on such a codebase is a huge danger. I can certainly imagine someone who doesn't care about precedence using an editor which disambiguates such things automatically; either by adding parentheses, colouring the background, etc. I can also imagine such a person spotting precedence bugs introduced by a colleague who considered themselves to be above such tooling. Lisp, Forth and friends do perfectly well without having to consult precedence tables, and whilst I appreciate that some would prefer more syntax than those provide, I think precedence rules should still stick to the meta-level, parser-directing stuff like block delimiters, statement separators ("x ; y"), and maybe syntax sugar like "," ".", "=", etc. If it can be written as a library (which certainly includes things like numeric procedures) then it shouldn't have any precedence. Even this minimal amount of precedence should be avoidable if desired, e.g. to avoid ambiguities like "a = b xor c". In PHP this parses to "(a = b) xor c", which is a perfectly valid PHP expression and caused the most egregious waste of my time to date. Whilst it's true that learning and applying "BODMAS" is simple enough to do in high school arithmetic, the context of high school arithmetic is vastly impoverished compared to computer programming. For example, which has the higher precedence: integer multiplication or list append? What about floating-point division compared to image convolution? Tree construction or matrix subtraction? I think such questions are silly, yet they're a legitimate concern in languages with heavy use of infix notation (e.g. Haskell). Languages which define a fixed set of infix operators to avoid such problems (e.g. C) cause an unnecessary asymmetry between operators and every other procedure (e.g. think about the number of times "function(x, y) { return x + y; }" has been written by Javascript programmers!), and are impoverishing their domain of discourse much like high school arithmetic (e.g. compare introductory C material to something like https://code.world/doc.html?help/codeworld.md https://code.world/doc.html?help/codeworld.md or http://www.bootstrapworld.org/materials/spring2016/tutorial http://www.bootstrapworld.org/materials/spring2016/tutorial )

masklinn 10y ago
> Lisp, Forth and friends do perfectly well without having to consult precedence tables It helps that they have "alien" syntaxes (prefix or postfix but not infix). Smalltalk is also a language which did away with precedence almost entirely: it has a strict right-to-left evaluation model, and only three precedence levels[0]: unary messages (aSubject aMessage), binary messages (aValue <operator> anOtherValue) and keyword messages (aSubject aMessage: aValue) but because it has "infix operators" the effect is much weirder. [0] or possibly a fourth, the cascading `;` operator is not a message, and can become really, really weird when used with different message types e.g. 7 + 4 squared; factorial; yourself. binds like this: 7 (+ (4 squared)); factorial; yourself. so it computes 4 squared, adds it to 7, then computes the factorial of 7 and finally returns 7.