Aha, how timely! I just wrote this post on functors and applicatives that uses Maybe as an example: http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...
great illustrations.
Why Maybe Is Better Than Null
121–130 of 133 posts
Re: Why Maybe Is Better Than Null
#122making null fuzzy may save your program from a crash, but it also makes execution unpredictable. I would prefer a crash - which would lead to better localization and bug fixing - than indeterminate behaviour which is hard to debug and maintain.
Re: Why Maybe Is Better Than Null
#123Earlier quoted context omitted.
You can also make Maybe an instance of various typeclasses for even nicer syntax: instance Num a => Num (Maybe a) where (+) = liftM2 (+) (-) = liftM2 (-) (*) = liftM2 (*) abs = liftM abs signum = liftM signum negate = liftM negate fromInteger = Just . fromInteger > Just 4 + 2 * Just 6 Just 16 > Nothing * 42 Nothing Notice how the fromInteger method allows you to freely mix Maybe and non-Maybe numbers.
Sounds like a bad idea to me. Even though Num doesn't have an explicit contract, we sort of expect it to behave "nicely". But here we start with a nice ring like Integer and end up with a type that has this weird, extra element that has no inverse with respect to addition, etc.
For all fixed length two's complement integer types the smallest representable number has no additive inverse, too.
Re: Why Maybe Is Better Than Null
#124I can't believe there is no mention of Ceylon here. Ceylon has an elegant approach to this using union types.
Typesafe null and flow-dependent typing
There's no NullPointerException in Ceylon, nor anything similar. Ceylon
requires us to be explicit when we declare a value that might be null,
or a function that might return null. For example, if name might be null,
we must declare it like this:
String? name = ...
Which is actually just an abbreviation for:
String|Null name = ...
An attribute of type String? might refer to an actual instance of String,
or it might refer to the value null (the only instance of the class Null).
So Ceylon won't let us do anything useful with a value of type String?
without first checking that it isn't null using the special if (exists ...)
construct.
void hello(String? name) {
if (exists name) {
print("Hello, ``name``!");
}
else {
print("Hello, world!");
}
}
Re: Why Maybe Is Better Than Null
#125Earlier quoted context omitted.
Yep, you've got it exactly right. The problem for dynamic type systems is how do you enforce 3? Do you care to?
I suppose you could write a sort of safe Maybe template class in c++. You could pass in two callbacks to handle Just and Nothing respectively. It would be really ugly, but should work, right?
Yeah, a function taking two callbacks is what I had in mind. This works in dynamic typed languages too, although obviously not as well.
Re: Why Maybe Is Better Than Null
#126Earlier quoted context omitted.
Sounds like a bad idea to me. Even though Num doesn't have an explicit contract, we sort of expect it to behave "nicely". But here we start with a nice ring like Integer and end up with a type that has this weird, extra element that has no inverse with respect to addition, etc.
For all fixed length two's complement integer types the smallest representable number has no additive inverse, too.
Prelude Data.Int> minBound + minBound :: Int16
0
Re: Why Maybe Is Better Than Null
#127If you work on types that might be null, you're bloody careful or you're in the wrong profession. We're not calling incompetent programmers a gazillion dollar mistake, even though they probably have caused as much.
Look everyone, dscrd has solved the problem of software having bugs. Just be careful! Man, why didn't anyone think of that before? The software industry is going to be so much nicer now that you eliminated bugs.
Thanks! Where can I pick up my Nobel?
Re: Why Maybe Is Better Than Null
#128If you work on types that might be null, you're bloody careful or you're in the wrong profession. We're not calling incompetent programmers a gazillion dollar mistake, even though they probably have caused as much.
Not everyone has the profession of herding spherical cows in vacuum ... in the real world lots of stuff can bait you in the ass.
I'm very amused. About 80% of my career has been in the "real world", so I have actually have some authority in calling this. No power in the world can subvert incompetence.
Re: Why Maybe Is Better Than Null
#129Earlier quoted context omitted.
>That pattern just turns out to be very useful. Like NaN, it can be hard to track down where things went wrong.
Except contrary to NaN, the type system encodes where it can exist and what its span is.
Right, you can rule out the pieces that are typed as "NaN-free" - hopefully that's a lot.
This is a great reason to avoid huge chunks of code stitched together staying inside Maybe, while still being convenient on the small scale.
Re: Why Maybe Is Better Than Null
#130I can't believe there is no mention of Ceylon here. Ceylon has an elegant approach to this using union types. Typesafe null and flow-dependent typing There's no NullPointerException in Ceylon, nor anything similar. Ceylon requires us to be explicit when we declare a value that might be null, or a function that might return null. For example, if name might be null, we must declare it like this: String? name = ... Whic…
C# does this too, but only for primitive types (per my understanding).