4 ms·
> wouldn't it be better to a) code f defensively in the first place, In Haskell, you don't have to. If your function takes a String as an argument, for instanc
by tmhedberg 15y ago
> wouldn't it be better to a) code f defensively in the first place,
In Haskell, you don't have to. If your function takes a String as an argument, for instance, the compiler will ensure that it never receives a null instead. It will always receive an actual String, because normal types are non-nullable in Haskell. You have to explicitly wrap a type in a Maybe if you want to add nullability, and `Maybe String` is a completely different type from `String`, so the type checker can and will enforce that they don't improperly intermingle.
> and b) not call f with invalid parameters?
Same story here. If f takes a String argument, you can't (deliberately or by accident) pass it a Maybe String instead, or your code simply won't compile. The strong static type system in Haskell eliminates the mental burden of having to always watch out for nulls and handle them as a special case.
That may not seem like much of a burden if you're accustomed to languages like Python, Java, etc. where nullability is the default. But think about how much time you've spent dealing with NullPointerExceptions (or the equivalent in your language of choice) and imagine how much nicer it would be if the language itself could simply eliminate the possibility of them ever occurring in the first place. Well, thanks to its type system, Haskell can do that.
- _delirium 15y agoI agree, but that particular issue can be fixed with a type system tweak instead, to treat nullability as a type modifier, vaguely like constness, which can then be statically enforced. Cyclone adds nullability annotations to C, for example, and Ada has a "null exclusion" type modifier.
- tmhedberg 15y agoThe advantage to Haskell's type constructor approach, though, is extensibility. Making nullability a language keyword like `const` requires a change to the fundamental grammar of the language. In Haskell, `Maybe a` is just another data type, defined entirely in Haskell itself. This opens the door to allowing users of the language to create arbitrary type system constraints without having to modify the compiler to support them.
- icebraining 15y agoPython doesn't have nullability, you must always pass some object; None is just an object like any other /pedant.
- ehutch79 15y agoI'm not asking about haskell though, I was asking what the valid reasons for that python code being written.
- tmhedberg 15y agoI'm pretty sure that the author of the article didn't mean to imply that you should actually define monads explicitly in Python and start using them in your code. That would be inelegant, far from idiomatic, and mostly pointless, since Python doesn't type-check your code like Haskell does, and most of the advantages of an explicit Monad class arise from its usage in the presence of a strong type system. The example snippet was likely just an illustrative example, using Python merely because it's a more widely understood language than Haskell. If he wrote it in Haskell, then not only would it be redundant (since monads are already defined in that language), but it would be less comprehensible to the intended audience of new and non-Haskell programmers.