如果null不好，为什么现代语言会实现它？ [关闭]

#1 楼

免责声明：由于我个人不认识任何语言设计师，因此我给您的任何答案都是推测性的。

来自Tony Hoare本人：我十亿美元的错误。这是在1965年发明空引用的。那时，我正在设计第一个全面的类型系统，用于面向对象语言（ALGOL W）的引用。我的目标是确保对引用的所有使用都绝对安全，并由编译器自动执行检查。但是我无法抗拒引入空引用的诱惑，只是因为它是如此容易实现。这导致了无数的错误，漏洞和系统崩溃，在最近四十年中可能造成十亿美元的痛苦和破坏。


强调我的经验。

自然，对当时的他来说，这似乎并不是一个坏主意。出于相同的原因，它可能被永久保留了-如果对得奖的图灵奖的快速排序发明者来说，这似乎是个好主意，那么很多人仍然不理解为什么它是邪恶的，这不足为奇。这也可能部分是因为出于市场营销和学习曲线方面的原因，新语言与旧语言的相似性很方便。恰当的例子：


“我们一直在追求C ++程序员。我们设法将其中的许多人拖到了Lisp的中间。”
-Guy Steele，共同作者Java规范


（来源：http://www.paulgraham.com/icad.html）

当然，C ++具有空值，因为C为null，则无需讨论C的历史影响。 C＃取代了J ++，后者是Microsoft的Java实现，并且它也取代了C ++作为Windows开发的首选语言，因此它可以从任何一个中得到。

EDIT这是另一句话来自Hoare的值得考虑的事情：


总体而言，编程语言比以前复杂得多：从连贯且科学基础的学科或正确性理论的角度来看，仍然没有真正考虑过面向对象，继承和其他功能。 。我一生一直追求的最初假设是，人们将正确性的标准作为一种融合体面的编程语言设计的手段-一种不会为用户设置陷阱的方法，而程序的不同组件清楚地对应于其规范的不同组件，因此您可以对其进行组合推理。 [...]这些工具（包括编译器）必须基于某种意义上的理论来编写正确的程序。
-Philip L. Frana的口述历史访谈，2002年7月17日，英国剑桥;明尼苏达大学查尔斯·巴贝奇研究所。[http://www.cbi.umn.edu/oh/display.phtml?id=343]


再次强调我的观点。 Sun / Oracle和Microsoft是公司，任何公司的底线都是金钱。拥有null给他们带来的好处可能胜过弊端，或者他们的截止日期太紧而无法充分考虑该问题。作为一个可能由于截止日期而导致的另一种语言错误的例子：


可克隆性被破坏了，但它确实发生了，这是一个耻辱。最初的Java API在紧迫的期限内很快就完成了，以迎接一个封闭的市场窗口。最初的Java团队做得非常出色，但是并非所有的API都是完美的。可克隆性是一个薄弱环节，我认为人们应该意识到它的局限性。 -乔什·布洛赫（Josh Bloch）


（来源：http://www.artima.com/intv/bloch13.html）

#2 楼

我敢肯定，像Java或C＃这样的语言的设计师都知道与空引用存在有关的问题。


当然。


另外，实现选项类型实际上并没有比null引用复杂得多。


我希望有所不同！在C＃2中，可为空的值类型所涉及的设计注意事项非常复杂，有争议且困难。他们花了几个月的时间讨论语言，运行时的设计团队以及原型的实现等问题，实际上，可空框的语义已非常接近于发行C＃2.0，这引起了很大争议。 />

他们为什么仍然决定将其包括在内？


所有设计都是一个在许多微妙且完全不兼容的目标之间进行选择的过程；我仅简要介绍一下将要考虑的几个因素：


语言功能的正交性通常被认为是一件好事。 C＃具有可空值类型，不可空值类型和可空引用类型。不可为空的引用类型不存在，这使得类型系统不是正交的。
熟悉C，C ++和Java的现有用户很重要。
与COM的轻松互操作性很重要。
>与所有其他.NET语言的轻松互操作性很重要。
与数据库的轻松互操作性很重要。
语义的一致性很重要；如果我们引用的TheKingOfFrance等于null，是否总是意味着“现在没有法国国王”，或者它也意味着“肯定有法国国王；我只是不知道现在是谁”？还是意味着“在法国拥有国王这个概念是荒谬的，所以甚至不要问这个问题！”？在C＃中，Null可能意味着所有这些东西，而所有这些概念都是有用的。
性能成本很重要。
进行静态分析很重要。
类型系统的一致性很重要；我们是否总能知道在任何情况下都不能将非空引用视为无效？在引用类型为非空字段的对象的构造函数中该怎么办？在这样的对象的终结器中，由于要填充引用的代码引发了异常，该对象被终结了，该怎么办？对于您而言，保证其安全性的类型系统很危险。
那么语义的一致性又如何呢？使用时传播空值，但使用空引用时会引发异常。这是不一致的；不一致可以带来一些好处吗？
我们可以在不破坏其他功能的情况下实现该功能吗？该功能还排除了将来可能出现的其他功能吗？
您与拥有的军队开战，而不是您想要的军队。记住，C＃1.0没有泛型，因此将Maybe<T>当作替代品完全是个入门。在运行时团队添加泛型以消除空引用的同时，.NET是否应该滑倒两年？
类型系统的一致性如何？您可以为任何值类型说出Nullable<T> －不，等等，这是一个谎言。你不能说Nullable<Nullable<T>>。你应该能够吗？如果是这样，其期望的语义是什么？使整个类型系统具有仅用于此功能的特殊情况是否值得？

等等。这些决定很复杂。

#3 楼

空值是代表缺乏价值的非常有效的目的。

我会说我是最了解声音的人，因为空值的滥用以及它们可能造成的所有头痛和痛苦，尤其是在使用时

我个人的立场是，人们只有在有必要证明其必要性和适当性时才可以使用null。

为null进行示例的示例：

死亡通常是可为空的字段。有三种可能的死亡日期。该人已经死亡并且知道日期，或者该人已经死亡并且日期未知，或者该人没有死亡，因此不存在死亡日期。

死亡日期也是DateTime字段，并且没有“未知”或“空”值。当您确定一个新的日期时间时，它确实具有默认日期，该日期根据所使用的语言而异，但是从技术上讲，这个人实际上确实在那个时间死亡，如果您愿意，它将标记为“空值”请使用默认日期。

数据将需要正确地表示情况。

人已死亡已知死亡日期（3/9/1984）

简单，'1984年3月9日'

人去世了，死亡日期不明

那么什么是最好的呢？ Null，“ 0/0/0000”或“ 01/01/1869”（或您的默认值是什么？）

人不是死亡日期不适用死亡日期

那什么是最好的呢？ Null，'0/0/0000'或'01 / 01/1869'（或您的默认值是什么？）

所以让我们考虑一下每个值...



为空，它包含一些隐患和您需要警惕的问题，无意中首先尝试操纵它而不先确认它不为null，例如会引发异常，但它也最能代表实际情况...如果这个人没有死，那么死亡的日期就不存在了...没什么...它是空的...

0/0/0000，这在某些语言中可能还可以，甚至可以适当表示无日期。不幸的是，某些语言和验证会将其拒绝为无效的日期时间，这使它在许多情况下都不可行。

1/1/1869（或任何默认的日期时间值是），这里的问题是变得棘手。您可以将其用作缺乏价值的东西，除非如果我想筛选出我没有死亡日期的所有记录，该怎么办？我可以轻松地筛选出在那一天实际死亡的人，这些人可能会导致数据完整性问题。

事实是有时您确实不需要表示任何内容，并且确定有时变量类型可以很好地解决这一问题，但通常变量类型必须不能表示任何内容。

如果我没有苹果，我有0个苹果，但是如果我不知道我有多少个苹果，该怎么办？

绝对会滥用null并有潜在危险，但是有时这是必要的。在许多情况下，它只是默认值，因为在我提供值之前，缺少值，需要一些东西来表示它。 （空）

#4 楼

我不会说“其他语言也有，我们也有……”，就像跟琼斯一样。任何新语言的一个关键功能是能够与其他语言的现有库进行互操作（阅读：C）。由于C具有空指针，因此互操作性层必然需要空的概念（或使用它时会炸毁的其他“不存在”等价物）。

语言设计者可以选择使用选项类型，并迫使您在任何可能为空的地方都处理空路径。而且几乎可以肯定会导致更少的错误。

但是（特别是对于Java和C＃，由于它们的引入时间和目标受众的时间），如果不对它们的采用大打折扣，则将选项类型用于此互操作性层可能会受到损害。选项类型一直向上传递，使90年代中期至90年代后期的C ++程序员烦恼-或互操作性层在遇到null时会抛出异常，使90年代中期至90年代后期的C ++程序员烦恼。 ..

#5 楼

首先，我认为我们都可以同意零概念是必要的。在某些情况下，我们需要表示缺少信息。

允许null引用（和指针）只是该概念的一种实现，尽管它已知存在问题，但可能是最受欢迎的一种实现： C，Java，Python，Ruby，PHP，JavaScript等都使用类似的null。为什么？那么，还有什么选择呢？

在诸如Haskell之类的功能语言中，您可以使用Option或Maybe类型。但是，这些是建立在以下基础之上的：


参数类型
代数数据类型

现在，原始的C，Java，Python，Ruby或PHP支持吗？这些功能中的任何一个？否。Java的有缺陷的泛型是该语言历史上的最新事物，我不知怎地怀疑其他语言甚至根本没有实现它们。

就可以了。 null很简单，参数代数数据类型更难。人们选择了最简单的选择。

#6 楼

Null / nil / none本身并不邪恶。

如果您看到他的名字被误导为著名的演讲“十亿美元的错误”，托尼·霍尔（Tony Hoare）谈到了如何让任何变量能够保持空值是一个巨大的错误。备选方案-使用选项-实际上并没有摆脱空引用。相反，它允许您指定哪些变量允许保留null，哪些变量不允许保留。

事实上，对于实现适当异常处理的现代语言而言，null取消引用错误不存在与任何其他例外不同-您找到了，就解决了。空引用的某些替代方法（例如，空对象模式）会隐藏错误，从而使事情无声地失败，直到以后。我认为，快速失败会更好。

那么问题来了，为什么语言无法实现Options？实际上，可以说是有史以来C ++最受欢迎的语言，它能够定义无法分配的对象变量NULL。这是Tony Hoare在讲话中提到的“零问题”的解决方案。为什么第二流行的打字语言Java没有呢？有人可能会问，为什么它通常有这么多缺陷，尤其是在类型系统上。我认为您无法真正说出语言是系统地犯此错误的。有些会，有些不会。

#7 楼

因为编程语言通常被设计为实用而不是技术上正确的。事实是，由于错误或丢失的数据或尚未确定的状态，null状态很常见。技术上优越的解决方案比简单地允许空状态和吸收程序员犯错误的事实更加笨拙。例如，如果我想编写一个与文件一起使用的简单脚本，我可以编写伪代码，例如：

file = openfile("joebloggs.txt")

for line in file
{
  print(line)
}

，如果joebloggs.txt不存在，它将只会失败。事实是，对于简单的脚本来说可能还可以，并且在更复杂的代码中的许多情况下，我知道它存在并且不会发生故障，因此迫使我进行检查浪费了我的时间。更安全的替代方案通过迫使我正确处理潜在的故障状态来实现其安全性，但通常我不想这样做，我只是想继续前进。

#8 楼

NULL（或nil或Nil或null或Nothing或您喜欢的语言中调用的任何东西）指针有明显的实际用途。

对于那些没有例外的语言在系统（例如C）中，当应返回指针时，可以将空指针用作错误标记。例如：

char *buf = malloc(20);
if (!buf)
{
    perror("memory allocation failed");
    exit(1);
}

这里将从NULL返回的malloc(3)用作故障标记。

在方法/函数参数中使用时，它可以指示对参数使用默认值，或者忽略输出参数。下面的示例。

即使对于具有异常机制的语言，空指针也可以用作软错误（即，可恢复的错误）的指示，尤其是在异常处理成本很高（例如，Objective- C）：

NSError *err = nil;
NSString *content = [NSString stringWithContentsOfURL:sourceFile
                                         usedEncoding:NULL // This output is ignored
                                                error:&err];
if (!content) // If the object is null, we have a soft error to recover from
{
    fprintf(stderr, "error: %s\n", [[err localizedDescription] UTF8String]);
    if (!error) // Check if the parent method ignored the error argument
        *error = err;
    return nil; // Go back to parent layer, with another soft error.
}

这里，软错误如果未被捕获，不会导致程序崩溃。这样就消除了Java那样的疯狂try-catch，并在程序流中具有更好的控制，因为软错误不会中断（并且少数硬异常通常无法恢复并且未被捕获）

#9 楼

有两个相关的但略有不同的问题：



应该根本存在null吗？还是应该始终在可能有用null的地方使用Maybe<T>？

所有引用是否都可以为空？如果不是，应该使用默认值吗？

必须显式地将可空引用类型声明为string?或类似的对象，才能避免null引起的大多数（但不是全部）问题，而与程序员的所用之处没有太大不同


我至少同意您的观点，并非所有引用都应该为空。但是避免null并非没有其复杂性：

.NET将所有字段初始化为default<T>，然后才能首先通过托管代码对其进行访问。这意味着对于引用类型，您需要null或等效的东西，并且无需运行代码即可将值类型初始化为某种零。尽管这两种方法都有严重的缺点，但default初始化的简单性可能胜过了这些缺点。例如，对于字段，您可以通过在初始化this指针之前要求对字段进行初始化来解决此问题。托管代码。 Spec＃沿这条路线走了，使用了与C＃相比构造函数链接不同的语法。
对于静态字段，请确保这更加困难，除非您对字段初始化程序中可能运行的代码种类施加严格限制，因为您不能简单地隐藏this指针。
如何初始化引用类型的数组？考虑一个List<T>，它由容量大于长度的阵列支持。其余元素需要具有一定的值。

另一个问题是，它不允许bool TryGetValue<T>(key, out T value)之类的方法，如果找不到任何内容，则将default(T)返回为value。尽管在这种情况下，很容易就争辩说out参数最初是不好的设计，并且此方法应该返回一个区分联合或一个may。

所有这些问题都可以解决，但这并不像“禁止null并且一切都很好”那样容易。