5 ms·
> Specifically, I'm not convinced "all of the null pointer bugs" would have simply been erased and replaced with good working software. Rather, I tend to think
by Dewie 12y ago
> Specifically, I'm not convinced "all of the null pointer bugs" would have simply been erased and replaced with good working software. Rather, I tend to think they would have just been replaced with similar bugs.
This reads to me like eliminating null pointer bugs would just create a void that something else would fill? I don't see how that would work, at all. Is eliminating a null pointer exception going to introduce a divide by zero exception/bug? Is it going to introduce program logic bug? ...
If you're thinking about unwrapping a nullable value and throwing an exception if it really is null; I don't think of that as a conceptual null pointer exception, at least not in the usual sense. It's a deliberate decision along the lines of "I know [because of the control flow up to this point] that this value can not be null" or "if it is null, just throw an exception". It is NOT "this value can never be null... I think... well let's check the documentation, OK I'll assume that it isn't being misleading (documentation can easily 'lie' about a value being null in a nullable-by-default language, since non-nullable is not expressible in the language).
In a language with nullable-always, you can always pass a value (probably reference, but still) as null. In a language with explicitly nullable types, this is impossible. That's why unwrap functions throw an exception if the value is null: there is no other way to handle that case in a typed manner (well, I guess you also could loop forever...). In a nullable-by-default language? It is always fine to pass null. And it will not necessarily fail if a null is passed that shouldn't have been passed: it will only error when the reference is (tried to be) dereferenced.
- dllthomas 12y agoIt may introduce a program logic bug. Or arguably, it may have already been a program logic bug that remains a program logic bug. I would be tremendously surprised if this was close to 100% of the time, though, and even at 50% we're putting a good dent in our bugs (with, of course, plenty remaining, but that's no reason to forgo this).
- taeric 12y agoMy main hypothesis, which I of course never said, is that current static analysis tools should be able to catch the majority of these cases anyway. Especially the ones that matter. That is, a type system is not the only tool we have in static analysis. So, I'm not completely convinced that moving to a type system is the best way to go. Granted, it large part, it is clear it doesn't matter "what I think." Statically typed languages have a massive amount of support.
- dllthomas 12y agoWith the isomorphism between proofs and types, most of the stronger guarantees that any static analysis tool can give you are in some sense types. General "smell" type linting stuff, perhaps not.
- taeric 12y agoMakes sense, and I'd imagine that in large part that the theory behind them is the same. The practice of the two is different, though. Specifically, majority of the static typing regimes seem to demand a change in how software is written. Whereas most of the static analysis seem to simply provide stronger guarantees on what you are already writing. That is a huge difference.
- dllthomas 12y agoI think this is an artifact of the code you find yourself wanting to write relying on guarantees closer to the type system the static analysis tool applies (implicitly or explicitly). Some of this probably varies by domain, some by language, some by familiarity with particular type systems, and some simply by individual.
- chongli 12y agoThat is, a type system is not the only tool we have in static analysis. It's not the only tool but it's one of the better ones. It's faster, more reliable and more well-researched than almost any other tool.