Hacker News Reader

Comment by nogridbag | Hacker News Reader

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.

View on HN

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

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

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.

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"

In many languages, such as python, assignments are statements, not expressions, and so they don’t evaluate to anything at all.

Yeah, I covered that at the end.

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

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.

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

= 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

Ah I see your point. Appreciate the correction.

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

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?

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.

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

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

Once more I hope this is satire, but as so often on the Internet it is surprisingly hard to tell.

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?

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.

Tabs for indentation, spaces for alignment.

I used to feel very strongly about this. Then I started using Common Lisp and discovered the abomination that is tabstop. This archaic "feature" leads to tab width that varies across the line and seems to be hardcoded in every text editor out there. Worse, it's only useful if using tabs for alignment which is completely broken anyway! At some point I intend to patch the source for the editors I use to remove this nonsense.

Admittedly this is something of an edge case - how many languages other than Lisps involve alternating layers of indentation and alignment? The more common C like languages don't suffer from this at all.

At this point I'm largely convinced that more or less all of our tools, languages, and conventions are poorly thought out, brittle, and inelegant. /rant

usually I turn off tabs for indentation in Lisp editors. On a Lisp Machine:

  (setq zwei:*indent-with-tabs* nil)

I've settled on "follow the existing/upstream project's style; if it's a new project, follow the language's idiomatic style". I personally (strongly) prefer spaces over tabs, but I've inherited/forked plenty of projects that use tabs in JavaScript for example, and I just set my editor and formatter to use tabs in that project.

I think the ideal situation is a language with an official or at least commonly accepted formatter, so that existing and new projects will essentially always follow the same style and you never have to think about it. Like "go fmt" always using tabs. I don't like tabs, but I like that kind of enforced consistency way more than I dislike tabs.

That's also why I like using opinionated third-party formatters like prettier and black. Combined with pre-commit hooks, you almost never have to think about style and can just focus on the code. Plus diffs are cleaner.

Considering that most code get read by more than one person, I think hardcoding the author's preferences in how it should be read is strange and in some cases inaccessible.

This. Author chose two spaces per indent and proceeded to nest blocks 5 levels deep? Guess I have to run it through a code formatter now just to read it.

Alternatively, author chose eight spaces per indent and proceeded to nest things? My tiled windows only have ~100 columns, thanks so much for breaking my workflow with your poor choices.

But why not? These days reformatting on the fly is fast and easy. Especially if you enforce formatting conventions on commit (so you can automatically reformat into a canonical version).

Because typically code will be read far more than it is written and by far more people than contributed to it. In many cases I won't have the relevant tooling installed let alone know how to use it because I don't use that language myself. (For example, a library written in Rust that exposes C bindings whose prebuilt artifact I might download and link against.)

That being said, I 100% wholeheartedly approve of enforcing code formatting (among other things) on commit. Pre-commit hooks and linters are both awesome.

If you do not have the relevant tooling you can still read the canonical formatting.

If you want custom formatting, I don't think that expecting your editor to reformat on the fly is a big ask. At the end of the day that exactly what tab proponents expect.

> If you do not have the relevant tooling you can still read the canonical formatting.

Which is often unnecessarily difficult for whatever reason, hence my initial comment. Given that tabs already exist there's literally no reason not to use them other than to intentionally spite any future readers who don't agree with your preference for indentation width.

> that exactly what tab proponents expect

Because that capability is built into even the most primitive of text editors since forever. Per-language formatting, on the other hand, is most certainly not.

Using just tabs you end up with misaligned code. So you need a mix of tabs and spaces (i.e. smart tabs). But nobody sane [1] would do that by hand and would rely on their editor to do the indenting automatically. At this point just ask the editor to indent on demand.

[1] I'm hyperbolic, sorry if you actually do that although I pity you.

Automated reformats cause big problems in version control.

Every line appears to come from the reformat commit. So it's hard to see when the codes function was changed.

you format as part of the commit, not as a separate commit.

I believe what's being described is on the fly (ie uncommited) reformatting to suit individual reading preferences. Additional enforced autoformatting at the time of commit ensures that all version controlled code always conforms to the chosen style. Thus there are never any reformat commits unless the chosen style is modified.

> so that under any circumstances, the code reads the same as the author intended

I write all my code in notepad.exe with the font Wingdings. I hope that if you ever read any of my code you'll respect my intent with how it's displayed.

I prefer <- myself :)

Another Smalltalk fan!

Reply on news.ycombinator.com