3 ms·

I would go further to say that syntax should never be used. for example with Go: > cheapFunction(...) || expensiveFunction(...) is not valid unless both funct

by 38 2y ago

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.

lolinder 2y ago
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).
- 38 2y ago
  just because a footgun exists, doesn't mean you should use it
  - lolinder 2y ago
    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.
    - 38 2y ago
      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.
      - trealira 2y ago
        > 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.

by 38 2y ago

lolinder 2y ago

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

38 2y ago
just because a footgun exists, doesn't mean you should use it
- lolinder 2y ago
  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.
  - 38 2y ago
    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.
    - trealira 2y ago
      > 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.