3 ms·

One of the problem's Maybe still has is in the deeper question of "why are you expecting None to be here?". Don't get me wrong, there are valid cases for this,

One of the problem's Maybe still has is in the deeper question of "why are you expecting None to be here?". Don't get me wrong, there are valid cases for this, and Maybe is certainly preferable to null across the board, but I think the movement to Maybe in the greater programming space will in many cases practically result in trading one set of explicit errors (crashes) for (a more subtle?) set of errors (behavioral). In particular, this style of programming will become frequent (from Swift documentation): if let roomCount = john.residence?.numberOfRooms { println("John's residence has \(roomCount) room(s).") } else { println("Unable to retrieve the number of rooms.") } Or from this blog post's own example: option.ifPresent(x -> System.out.println(x)); In other words, I think the core problem still hasn't been attacked and we may end up in the same situation we were in with exceptions originally: programmers will just throw up their hands and wrap everything in a Maybe/Optional and/or just maybe-protect until the compiler stops bugging them. At the end of the day, if you ? all your values then you end up with something equivalent to having everything be nullable and correctly null-checking them. Obj-C had a form of this with nil calling of methods silently doing nothing (so you end up with methods that "conveniently" don't happen, and don't crash! when the receiver is nil). However, despite having lots of legitimate uses (don't bother checking your delegate exists), it can still very silently sneak in to other parts of the code.

fixermark 11y ago
This is a concern, but the advantage to Maybe is it makes this concern very explicit. SML/NJ code will not compile if you don't have a binding to handle the None for an option 'a type. The programmer does of course then have the option of doing None => raise Error but practically speaking, when deciding it's time to make your code more robust, it's a lot easier to text search for instances of "None => raise" than to search for the absence of proper handling of the possibility of a null arg or return value.
- paulddraper 11y ago
  Exactly. You can still get errors due to things not being there. But your assumptions are explicitly stated. You see None => raise Error, and a little alarm goes off in your head, and you look around for a reassurance that we really want to do that. In contrast, you don't give x.toUpperCase() a second glance.
evincarofautumn 11y ago
You seem to be saying that developers can make logic errors despite expressive types. Of course that’s true—type systems are a first pass to absolve us from the trivial errors that otherwise waste our time. I don’t agree that lazy programmers will add optionality to please compilers rather than fix their program logic. In languages where optional types are ubiquitous, you usually see people avoiding needless optionality, because it’s simply easier.
ivm 11y ago
> Obj-C had a form of this with nil calling of methods silently doing nothing (so you end up with methods that "conveniently" don't happen, and don't crash! when the receiver is nil). For me it is the worst part of Objective-C. Instead of getting a crash at nil, you will get a weird program behavior later because something wasn't called. And I never use this feature because it complicates code flow and brings no benefits.

fixermark 11y ago

This is a concern, but the advantage to Maybe is it makes this concern very explicit. SML/NJ code will not compile if you don't have a binding to handle the None for an option 'a type. The programmer does of course then have the option of doing None => raise Error but practically speaking, when deciding it's time to make your code more robust, it's a lot easier to text search for instances of "None => raise" than to search for the absence of proper handling of the possibility of a null arg or return value.

paulddraper 11y ago
Exactly. You can still get errors due to things not being there. But your assumptions are explicitly stated. You see None => raise Error, and a little alarm goes off in your head, and you look around for a reassurance that we really want to do that. In contrast, you don't give x.toUpperCase() a second glance.

evincarofautumn 11y ago

You seem to be saying that developers can make logic errors despite expressive types. Of course that’s true—type systems are a first pass to absolve us from the trivial errors that otherwise waste our time. I don’t agree that lazy programmers will add optionality to please compilers rather than fix their program logic. In languages where optional types are ubiquitous, you usually see people avoiding needless optionality, because it’s simply easier.

ivm 11y ago

> Obj-C had a form of this with nil calling of methods silently doing nothing (so you end up with methods that "conveniently" don't happen, and don't crash! when the receiver is nil). For me it is the worst part of Objective-C. Instead of getting a crash at nil, you will get a weird program behavior later because something wasn't called. And I never use this feature because it complicates code flow and brings no benefits.