3 ms·

Okay, I realise this is probably a naïve question, but it hasn't been answered by any of the anti-null articles. Usually, null as a return value has some kind

Okay, I realise this is probably a naïve question, but it hasn't been answered by any of the anti-null articles. Usually, null as a return value has some kind of special meaning, like indicating a failure or other edge case. Making null go away doesn't mean that case can't happen, you just need to handle it differently. The example in the article String com = tld("example").getOrElse("unknown"); is one of those lovely academic examples which is completely out of touch with reality. Unless you're doing nothing but displaying it to the user, the string "unknown" is just as bad as the null object in almost every way, and worse in others: there's a reasonable chance that "unknown" will one day be a valid TLD. So the proposed solution with the Option<> generic type really is just a reminder to the programmer. There's no technical advantage. You might even see a decrease in performance if the compiler can't optimise it away. Except we already have a reminder mechanism: checked exceptions. Remember those? Remember how popular they are? C# actually has this concept of nullable types. It doesn't apply to class types which are always nullable, but structs (with mostly value semantics as opposed to identity semantics) can be either nullable or not - just like C/C++'s passing by value I suppose. Except they're so unwieldy to use due to the OMG IT MIGHT BE NULL paranoia (you can't do anything as ridiculous as access a member without unboxing... which will throw a NullPointerException if null - score!), you may as well redefine your struct as a class and use that. (which breaks cases where you didn't want it nullable. score 2!) I won't even treat C++ references (&) as a realistic attempt at a non-nullable type system because safety and C++ don't go together anyway. [1] I've not used scala, so if someone has a good, realistic example of code where scala's non-null system works well, I'd love to see it. I guess I have to add that I actually liked static typing for a long time (I've done my stereotypical 10000 hours of C++), until I noticed I was just slowing myself down and my code in dynamic languages wasn't any worse, just quicker/easier to modify. Is this a sign of programming maturity? Is static typing the "training wheel" mechanism for beginning programmers? I'm starting to think so. [1] void bar(Foo& f); Foo* p = 0; bar(*p);

vladev 17y ago
I agree, the example with the tld part wasn't the best - maybe an url schema (http part) would have been much better. "So the proposed solution with the Option<> generic type really is just a reminder to the programmer." - exactly. But a good program is a program that works, so we need to achieve that first. :)
- pmjordan 17y ago
  But a good program is a program that works, so we need to achieve that first. :) The thing is, static typing addresses this on the microscopic scale, where it's not difficult to make code work anyway - except maybe for novices, hence my "training wheels" analogy. I don't see any evidence that it helps correctness on a more macroscopic scale. In fact, it makes code more verbose, which makes it trickier to take in all at once. EDIT: rather than just hating on static typing, I propose this: How about making our languages more expressive? I don't think exceptions (try/catch/finally) are anywhere close to a global optimum for error/edge-case handling. Maybe there's no silver bullet, but I'm pretty confident we can do better than current exception handling. I hear Common Lisp 'conditions' are resumable, which sounds nice, but again only useful if you can reasonably substitute a value of some kind, a bit like the TLD example. What mechanism should we have if we really want our program to do something else in exceptional cases?
  - limmeau 17y ago
    Regarding "It makes code more verbose": while "new JSome<LongSuperclassName>(myValue)" is certainly more verbose than necessary, I still think that the one bit of information "this method returns Foos" vs "this method returns Foos or nothing" is worth documenting. And in a statically typed language, the type system is an obvious place for such documentation.
    - pmjordan 17y ago
      Sure, if you're already going to go to the trouble of having type annotations for everything, adding an extra '?' (like in C#) isn't going to break the camel's back. It's the unboxing and wrangling with the returned value that make it more verbose. As far as I can tell the only statically typed languages that stand any chance in terms of terseness are those with sophisticated type inference. In that case, "can return null" or not makes a lot of sense for auto-generated documentation or making it an error to compare the return value to null.
      - limmeau 17y ago

vladev 17y ago

I agree, the example with the tld part wasn't the best - maybe an url schema (http part) would have been much better. "So the proposed solution with the Option<> generic type really is just a reminder to the programmer." - exactly. But a good program is a program that works, so we need to achieve that first. :)

pmjordan 17y ago
But a good program is a program that works, so we need to achieve that first. :) The thing is, static typing addresses this on the microscopic scale, where it's not difficult to make code work anyway - except maybe for novices, hence my "training wheels" analogy. I don't see any evidence that it helps correctness on a more macroscopic scale. In fact, it makes code more verbose, which makes it trickier to take in all at once. EDIT: rather than just hating on static typing, I propose this: How about making our languages more expressive? I don't think exceptions (try/catch/finally) are anywhere close to a global optimum for error/edge-case handling. Maybe there's no silver bullet, but I'm pretty confident we can do better than current exception handling. I hear Common Lisp 'conditions' are resumable, which sounds nice, but again only useful if you can reasonably substitute a value of some kind, a bit like the TLD example. What mechanism should we have if we really want our program to do something else in exceptional cases?
- limmeau 17y ago
  Regarding "It makes code more verbose": while "new JSome<LongSuperclassName>(myValue)" is certainly more verbose than necessary, I still think that the one bit of information "this method returns Foos" vs "this method returns Foos or nothing" is worth documenting. And in a statically typed language, the type system is an obvious place for such documentation.
  - pmjordan 17y ago
    Sure, if you're already going to go to the trouble of having type annotations for everything, adding an extra '?' (like in C#) isn't going to break the camel's back. It's the unboxing and wrangling with the returned value that make it more verbose. As far as I can tell the only statically typed languages that stand any chance in terms of terseness are those with sophisticated type inference. In that case, "can return null" or not makes a lot of sense for auto-generated documentation or making it an error to compare the return value to null.
    - limmeau 17y ago