I have been reading about the (un)convenience of having
null instead of (for example)
Maybe. After reading this article, I am convinced that it would be much better to use
Maybe (or something similar). However, I am surprised to see that all the "well-known" imperative or object oriented programming languages still use
null (which allows unchecked access to types that can represent a 'nothing' value), and that
Maybe is mostly used in functional programming languages.
As an example, look at the following C# code:
void doSomething(string username)
// Check that username is not null
// Do something
Something smells bad here... Why should we be checking if the argument is null? Shouldn't we assume that every variable contains a reference to an object? As you can see, the problem is that by definition almost all variables can contain a null reference. What if we could decide which variables are "nullable" and which not? That would save us a lot of effort while debugging and looking for a "NullReferenceException". Imagine that, by default, no types could contain a null reference. Instead of that, you would state explicitly that a variable can contain a null reference, only if you really need it. That is the idea behind Maybe. If you have a function that in some cases fails (for example division by zero), you could return a
Maybe<int>, stating explicitly that the result may be an int, but also nothing! This is one reason to prefer Maybe instead of null. If you are interested in more examples, then I suggest to read this article.
The facts are that, despite the disadvantages of making most types nullable by default, most of the OO programming languages actually do it. That is why I wonder about:
- What kind of arguments would you have to implement
nullin your programming language instead of
Maybe? Are there reasons at all or is it just "historical baggage"?
Please ensure you understand the difference between null and Maybe before answering this question.