3 ms·
> every single NoneType error I have gotten using in the python I'm paid to write would go away with a static type system. Not true. Java has NullPointerExcept
by irahul 14y ago
> every single NoneType error I have gotten using in the python I'm paid to write would go away with a static type system.
Not true. Java has NullPointerException, and static typing does nothing to prevent it. Java doesn't have Maybe, or Option or whatever you call it, but `Option.IsNone` isn't any different from `if (obj == null)`.
> Every single function I've changed the signature of and then failed to change one caller would go away with a static type system.
Yes, static type systems are great for that. But if you are using Python, use pylint and rope.
> If I had Haskell's good type inference, I wouldn't have had to do any of this time-wasting endeavor.
I don't know about you but changing signatures is very low in my list of pain-points. If it's solved for my environment, superb. If it's not, it will sting once in a while but that's that.
- rednum 14y agoIt is worth noting that in Haskell you don't have something like NullPointerException (the type system won't allow for that), and using Maybe actually is a bit different than writing 'if (obj != null)' everywhere, if you are into stuff like monads or functors. Besides, in Java null pointer can pop up pretty much everywhere, but in Haskell you probably shouldn't store all your data in Maybe.
- irahul 14y ago> It is worth noting that in Haskell you don't have something like NullPointerException, the type system doesn't allow for that - so while you're point is relevant to Java it doesn't hold here. The closest you can get to something like null pointer is using 'maybe' type, but when you do so, you have to everywhere explicitly handle what happens if variable has no value (or the value of 'nothing' more precisely). Which, as I mentioned, isn't any different from checking from nulls everywhere. Or if you are so inclined, write an Option class with the desired interface and use it everywhere where the value in nullable. My point is using Maybe is the same as manually checking for null. case maybeValue of Just value -> ... Nothing -> ... is the same as if (val != null) { .... } else { ... } If you see the compiler forcing you to always use Maybe for nullable types as an advantage, good for you. Personally, I don't see it as a big deal.
- rednum 14y agoThat's right, I've changed my comment to be more relevant reply, sorry for confusion. > If you see the compiler forcing you to always use Maybe as an advantage, good for you. Personally, I don't see it as a big deal. One of reasons I like Maybe is I can accidentally put null somewhere I know I should not; Haskell's type system will prevent me from that. I wouldn't use Maybe unless I really need to - whereas in languages with less strict type systems, almost everything is a 'Maybe'. Besides, it seems it's easier to build some layer on abstraction on it, which you can reuse and save some time (for example, you have monad instance for it - however I don't think I've ever used it).
- irahul 14y ago> whereas in languages with less strict type systems, almost everything is a 'Maybe' I don't know Haskell(I do know F#), so help me with this: How is everything not a Maybe in Haskell? In the languages I know, when you return an object from a method, (it can throw an Exception or return null) or return a valid val. When it throws an Exception, there is no Maybe, or else it's a Maybe. How is it any different in Haskell.
- CookWithMe 14y ago> isn't any different from checking from nulls everywhere You would only check for nulls "everywhere" if all functions could potentially return null. Then, indeed, there is no difference. But (hopefully) not all functions will return null, so you'll probably have at most a single-digit percentage of functions that do. The point is that by using Option, you are explicitly stating "This function can return null", making it impossible for the caller to ignore. If you write it somewhere into the docs, it is indeed easy to overlook. This may not be as relevant when you are only working with your own code, but I find this (and static typing in general) most helpful when dealing with code from someone else, including the libraries one uses.
- irahul 14y ago> But (hopefully) not all functions will return null, so you'll probably have at most a single-digit percentage of functions that do. In a real world API, almost everything that returns an object can return null or throw an exception. > The point is that by using Option, you are explicitly stating "This function can return null", making it impossible for the caller to ignore. Throw an exception if impossible to ignore is the motive. > If you write it somewhere into the docs, it is indeed easy to overlook. It might be overlooked. But is it too much to assume that someone making a call will check the parameters and the return type?