- 主题:编程语言中的null，算不算是一个失败的设计？
--
FROM 223.104.3.*
null的始作俑者自己早就承认了，是一个多少billion的失败了啊
https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/
所以kotlin、dart啊啥的，都加了编译器层面的东西搞定这个问题
Rust和cpp后来的搞法，是optional吧
--
修改:z16166 FROM 125.35.125.*
FROM 125.35.125.*
std::optional(cpp)、std::option(Rust）可以认为就是一个object，两种状态：有值、无值。
kotlin的搞法是码农要告诉编译器某个变量的值是否可能为null，用语法糖 ? 区分，
对于可能为null的变量，编译期跟踪码农是否做了null check，不做的编过不去。
对于一定不会为null的变量，禁止可能的null赋值。
【 在 chaobill 的大作中提到: 】
: 返回 object 多好，然后由语法检测是 empty
--
FROM 125.35.125.*
关键是默认整个编程环境都是 non-null 的，optional 也是少部分，免得心智负担太重。现有语言写多了都是 optional<> 和 ?. 到处飘，很丑很恶心。
【 在 z16166 (Netguy) 的大作中提到: 】
: std::optional(cpp)、std::option(Rust）可以认为就是一个object，两种状态：有值、无值。
: kotlin的搞法是码农要告诉编译器某个变量的值是否可能为null，用语法糖 ? 区分，
: 对于可能为null的变量，编译期跟踪码农是否做了null check，不做的编过不去。
: ...................
--
修改:hgoldfish FROM 112.47.122.*
FROM 112.47.122.*
这是计算机科学 尝试 对 传统科学挑战 走的捷径。显然 攀登科学高峰没有捷径。
【 在 shibor 的大作中提到: 】
--
FROM 183.95.135.*
optional这些应该是从Haskell这些函数式编程语言学过去的。
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 关键是默认整个编程环境都是 non-null 的，optional 也是少部分，免得心智负担太重。现有语言写多了都是 optional<> 和 ?. 到处飘，很丑很恶心。
--
FROM 123.112.70.*
cpp的optional还不是针对指针的
主要内存分配失败这个操作没法完全避免，失败时也没法返回一个有意义的值（会被拿来读写内存），如果不想null被到处传播，那就只能就地panic或者扔异常，但有些应用不能这么干。
GSL里搞了个not_null，只能部分缓解
https://visualstudiomagazine.com/articles/2016/06/01/using-the-not_null-template.aspx
【 在 hgoldfish 的大作中提到: 】
: 关键是默认整个编程环境都是 non-null 的，optional 也是少部分，免得心智负担太重。现有语言写多了都是 optional<> 和 ?. 到处飘，很丑很恶心。
:
--
修改:z16166 FROM 125.35.125.*
FROM 125.35.125.*
勉强还好吧，有助于从类型信息上把各种异常情况框定住，对于接口的完备性很有帮助
【 在 hgoldfish 的大作中提到: 】
: 关键是默认整个编程环境都是 non-null 的，optional 也是少部分，免得心智负担太重。现有语言写多了都是 optional<> 和 ?. 到处飘，很丑很恶心。
:
--
修改:Bernstein FROM 125.33.246.*
FROM 125.33.246.*
我觉得不是，现实中确实有missing的概念
go语言想去掉null，但是不行，切片，函数还是nil
而且很多时候我们想知道哪些值是missing
但是go有默认值，搞得不知道到底是不是入参
不过go确实避免了大量的Null判断，for循环nil值也不会报错
【 在 shibor 的大作中提到: 】
--
修改:littleSram FROM 124.64.18.*
FROM 124.64.18.*