4 ms·

You are making some really good points. One thing I would like to observe is that all the languages that you are citing that don't implement nil also implement

by zimbatm 11y ago

You are making some really good points. One thing I would like to observe is that all the languages that you are citing that don't implement nil also implement patter-matching. All have something equivalent to the Haskell Maybe type which needs to unwrap the value upon utilization. I would be open to admit that nil is an absolute mistake if you can demonstrate that unwrapping is as convenient as just checking for nil and then using the value (or present another mechanism that is as convenient). In regards to possible class of errors in Haskell I can think of a few: any non-terminating program, any program that blows up the memory. It's possible to implement a Monad that doesn't obey the monadic laws. It's possible to inverse the order of arguments inadvertently if they have the same type. Any insufficiently specified type, like using Int when only a range of Int is acceptable or any String when only a URL is acceptable. I'm sure there are more ;)

catnaroek 11y ago
> if you can demonstrate that unwrapping is as convenient as just checking for nil and then using the value. If you want to build a largefail at any point computation that may abort at any point in the middle, you can use the MaybeT monad transformer. Or EitherT, if you want to supply an error message when you fail. Inside a `do` block, it looks just the same as imperative code. So no syntactic convenience is lost. But the real benefit, at least in my opinion, is the ability to design APIs that allow less room for error. In the vast majority of cases, pointers and references simply aren't intended to be nullable in the first place. > It's possible to implement a Monad that doesn't obey the monadic laws. And it's possible to overload operators in C++ in ways that make no sense whatsoever as well. (Using the same operator for bit shifting and stream I/O, seriously?) At least Haskell has a culture of associating laws to type classes. > It's possible to inverse[sic] the order of arguments inadvertently if they have the same type. No worse than any other language. If anything, Haskell's type system makes more distinctions, so this specific error is less likely. > Any insufficiently specified type, like using Int when only a range of Int is acceptable or any String when only a URL is acceptable. Idiomatic Haskell would make custom types, with smart constructors if necessary. Using String when a URL is expected is simply bad API design in Haskell. --- But, anyway, I'd rather not continue this subthread, since the topic is Go.

by zimbatm 11y ago

catnaroek 11y ago

> if you can demonstrate that unwrapping is as convenient as just checking for nil and then using the value. If you want to build a largefail at any point computation that may abort at any point in the middle, you can use the MaybeT monad transformer. Or EitherT, if you want to supply an error message when you fail. Inside a `do` block, it looks just the same as imperative code. So no syntactic convenience is lost. But the real benefit, at least in my opinion, is the ability to design APIs that allow less room for error. In the vast majority of cases, pointers and references simply aren't intended to be nullable in the first place. > It's possible to implement a Monad that doesn't obey the monadic laws. And it's possible to overload operators in C++ in ways that make no sense whatsoever as well. (Using the same operator for bit shifting and stream I/O, seriously?) At least Haskell has a culture of associating laws to type classes. > It's possible to inverse[sic] the order of arguments inadvertently if they have the same type. No worse than any other language. If anything, Haskell's type system makes more distinctions, so this specific error is less likely. > Any insufficiently specified type, like using Int when only a range of Int is acceptable or any String when only a URL is acceptable. Idiomatic Haskell would make custom types, with smart constructors if necessary. Using String when a URL is expected is simply bad API design in Haskell. --- But, anyway, I'd rather not continue this subthread, since the topic is Go.