矢量语言有时可以不使用null。

在本例中，空向量充当类型化null。

Robert Nystrom在这里提供了一篇不错的文章:

http://journal.stuffwithstuff.com/2010/08/23/void-null-maybe-and-nothing/

描述了他在为Magpie编程语言添加缺席和失败支持时的思维过程。

来自。net背景，我一直认为null是有意义的，它很有用。直到我了解了结构体，以及使用它们是多么容易，避免了大量的样板代码。2009年，托尼·霍尔在伦敦QCon大会上为发明空引用而道歉。引用他的话:

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965.

在程序员身上也可以看到这个问题

我总是把Null(或nil)看作是一个值的缺失。

有时你想这样，有时又不想。这取决于您正在处理的域。如果缺少中间名是有意义的:没有中间名，那么您的应用程序可以相应地执行。另一方面，如果不应该有空值:第一个名字是空的，那么开发人员会在凌晨2点接到电话。

我还见过代码因检查null而超载和过于复杂。对我来说，这意味着两件事之一: A)在应用程序树中更高的错误 B)糟糕的/不完整的设计

从积极的方面来看——Null可能是检查是否缺少某些东西的更有用的概念之一，没有Null概念的语言在进行数据验证时最终会使事情过于复杂。在这种情况下，如果新变量没有初始化，所述语言通常会将变量设置为空字符串0或空集合。但是，如果空字符串或0或空集合是应用程序的有效值——那么就有问题了。

有时，通过为字段创建特殊/奇怪的值来表示未初始化的状态，可以避免这种情况。但是当一个好心的用户输入特殊值时会发生什么呢?让我们不要陷入数据验证例程的混乱。 如果语言支持空概念，那么所有的关注点都将消失。

选项类型的好处并不在于它们是可选的。而是所有其他类型的人都不是。

有时，我们需要能够表示一种“null”状态。有时我们必须表示一个“无值”选项以及变量可能接受的其他可能值。因此，一种完全不允许这一点的语言将会有点残缺。

但通常情况下，我们并不需要它，并且允许这样的“null”状态只会导致歧义和混乱:每次在. net中访问引用类型变量时，我都必须考虑它可能是空的。

通常情况下，它实际上永远不会为空，因为程序员构造的代码使它永远不会发生。但是编译器不能验证它，每次你看到它，你都要问自己“这个可以为空吗?”我需要检查这里是否为空吗?”

理想情况下，在许多情况下，null没有意义，它不应该被允许。

在. net中实现这一点很棘手，因为几乎所有东西都可以为空。您必须依赖所调用代码的作者100%遵守纪律和一致，并清楚地记录了什么可以为空，什么不可以为空，否则您必须偏执狂，检查所有内容。

但是，如果默认情况下类型不能为空，则不需要检查它们是否为空。你知道它们永远不可能为空，因为编译器/类型检查器会强制你这样做。

然后，我们只需要一个后门，在极少数情况下，我们确实需要处理一个空状态。然后可以使用“选项”类型。然后，在我们有意识地决定我们需要能够表示“无值”的情况下，我们允许null，而在其他任何情况下，我们知道值永远不会为null。

正如其他人所提到的，在c#或Java中，null可能意味着以下两种情况之一:

变量未初始化。理想情况下，这种情况不应该发生。一个变量不应该存在，除非它被初始化。 变量包含一些“可选”数据:它需要能够表示没有数据的情况。这有时是必要的。也许你试图在一个列表中找到一个对象，而你事先不知道它是否在那里。然后我们需要能够表示“没有找到对象”。

第二种意思必须保留，但第一种意思应该完全消除。甚至第二种意思也不应该是默认的。如果我们需要，我们可以选择加入。但当我们不需要某些东西为可选时，我们希望类型检查器保证它永远不会为空。

我认为为什么空是不可取的简单总结是，无意义的状态不应该是可表示的。

假设我在建模一扇门。它可以处于三种状态之一:打开、关闭但未解锁、关闭并锁定。现在我可以用

class Door
    private bool isShut
    private bool isLocked

如何将三个状态映射到这两个布尔变量是很清楚的。但这就留下了第四种不希望出现的状态:isShut==false && isLocked==true。因为我所选择的类型承认这种状态，所以我必须花费精力来确保类永远不会进入这种状态(可能通过显式地编码一个不变量)。相反，如果我使用一种具有代数数据类型的语言或允许我定义的受控枚举

type DoorState =
    | Open | ShutAndUnlocked | ShutAndLocked

那么我就可以定义

class Door
    private DoorState state

再也没有什么担心了。类型系统将确保类Door的实例只有三种可能的状态。这正是类型系统所擅长的——在编译时显式地排除了一整类错误。

null的问题在于，每个引用类型都会在其空间中获得这个通常不希望的额外状态。字符串变量可以是任意字符序列，也可以是这个疯狂的额外空值，它没有映射到我的问题域。三角形对象有三个点，它们本身有X和Y值，但不幸的是，这些点或三角形本身可能是这个疯狂的空值，对我所处的绘图域毫无意义。等。

当您确实打算对一个可能不存在的值建模时，那么您应该显式地选择它。如果我打算对人建模的方式是每个人都有一个名字和一个姓，但只有一些人有中间名，那么我想说一些像这样的话

class Person
    private string FirstName
    private Option<string> MiddleName
    private string LastName

这里的string被假定为非空类型。这样，在尝试计算某人名字的长度时，就不需要建立棘手的不变量，也不会出现意外的nullreferenceexception。类型系统确保任何处理midlename的代码都考虑到它为None的可能性，而任何处理FirstName的代码都可以安全地假设那里有一个值。

例如，使用上面的类型，我们可以编写这个愚蠢的函数:

let TotalNumCharsInPersonsName(p:Person) =
    let middleLen = match p.MiddleName with
                    | None -> 0
                    | Some(s) -> s.Length
    p.FirstName.Length + middleLen + p.LastName.Length

没有烦恼。相反，在一种语言中，对字符串等类型的可空引用，则假设

class Person
    private string FirstName
    private string MiddleName
    private string LastName

你最终创作的东西就像

let TotalNumCharsInPersonsName(p:Person) =
    p.FirstName.Length + p.MiddleName.Length + p.LastName.Length

如果传入的Person对象没有所有东西都是非空的不变式，那么它就会爆炸，或者

let TotalNumCharsInPersonsName(p:Person) =
    (if p.FirstName=null then 0 else p.FirstName.Length)
    + (if p.MiddleName=null then 0 else p.MiddleName.Length)
    + (if p.LastName=null then 0 else p.LastName.Length)

或者

let TotalNumCharsInPersonsName(p:Person) =
    p.FirstName.Length
    + (if p.MiddleName=null then 0 else p.MiddleName.Length)
    + p.LastName.Length

假设p确保first/last在那里，但middle可以为空，或者你可能会检查抛出不同类型的异常，或者谁知道呢。所有这些疯狂的实现选择和需要考虑的事情突然出现，因为有这种愚蠢的可代表价值，你不想要或不需要。

Null通常会增加不必要的复杂性。复杂性是所有软件的敌人，您应该在合理的情况下努力降低复杂性。

(Note well that there is more complexity to even these simple examples. Even if a FirstName cannot be null, a string can represent "" (the empty string), which is probably also not a person name that we intend to model. As such, even with non-nullable strings, it still might be the case that we are "representing meaningless values". Again, you could choose to battle this either via invariants and conditional code at runtime, or by using the type system (e.g. to have a NonEmptyString type). The latter is perhaps ill-advised ("good" types are often "closed" over a set of common operations, and e.g. NonEmptyString is not closed over .SubString(0,0)), but it demonstrates more points in the design space. At the end of the day, in any given type system, there is some complexity it will be very good at getting rid of, and other complexity that is just intrinsically harder to get rid of. The key for this topic is that in nearly every type system, the change from "nullable references by default" to "non-nullable references by default" is nearly always a simple change that makes the type system a great deal better at battling complexity and ruling out certain types of errors and meaningless states. So it is pretty crazy that so many languages keep repeating this error again and again.)