Hacker News Reader

Comment by dvt | Hacker News Reader

The writer here misunderstands how short-circuit evaluation is supposed to be used. The idea is that you should use SCE in a few, pretty standard, cases:

    cheapFunction(...) || expensiveFunction(...) // saves us a few cylces
    car = car || "bmw" // setting default values, common pattern
    funcA(...) && funcB_WhichMightBreakWithoutFuncA(...) // func A implies func B
    ...
    // probably a few other cases I don't remember

Using it to handle control flow (e.g. throwing exceptions, as a makeshift if-then, etc.) is a recipe for disaster.

View on HN

Short-circuiting evaluation is also useful for things like this:

  function insertion_sort(a) {
      for (let i = 1; i < a.length; i++) {
          let key = a[i];
          let j = i;
          while (j > 0 && key < a[j-1]) {
              a[j] = a[j-1];
              j--;
          }
          a[j] = key;
      }
  }

If short circuit evaluation didn't exist, then "key < a[j - 1]" would be evaluated even in the case where j = 0, leading to the array being indexed out of bounds.

I would go further to say that syntax should never be used. for example with Go:

> cheapFunction(...) || expensiveFunction(...)

is not valid unless both functions return bool

> car = car || "bmw"

is not valid at all, because both types would need to be bool

> funcA(...) && funcB_WhichMightBreakWithoutFuncA(...)

not valid unless functions return bool. I think Go smartly realized this syntax is just sugar that causes more problems than it solves.

This has nothing to do with syntax and short circuiting and everything to do with Go's type system. Go, like most compiled languages, has no concept of "truthiness". JavaScript is not Go and has truthiness.

We can debate the merits of truthiness and using it this way, but let's have that debate on the merits, not by invoking other languages with completely different design constraints.

Your argument here is similar to what got us "no split infinitives" in English (grammarians wanted English to be more like Latin).

just because a footgun exists, doesn't mean you should use it

Then let's talk—with specifics!—about why it's a footgun and we shouldn't use it.

"Because Go doesn't support it" would also be a reason to avoid:

* Generics (at least until recently)

* Classes

* Prototypes

* Exceptions

* Async/Await

* Package managers (until recently)

* Algebraic data types

* Effect types

* Type inference

* Type classes

* Etc.

You could argue that one or more of these are footguns, but I seriously doubt you'd consider them all to be, so let's talk about what separates the footgun from the feature that just didn't fit in Go's design.

This isn't about Go. This is about a language construct (&& and ||) that I would argue is terrible and should never be used. Its mainly just sugar, and in my experience code heavy on these is harder to read and write. Couple that with truthiness and it's even worse.

> This is about a language construct (&& and ||) that I would argue is terrible and should never be used.

Something tells me you'd hate my five-line implementation of the standard library function fgets in C.

  char *fgets(char *buf, size_t n, FILE *fp) {
      char *p = buf;
      int c = 0;
      while (n > 1 && (c = getc(fp)) != EOF && (*p++ = c) != '\n')
          n--;
      return n > 0 && (c != EOF || feof(fp) && p != buf) ? *p = '\0', buf : 0;
  }

I'm joking; I'd never write code this way in earnest.

Reply on news.ycombinator.com