1,874 reputation
11824
bio website
location
age
visits member for 4 years, 1 month
seen Aug 11 at 22:29

Sep
9
awarded  Famous Question
Sep
2
awarded  Yearling
Mar
16
comment Are null references really a bad thing?
It's common in functional programming languages, like Haskell, Scala, F#, etc. The accepted answer links to an implementation in Java, but in a functional language like Scala, the syntax to use it is easier. If s is an Option[String] and you want to get its length, you can say s match { case Some(str) => str.length; case None => /* Handle this case however you want */ } With a string, s.length() risks a NullPointerException. With an Option[String], s.length() is caught at compile time, because Option[String] doesn't have a length.
Mar
13
awarded  Informed
Mar
13
comment Are null references really a bad thing?
@JensG in your latest example, does the compiler make you do the null check before every call to t.Something()? Or does it have some way of knowing you already did the check, and not making you do it again? What if you did the check before you passed t in to this method? With the Option type, the compiler knows whether you've done the check yet or not by looking at the type of t. If it's an Option, you haven't checked it, whereas if it's the unwrapped value then you have.
Mar
13
comment Are null references really a bad thing?
The compiler can force you to unwrap the maybe in the same way it prevents you from assigning an expression of compile-time type String to a variable of compile-time type Int. Whereas, with the null value, the compiler has to know the value of the expression to know you did something illegal, not just the compile-time type of the expression.
Mar
13
comment Are null references really a bad thing?
With the Option type, a "String that could be null" is a different type than a String, so the compiler can recognize when you're using a "String that could be null" as if it's a String without first doing the null check and extracting the String. If all strings can be null, then there's no reliable way for the compiler to tell. Heck, maybe the value of the String is coming from a closed-source third-party library... What's the compiler to do, read the documentation?
Mar
13
accepted Are null references really a bad thing?
Mar
13
comment Are null references really a bad thing?
Coming back to my own question a few years later, I'm now totally a convert of the Option / Maybe approach.
Mar
13
comment Are null references really a bad thing?
@JensG The point is, you're forced to check it by the compiler.
Mar
13
comment Are null references really a bad thing?
However I agree with the general comment that exceptions (used properly) are not a bad thing, and "fixing" an exception by swallowing it is generally a terrible idea. But with the Option type, the goal is to turn exceptions into compile-time errors, which are a better thing.
Mar
13
comment Are null references really a bad thing?
Unfortunately in Scala you still can say s: String = null, but that's the price of interoperability with Java. We generally disallow that sort of thing in our Scala code.
Mar
13
comment Are null references really a bad thing?
For example: You can't say s: String = None, you have to say s: Option[String] = None. And if s is an Option, you can't say s.length, however you can check that it has a value and extract the value at the same time, with pattern matching: s match { case Some(str) => str.length; case None => throw RuntimeException("Where's my value?") }
Mar
13
comment Are null references really a bad thing?
I know quite a bit more about the Option type now than when I posted the question a few years ago, since I now use them regularly in Scala. The point of Option is that it makes assigning None to something that isn't an Option into a compile-time error, and likewise using an Option as if it has a value without first checking it is a compile-time error. Compile errors are certainly nicer than run-time exceptions.
Sep
2
awarded  Yearling
Jul
15
awarded  Notable Question
Jun
18
comment How was programming done 20 years ago?
Admittedly, that argument doesn't really hold for interpreted languages. I had an old-school physics professor who refused to program in anything but Forth for this reason.
Jun
18
comment How was programming done 20 years ago?
OK, I'm taking the bait... Part of the process of debugging is figuring out the right questions to ask. With print-statement debugging, you have to recompile and rerun the whole program every time you have a new question. With the debugger, I go type my question in the Immediate window and there's the answer. This is a clear-cut productivity benefit. The fact that a tool makes your life easier does not make it a crutch, it makes it a good tool.
Jun
13
comment Does relying on intellisense and documentation a lot while coding makes you a bad programmer?
I'd much rather work with the person who looks everything up than the one who only thinks he knows how everything works.
Jun
12
comment Should I use parentheses in logical statements even where not necessary?
In all the languages I work with regularly it's .member before unary operators, unary before binary operators, * and / before + and - before < and > and == before && before || before assignment. Those rules are easy to remember because they match my "common sense" about how the operators are normally used (e.g., you wouldn't give == greater precedence than + or 1 + 1 == 2 stops working), and they cover 95% of the precedence questions I'd have.