This mistake is fixed in Haskell.
[deleted]
What is wrong with NULL
21–30 of 147 posts
Re: What is wrong with NULL
#22[deleted]
Re: What is wrong with NULL
#23This mistake is fixed in Haskell.
Re: What is wrong with NULL
#24The mistake is an unsafe null: making every object type carry a value in its domain which says "Oops, though my type says I'm a Foobar, I'm not actually an object, la la la! Have a free exception on me, in your face!" Lisp's NIL is brilliant. It's in its own type, the null type! And it's the only instance of that type. No other type has a null instance. Null references in the language simply reflect the tension betwe…
Lisp nil is really unit right? Nothing to do with null as otherwise used?
Can you describe when you want to directly have an object that isn't there? If you want a "decoy object" that faults if used... why isn't Maybe perfect for that?
Re: What is wrong with NULL
#25Another reason that, even despite sharing a lot of syntax with PHP, Hack is one of my favorite languages:
Re: What is wrong with NULL
#26[deleted]
You don't need multiple return for this - that's exactly what Maybe is for. (You should have multiple return via tuples, but for other reasons.)
Re: What is wrong with NULL
#27The mistake is an unsafe null: making every object type carry a value in its domain which says "Oops, though my type says I'm a Foobar, I'm not actually an object, la la la! Have a free exception on me, in your face!" Lisp's NIL is brilliant. It's in its own type, the null type! And it's the only instance of that type. No other type has a null instance. Null references in the language simply reflect the tension betwe…
ruby nil is similar in that it's an instance of the Nil class. though, calling a method on nil that isn't there is a common error. I like how swift handles things. strong type system that makes it a little painful to do things unsafely. guarantees some things that make it a powerful and more safe language than objective c. I think they lost a few dynamic patterns though in the transition but that's just what i recall…
There is a reason why in Lisp the type of NIL is NULL and not NIL. NIL does in fact name a type also. That is different from the NULL type/class.
NULL has one instance, the object NIL. NULL isn't derived from anything; its superclass is the master superclass T.
The NIL type has an empty domain: no object is of the NIL type. (Somewhat like in C and C++, no object is of the void type, for those who like pointless C and C++ analogies that don't lead anywhere.) Furthermore, the NIL type is a subtype of every other type, the same way that T is a supertype of every other type. That is to say, every type is implicitly a supertype of nil. This goes hand in hand with the fact that the set of instances of any type is a superset of the empty set. E.g. set of integers (a type) has an empty subset (every set does), and that empty subset can be identified as the NIL type, whose domain is the empty set.
Re: What is wrong with NULL
#28This mistake is fixed in Haskell.
Rust, too! Edit: Btw, I disagree with how the article categorizes Rust in comparison to Haskell. It shows that Rust has std::ptr::null, but neglects the fact that Haskell has Foreign.Ptr.nullPtr. Either both should be "5 stars" or both should be "4 stars".
Ya, all of the 4 star ones basically include it in their ffi compatibility layers. The five star ones do too.
Re: What is wrong with NULL
#29Uglier than a Windows backslash, odder than ===, more common than PHP, more unfortunate than CORS, more disappointing than Java generics, more inconsistent than XMLHttpRequest, more confusing than a C preprocessor, flakier than MongoDB, and more regrettable than UTF-16, the worst mistake in computer science was introduced in 1965. That could be the greatest intro sentence ever seen on Hacker News.
Pretty good, but I've never had a problem with an XMLHttpRequest being inconsistent. Everything else seems spot-on though.
Re: What is wrong with NULL
#30Earlier quoted context omitted.
ruby nil is similar in that it's an instance of the Nil class. though, calling a method on nil that isn't there is a common error. I like how swift handles things. strong type system that makes it a little painful to do things unsafely. guarantees some things that make it a powerful and more safe language than objective c. I think they lost a few dynamic patterns though in the transition but that's just what i recall…
I agree, Swift's optionals are really great. But I also like Objective-C's nil: you can send messages to it and it won't do anything. That too solves a ton of problems with NULL.
What solves problem with null is if you can send messages to it, and have it do exactly what you want depending on the nature of message.