5 ms·

Yes, but giving nil a default type would be way more confusing.

by 13415 6y ago

morelisp 6y ago
Go already kind of does though, when you use it in a type switch nil has type nil. For binding purposes, `interface{}` also seems reasonable. (Or only half-joking, if I wanted maximum pragmatism for minimal clarity, nil's default type should be error.) It seems the root problem is that interfaces and concrete values occupy the same semantic positions. But that's way too hard a problem to fix; if I had a magic wand to update all existing code I'd probably just have `== nil` on an interface check for both kinds and try to rescue transitivity.
- brundolf 6y ago
  At the risk of inviting a flame-war, it's distressing to me that a language this recent, with such a purported focus on simplicity, has design-problems this fundamental
  - morelisp 6y ago
    Sorry, you won't get much agreement from me on this. There's only two kinds of languages, the kind with fundamental design problems and the kind people don't use. If you are looking for the perfect language may I suggest Forth on a Z80? Otherwise there's going to be a pile of shit hiding somewhere.
    - brundolf 6y ago
      I disagree. Issues like this on really core language primitives usually crop up when either: 1) The language lacked hindsight in its domain because there wasn't a ton of prior art (C) 2) The language didn't have enough foresight put into it (JavaScript) 3) The language's modern usage has drifted significantly far from its original usage (Java) Python is an example of a language people use that doesn't suffer from #1 (thanks to Perl and friends), doesn't really suffer from #2 (at least, Python 3) and doesn't (yet) suffer too badly from #3. It has plenty of flaws and limitations, but not in its foundation. The core language primitives are rock-solid. #1 doesn't apply to Go, and it's not old enough for #3 to apply. So that seems to only leave #2. (I should add that this doesn't make a language completely invalid or useless. I use (and even like!) JS despite its flaws; in fact I prefer it to Python overall, mostly due to the ecosystem. It's just disappointing to see issues of type #2, because they seem so avoidable.)
      - 13415 6y ago
        It's pointless discussing this. There is no perfect language and every programming language I've ever seen has design problems at one level or another. I know enough of CL, Pascal, Modula, Ada, Rust, Nim, etc., to know their weaknesses, too. Your C example is also not convincing. Lisp and Algol were already strong contenders at the time. People chose C because they needed a fast and close to metal language to create their own operating system for mainframes. It was a hack just like your category 2. Still, it's a great language.
        brundolf 6y ago
        > There is no perfect language > It's pointless discussing this I don't see how the first implies the second. This is a programming forum; it's good to discuss and debate the specifics of these things. C may not have been the best example of the category, but I think the category stands. Rust for example, much as I love it, is exploring uncharted territory. I wouldn't be surprised if 10 years from now we have ownership-based languages that are much easier to use, simply because lessons will have been learned by that point. Arguably Java's OOP fundamentals are not as good as C#'s because Java had to explore that territory first (setting aside technicalities about what the term "OOP" really means). Etc.
        13415 6y ago
        The problem is that decades of experience has shown that only few programmers can discuss the advantages and disadvantages of programming languages for certain purposes in a halfway objective manner, and since few of them implement their own languages even the good discussions often remain fruitless. I'll recommend Reddit's r/ProgrammingLanguages, as well as Scott's Programming Language Pragmatics as a reading instead. It's not fully up-to-date but I found the comparisons of features and their trade-offs in it fascinating.
      - nyanpasu64 6y ago
        I think Python suffers from #3, as they've been adding new (controversial) syntax like typing, the := operator, and pattern matching. These were intended to help write real-world code at the cost of simplicity and applicability as a teaching language.
  - 13415 6y ago
    Yes, that sounds like a flame war invitation. Issues with nil plays no role in practice.
  - jerf 6y ago
    I have a hard time classifying this as a "design problem" when it has zero practical implications. I've never encountered a problem that can be traced back to this, nor ever helped anyone else with a problem that can be tracked back to this. If it is a "design problem" it is of the weakest possible class. I can't imagine what would "fix" it that wouldn't be a larger design problem of its own. The whole "confused about nil interface vs. interface containing nil pointer of some type", while I would contend has a root cause of improperly importing the idea from C++ that nil is automatically invalid when in fact it is perfectly valid in Go to call methods on nil and thus confusing "nil" with "invalid", is at least a cause of real bugs and real misunderstandings.

Yes, but giving nil a default type would be way more confusing.

by 13415 6y ago

Yes, but giving nil a default type would be way more confusing.

Go already kind of does though, when you use it in a type switch nil has type nil. For binding purposes, `interface{}` also seems reasonable. (Or only half-joking, if I wanted maximum pragmatism for minimal clarity, nil's default type should be error.) It seems the root problem is that interfaces and concrete values occupy the same semantic positions. But that's way too hard a problem to fix; if I had a magic wand to update all existing code I'd probably just have `== nil` on an interface check for both kinds and try to rescue transitivity.

brundolf 6y ago
At the risk of inviting a flame-war, it's distressing to me that a language this recent, with such a purported focus on simplicity, has design-problems this fundamental
- morelisp 6y ago
  Sorry, you won't get much agreement from me on this. There's only two kinds of languages, the kind with fundamental design problems and the kind people don't use. If you are looking for the perfect language may I suggest Forth on a Z80? Otherwise there's going to be a pile of shit hiding somewhere.
  - brundolf 6y ago
    I disagree. Issues like this on really core language primitives usually crop up when either: 1) The language lacked hindsight in its domain because there wasn't a ton of prior art (C) 2) The language didn't have enough foresight put into it (JavaScript) 3) The language's modern usage has drifted significantly far from its original usage (Java) Python is an example of a language people use that doesn't suffer from #1 (thanks to Perl and friends), doesn't really suffer from #2 (at least, Python 3) and doesn't (yet) suffer too badly from #3. It has plenty of flaws and limitations, but not in its foundation. The core language primitives are rock-solid. #1 doesn't apply to Go, and it's not old enough for #3 to apply. So that seems to only leave #2. (I should add that this doesn't make a language completely invalid or useless. I use (and even like!) JS despite its flaws; in fact I prefer it to Python overall, mostly due to the ecosystem. It's just disappointing to see issues of type #2, because they seem so avoidable.)
    - 13415 6y ago
      It's pointless discussing this. There is no perfect language and every programming language I've ever seen has design problems at one level or another. I know enough of CL, Pascal, Modula, Ada, Rust, Nim, etc., to know their weaknesses, too. Your C example is also not convincing. Lisp and Algol were already strong contenders at the time. People chose C because they needed a fast and close to metal language to create their own operating system for mainframes. It was a hack just like your category 2. Still, it's a great language.
      - brundolf 6y ago
        > There is no perfect language > It's pointless discussing this I don't see how the first implies the second. This is a programming forum; it's good to discuss and debate the specifics of these things. C may not have been the best example of the category, but I think the category stands. Rust for example, much as I love it, is exploring uncharted territory. I wouldn't be surprised if 10 years from now we have ownership-based languages that are much easier to use, simply because lessons will have been learned by that point. Arguably Java's OOP fundamentals are not as good as C#'s because Java had to explore that territory first (setting aside technicalities about what the term "OOP" really means). Etc.
        13415 6y ago
        The problem is that decades of experience has shown that only few programmers can discuss the advantages and disadvantages of programming languages for certain purposes in a halfway objective manner, and since few of them implement their own languages even the good discussions often remain fruitless. I'll recommend Reddit's r/ProgrammingLanguages, as well as Scott's Programming Language Pragmatics as a reading instead. It's not fully up-to-date but I found the comparisons of features and their trade-offs in it fascinating.
    - nyanpasu64 6y ago
      I think Python suffers from #3, as they've been adding new (controversial) syntax like typing, the := operator, and pattern matching. These were intended to help write real-world code at the cost of simplicity and applicability as a teaching language.
- 13415 6y ago
  Yes, that sounds like a flame war invitation. Issues with nil plays no role in practice.
- jerf 6y ago
  I have a hard time classifying this as a "design problem" when it has zero practical implications. I've never encountered a problem that can be traced back to this, nor ever helped anyone else with a problem that can be tracked back to this. If it is a "design problem" it is of the weakest possible class. I can't imagine what would "fix" it that wouldn't be a larger design problem of its own. The whole "confused about nil interface vs. interface containing nil pointer of some type", while I would contend has a root cause of improperly importing the idea from C++ that nil is automatically invalid when in fact it is perfectly valid in Go to call methods on nil and thus confusing "nil" with "invalid", is at least a cause of real bugs and real misunderstandings.