7 ms·

I've seen the = instead of == in the wild with disastrous results: the assignment was on an ORM backed object, e.g. // accidentally mutates all names to Sa

I've seen the = instead of == in the wild with disastrous results: the assignment was on an ORM backed object, e.g. // accidentally mutates all names to Sam and persists to the DB myList.filter { myDomainObj.name = 'Sam' } But it makes me wonder why our programming languages would use characters which can often lead to this type of error.

sneak 5y ago
If you consider a linter part of a programming language, most, when properly configured, do not permit this. It's just the syntax that does; professionals do not rely on syntax validity alone but employ linting, code review, static analysis, and integrations tests on top. The gradient of professionalism in our industry is very wide, and the slope is quite shallow. To your point, however, many languages (such as Go, developed and used by Google, the organization under discussion) have designed their syntax now to completely avoid this type of error even being possible.
- tmp_anon_22 5y ago
  > type of error even being possible I mean its still possible to forget the ":" character and its still possible to mentally scan a PR and see "=" and miss that it should have been a "==".
  - edflsafoiewq 5y ago
    = vs == isn't possible in Go because of the statement/expression distinction. The benefits of allowing assignment to be an expression are too small compared to the problems it causes. x == 1 // oops, meant = // x == 1 evaluated but not used if x = 1 { ... } // oops, meant == // syntax error: assignment x = 1 used as value
    - tmp_anon_22 5y ago
      Ah I see your point. Appreciate the correction.
    - Macha 5y ago
      Python had similar, then introduced := for explicit assignment-as-expression. The debate over that one is considered a contributing factor to Guido's retirement as bdfl
- galangalalgol 5y ago
  what is the difference between linting and static analysis? Coverity, cppcheck etc, what are those? You mention integration tests, but not unit test, do you value unit test?
  - Macha 5y ago
    You could consider linting a subset of static analysis that considers only smaller units of code and not program flow. A linter might tell you your variable names are wrong or your brackets are wrong or you used discouraged method xyz. A different static analysis tool might tell you there's a path through a function that leaks memory.
nightfly 5y ago
I'm a fan of programming languages using := for assignment for this reason
- AnimalMuppet 5y ago
  Look, I know that this is an enormously bad bug, but... Google has a codebase that numbers multiple billions of lines. Using := means typing multiple billions of extra characters. That adds up. And it wouldn't even have prevented this bug! All checks have costs. As Emerson said, "A stitch in time saves nine. So we make 1000 stitches, that by doing so we may save nine."
  - anyfoo 5y ago
    Once more I hope this is satire, but as so often on the Internet it is surprisingly hard to tell.
    - samtheprogram 5y ago
      This reminds me of Silicon Valley’s main character preferring tabs to spaces because they use less bytes, despite his own product being for... compression! I personally prefer spaces so that under any circumstances, the code reads the same as the author intended (whether you’re in an editor or viewing a file with a CLI tool). Are we really counting bytes in this day and age?
      - hashingroll 5y ago
        The argument for tabs really goes that time is spent much more on reading code than authoring, so it should be optimized and customizable (tab width) for the reader.
        anyfoo 5y ago
        Tabs for indentation, spaces for alignment.
anyfoo 5y ago
The problem is not even with "easy to mix up operators" for this, it's about languages without a strong and static enough type system. While the particular problem Google hit is a bit more subtle (involving undefined behavior), in the majority of cases a strongly typed language would not allow expressions that accidentally mix up = and ==, as they often resolve to different types. In C "if (foo = bar)" and "if (foo == bar)" are both legal, because pretty much any type can be automatically coerced into a boolean. In many modern languages that is not the case. (Of course if you have assignments as expressions you are still screwed if foo and bar are both boolean to begin with, so some languages got away with that, too. And for fairness I should say that C at the very least warns if you don't explicitly put parentheses around the assignment, nowadays.)
- crazygringo 5y ago
  > in the majority of cases a strongly typed language would not allow expressions that accidentally mix up = and ==, as they resolve to different types. That's not true at all. Whenever you're intending to compare equality, they're usually going to be the same type already unless you're being really slopping in a scripting language like JavaScript or PHP -- but even then they're usually two numbers, two strings, or two booleans. The whole problem here is where foo and bar are both integers, or booleans, or whatever you want, and instead of typing "if (foo == bar)" you type "if (foo = bar)". Strong typing does nothing whatsoever to help in this common situation.
  - anyfoo 5y ago
    No. It can help because the result of the expression would have a different type, one that "if" does not accept. If a and b are integers, then the expression "a = b" is an integer too, but "a == b" is a boolean. In a strongly typed language, you can assume that "if" only accepts booleans.
    - tialaramex 5y ago
      Yeah. The direction of modern languages has been away from features like this which are "clever" but don't express anything you couldn't have said by another means - and yet allow programmers to accidentally write something nobody would ever want. Assignment shouldn't have a return type. Compound assignment operators? Likewise. You never need this return value, and sometimes you may use it by mistake. So, abolish it. In C++ not only do operators that shouldn't have a return value have one anyway, the type of that value might be anything. You can even overload both ++ operators to return different unrelated types so that mytype aThing { blah }; auto a = aThing++; // returns a String "Fuck tha police" auto b = ++aThing; // returns a double, 8.63 The Jeff Goldblum GIF is often the appropriate reaction to C++ features: "Your scientists were so preoccupied with whether or not they could, that they didn't stop to think if they should"
meowface 5y ago
>But it makes me wonder why our programming languages would use characters which can often lead to this type of error. Guido van Rossum wondered the same, which is why it isn't possible in Python. Same for "&&" vs. "&", since in Python it's "and" vs. "&".

sneak 5y ago

If you consider a linter part of a programming language, most, when properly configured, do not permit this. It's just the syntax that does; professionals do not rely on syntax validity alone but employ linting, code review, static analysis, and integrations tests on top. The gradient of professionalism in our industry is very wide, and the slope is quite shallow. To your point, however, many languages (such as Go, developed and used by Google, the organization under discussion) have designed their syntax now to completely avoid this type of error even being possible.

tmp_anon_22 5y ago
> type of error even being possible I mean its still possible to forget the ":" character and its still possible to mentally scan a PR and see "=" and miss that it should have been a "==".
- edflsafoiewq 5y ago
  = vs == isn't possible in Go because of the statement/expression distinction. The benefits of allowing assignment to be an expression are too small compared to the problems it causes. x == 1 // oops, meant = // x == 1 evaluated but not used if x = 1 { ... } // oops, meant == // syntax error: assignment x = 1 used as value
  - tmp_anon_22 5y ago
    Ah I see your point. Appreciate the correction.
  - Macha 5y ago
    Python had similar, then introduced := for explicit assignment-as-expression. The debate over that one is considered a contributing factor to Guido's retirement as bdfl
galangalalgol 5y ago
what is the difference between linting and static analysis? Coverity, cppcheck etc, what are those? You mention integration tests, but not unit test, do you value unit test?
- Macha 5y ago
  You could consider linting a subset of static analysis that considers only smaller units of code and not program flow. A linter might tell you your variable names are wrong or your brackets are wrong or you used discouraged method xyz. A different static analysis tool might tell you there's a path through a function that leaks memory.

nightfly 5y ago

I'm a fan of programming languages using := for assignment for this reason

AnimalMuppet 5y ago
Look, I know that this is an enormously bad bug, but... Google has a codebase that numbers multiple billions of lines. Using := means typing multiple billions of extra characters. That adds up. And it wouldn't even have prevented this bug! All checks have costs. As Emerson said, "A stitch in time saves nine. So we make 1000 stitches, that by doing so we may save nine."
- anyfoo 5y ago
  Once more I hope this is satire, but as so often on the Internet it is surprisingly hard to tell.
  - samtheprogram 5y ago
    This reminds me of Silicon Valley’s main character preferring tabs to spaces because they use less bytes, despite his own product being for... compression! I personally prefer spaces so that under any circumstances, the code reads the same as the author intended (whether you’re in an editor or viewing a file with a CLI tool). Are we really counting bytes in this day and age?
    - hashingroll 5y ago
      The argument for tabs really goes that time is spent much more on reading code than authoring, so it should be optimized and customizable (tab width) for the reader.
      - anyfoo 5y ago
        Tabs for indentation, spaces for alignment.

anyfoo 5y ago

The problem is not even with "easy to mix up operators" for this, it's about languages without a strong and static enough type system. While the particular problem Google hit is a bit more subtle (involving undefined behavior), in the majority of cases a strongly typed language would not allow expressions that accidentally mix up = and ==, as they often resolve to different types. In C "if (foo = bar)" and "if (foo == bar)" are both legal, because pretty much any type can be automatically coerced into a boolean. In many modern languages that is not the case. (Of course if you have assignments as expressions you are still screwed if foo and bar are both boolean to begin with, so some languages got away with that, too. And for fairness I should say that C at the very least warns if you don't explicitly put parentheses around the assignment, nowadays.)

crazygringo 5y ago
> in the majority of cases a strongly typed language would not allow expressions that accidentally mix up = and ==, as they resolve to different types. That's not true at all. Whenever you're intending to compare equality, they're usually going to be the same type already unless you're being really slopping in a scripting language like JavaScript or PHP -- but even then they're usually two numbers, two strings, or two booleans. The whole problem here is where foo and bar are both integers, or booleans, or whatever you want, and instead of typing "if (foo == bar)" you type "if (foo = bar)". Strong typing does nothing whatsoever to help in this common situation.
- anyfoo 5y ago
  No. It can help because the result of the expression would have a different type, one that "if" does not accept. If a and b are integers, then the expression "a = b" is an integer too, but "a == b" is a boolean. In a strongly typed language, you can assume that "if" only accepts booleans.
  - tialaramex 5y ago
    Yeah. The direction of modern languages has been away from features like this which are "clever" but don't express anything you couldn't have said by another means - and yet allow programmers to accidentally write something nobody would ever want. Assignment shouldn't have a return type. Compound assignment operators? Likewise. You never need this return value, and sometimes you may use it by mistake. So, abolish it. In C++ not only do operators that shouldn't have a return value have one anyway, the type of that value might be anything. You can even overload both ++ operators to return different unrelated types so that mytype aThing { blah }; auto a = aThing++; // returns a String "Fuck tha police" auto b = ++aThing; // returns a double, 8.63 The Jeff Goldblum GIF is often the appropriate reaction to C++ features: "Your scientists were so preoccupied with whether or not they could, that they didn't stop to think if they should"

meowface 5y ago

>But it makes me wonder why our programming languages would use characters which can often lead to this type of error. Guido van Rossum wondered the same, which is why it isn't possible in Python. Same for "&&" vs. "&", since in Python it's "and" vs. "&".