|
|
|
|
|
by zak_mc_kracken
4181 days ago
|
|
> Looks like an interesting idea to eliminate the class of NPE runtime errors, yet it’s a special language (and syntax!) construct. It therefore does not arise out of the type system, but is explicitely built into the type system, so it doesn’t scale. [Citation needed] Groovy, Ceylon and Kotlin prove that this approach has a lot of merits. > See Haskell’s Maybe type on how to eleminate NPE’s with a small, trivial type that is no more special than any other. Your claim that `Maybe` solves this better is dubious. Yes, it's nice to have this support emerging naturally from the type system but the downside is that you are now wrapping all your nullable values in monads, and if these values are already monads, you enter monad transformer hell (and it spreads to all the function signatures in your entire code base). Of course, there's also the fact that because all these values are now monads, you can only interact with them through layers of flatMaps, which generate a lot of nested and then unnested values along the way. It's quite inefficient. The approach used by Nit and the other three languages I gave above is much more lightweight and, in my opinion, a much more reasonable compromise. |
|
In addition to dragonwriter's objection, this is basically wrong. You can deal with wrapped maybes without touching monad transformers. Further, MaybeT is quite convenient when you have a lot of operatons that may fail, and you want to give up on the chain if they do. It doesn't spread arbitrarily far, though - at any point you can runMaybeT to turn (MaybeT m a) into (m (Maybe a)), for any Monad m.
In general, monad transformers don't propagate crazy far unless they need data that's only available crazy far away.