4 ms·

I'm not fluent in either Objective-C or Swift, maybe that's the reason why the brilliance of having four types of "null"/"nil" escapes me? Ok, it probably works

by rob74 5y ago

I'm not fluent in either Objective-C or Swift, maybe that's the reason why the brilliance of having four types of "null"/"nil" escapes me? Ok, it probably works well if you're used to it, but it feels more like a kludge than anything else...

throwaway4good 5y ago
It tells the tragic story of a language designer fighting to avoid null while building on/interfacing with an existing platform that has null.
- zaphirplane 5y ago
  Kotlin kind of got away with it, in the sense that I (massive statically) don’t hear people complain about null on the Java interoperability calls
  - throwaway4good 5y ago
    I think Kotlin took a more pragmatic approach - basically introducing ? and ! to signify that something could be null or something isn't null even though the compiler cannot see it.
- DonHopkins 5y ago
  "My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg "It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg
  - cxr 5y ago
    JS has null, the notion of a reference/binding being undefined, and the notion of a reference/binding being defined but assigned the value undefined.
Someone 5y ago
FTA: the concept of “nothing” in Objective-C is kind of a mess, since there’s four different versions of it The article is about nil, not about that. And yes, part of it is a kludge. I think that’s only NSNull, and that, technically, isn’t a language issue, but a library one. As https://nshipster.com/nil/ https://nshipster.com/nil/ (which explains all of this) says: NSNull is used throughout Foundation and other frameworks to skirt around the limitations of collections like NSArray and NSDictionary not being able to contain nil values. You can think of NSNull as effectively boxing the NULL or nil value so that it can be used in collections. I think a better implementation would use a private singleton NSNull inside the container as a sentinel, so that users of the class could store nil values.
- dspillett 5y ago
  > the concept of “nothing” in Objective-C is kind of a mess, since there’s four different versions of it Sounds like Visual Basic of old. We used to refer to the four constants of the apocalypse: null, nothing, missing, and empty.
olliej 5y ago
The “brilliance” is not having four nulls - that honestly more of a step down the road to use specific null values. The brilliance is the nil messaging semantic, it allows you to write concise code with a single error check at the end of appropriate, e.g: [[[foo bar:wibble] thing:1, thing: 2].wat again] Without having to have error check after error check after error check. These worked together, that return nil had so little cost on the API, you were able to have more error checks that return nil instead of trying to create some kind of fake value. Because you have so many error returns you have to check a lot if you didn’t have nil messaging. Our belief of what makes things good language design have changed a tiny bit in the intervening years :)

by rob74 5y ago

throwaway4good 5y ago

It tells the tragic story of a language designer fighting to avoid null while building on/interfacing with an existing platform that has null.

zaphirplane 5y ago
Kotlin kind of got away with it, in the sense that I (massive statically) don’t hear people complain about null on the Java interoperability calls
- throwaway4good 5y ago
  I think Kotlin took a more pragmatic approach - basically introducing ? and ! to signify that something could be null or something isn't null even though the compiler cannot see it.
DonHopkins 5y ago
"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg "It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg
- cxr 5y ago
  JS has null, the notion of a reference/binding being undefined, and the notion of a reference/binding being defined but assigned the value undefined.

Someone 5y ago

FTA: the concept of “nothing” in Objective-C is kind of a mess, since there’s four different versions of it The article is about nil, not about that. And yes, part of it is a kludge. I think that’s only NSNull, and that, technically, isn’t a language issue, but a library one. As https://nshipster.com/nil/ https://nshipster.com/nil/ (which explains all of this) says: NSNull is used throughout Foundation and other frameworks to skirt around the limitations of collections like NSArray and NSDictionary not being able to contain nil values. You can think of NSNull as effectively boxing the NULL or nil value so that it can be used in collections. I think a better implementation would use a private singleton NSNull inside the container as a sentinel, so that users of the class could store nil values.

dspillett 5y ago
> the concept of “nothing” in Objective-C is kind of a mess, since there’s four different versions of it Sounds like Visual Basic of old. We used to refer to the four constants of the apocalypse: null, nothing, missing, and empty.

olliej 5y ago

The “brilliance” is not having four nulls - that honestly more of a step down the road to use specific null values. The brilliance is the nil messaging semantic, it allows you to write concise code with a single error check at the end of appropriate, e.g: [[[foo bar:wibble] thing:1, thing: 2].wat again] Without having to have error check after error check after error check. These worked together, that return nil had so little cost on the API, you were able to have more error checks that return nil instead of trying to create some kind of fake value. Because you have so many error returns you have to check a lot if you didn’t have nil messaging. Our belief of what makes things good language design have changed a tiny bit in the intervening years :)