8 ms·

Null, empty string, empty value, Undefined etc. are the biggest causes of crashes,edge case bugs and a big time sink programming and data handling. Wish languag

Null, empty string, empty value, Undefined etc. are the biggest causes of crashes,edge case bugs and a big time sink programming and data handling. Wish languages had better support to handle straightforward cases instead of just crashing.

wvenable 12y ago
Crashing is ok. The problem is that it usually doesn't crash in the right spot. A null is generated somewhere else and propagated around for a while and the crash happens later in a unrelated area. But it's even worse if it doesn't crash at all.
taeric 12y ago
This is close to saying that lack of oxygen is the number one killer in drownings. That is, when you are in that situation there is a lot going wrong. So, sure, you got rid of null from the language. Does your program handle the case where it was handed a negative number correctly? All positive values? All unicode? Consider, in the Ariane Rocket incident, they were using a dependently typed language. Didn't magically prevent errors in assembly. So, fine, we'll make our programs where they handle all cases... Rapid prototyping probably just flew out the window. As did worrying about actual honest to goodness use cases. A great quote by Knuth I saw once was where he acknowledged that tex would choke on mile wide documents. But who cares?
- Dewie 12y ago
  > So, sure, you got rid of null from the language. Does your program handle the case where it was handed a negative number correctly? All positive values? All unicode? Aren't you just moving the goal post? You can play the 'OK so you can eliminate that from the equation, but can you ...' indefinitely. Well, perhaps only until you get to the question of cosmic rays. > So, fine, we'll make our programs where they handle all cases... Rapid prototyping probably just flew out the window. As did worrying about actual honest to goodness use cases. The topic is a few special cases, like null, not every conceivable case. If things like null and undefined cause the majority of crashes, and they are simple to handle with a 'proper' language (and they are), then you already have gotten a lot of bang for your buck. For rapid prototyping: if handling null cases is too much, use a function that unwraps nullable values directly, and if they are null, crashes (and no, this is not the same as a null pointer exception). Then go back and clean up the program when you are not prototyping quite as rapidly anymore.
  - taeric 12y ago
    That is my point, that this is really just moving some goal posts. So, we know that many programs didn't make it across the line with null as an option. Will they really do much better without it? I'm not convinced it is a sure thing. So, for example, a place where null comes up. When you create a file. Programs that didn't check just threw up on an exception now. It is just as likely that without that option, the code would have just checked for a value, or thrown an error. So... what changed?
    - scott_s 12y ago
      Maybe they don't throw an exception immediately. Maybe that null value gets stored somewhere, and you don't hit it until three hours later, when the system goes to save data to disk. Now your exception gets thrown far away from where the error occurred, both in terms of code and actual time. (For the record, I'm assuming an interface such as: fileOpen -> FileHandle Where the FileHandle object can be null, and it being null is used to indicate that the call to fileOpen failed.)
      - taeric 12y ago
        Couldn't that happen with an optional type, as well? Especially if you let it get inferred. Only when you go to use it would you realize you have to map over the value. And then you are back in the world of messed up.
        scott_s 12y ago
        It depends on the language, and the API of the libraries you use. If we have a Haskell-like Maybe type, you should be able to create functions that refuse to take a Maybe. That would force you to determine soon after the fileOpen call: did it succeed or not? To be clear, this would involve the static type system for your language forcing certain things to happen, or not compiling. The sequence: 1. fileOpen returned a Maybe<FileObject> 2. You want to store the FileObject somewhere, and it expects an actual FileObject. 3. Maybe<FileObject> is not itself a FileObject, so you have to figure out: is it Nothing, or a FileObject? 4. You have to handle the Nothing case (language forces you to, even if you do nothing about it - you explicitly decided to do nothing). 5. If it is indeed a FileObject, you store it for later use, and you are guaranteed it is, indeed, a FileObject.
- andolanra 12y ago
  Consider, in the Ariane Rocket incident, they were using a dependently typed language. Didn't magically prevent errors in assembly. Since when is Ada a dependently typed language? The actual code that caused the overflow can be read here[^1] and the report on the overflow can be read here[^2]. [^1]: http://en.wikipedia.org/wiki/Cluster_%28spacecraft%29#Arithmetic_overflow http://en.wikipedia.org/wiki/Cluster_%28spacecraft%29#Arithm... [^2]: http://sunnyday.mit.edu/nasa-class/Ariane5-report.html http://sunnyday.mit.edu/nasa-class/Ariane5-report.html
- tel 12y ago
  As far as I know Ada doesn't have dependent types.
  - taeric 12y ago
    Apologies, I had thought it was. (This goes to everyone that corrected me on this.) I can only guess that I got confused over reading about Agda at some point. Again, apologies.
- kjs3 12y ago
  The Ariane incident shows that if you combine misuse of type checks and practice poor software engineering methodologies you can get failure, not that proper use of the type system wouldn't have prevented it.
  - taeric 12y ago
    Right, my point is ultimately that proper software engineering methodologies means more than more powerful types.
    - deleted 12y ago
      [deleted]

wvenable 12y ago

Crashing is ok. The problem is that it usually doesn't crash in the right spot. A null is generated somewhere else and propagated around for a while and the crash happens later in a unrelated area. But it's even worse if it doesn't crash at all.

taeric 12y ago

This is close to saying that lack of oxygen is the number one killer in drownings. That is, when you are in that situation there is a lot going wrong. So, sure, you got rid of null from the language. Does your program handle the case where it was handed a negative number correctly? All positive values? All unicode? Consider, in the Ariane Rocket incident, they were using a dependently typed language. Didn't magically prevent errors in assembly. So, fine, we'll make our programs where they handle all cases... Rapid prototyping probably just flew out the window. As did worrying about actual honest to goodness use cases. A great quote by Knuth I saw once was where he acknowledged that tex would choke on mile wide documents. But who cares?

Dewie 12y ago
> So, sure, you got rid of null from the language. Does your program handle the case where it was handed a negative number correctly? All positive values? All unicode? Aren't you just moving the goal post? You can play the 'OK so you can eliminate that from the equation, but can you ...' indefinitely. Well, perhaps only until you get to the question of cosmic rays. > So, fine, we'll make our programs where they handle all cases... Rapid prototyping probably just flew out the window. As did worrying about actual honest to goodness use cases. The topic is a few special cases, like null, not every conceivable case. If things like null and undefined cause the majority of crashes, and they are simple to handle with a 'proper' language (and they are), then you already have gotten a lot of bang for your buck. For rapid prototyping: if handling null cases is too much, use a function that unwraps nullable values directly, and if they are null, crashes (and no, this is not the same as a null pointer exception). Then go back and clean up the program when you are not prototyping quite as rapidly anymore.
- taeric 12y ago
  That is my point, that this is really just moving some goal posts. So, we know that many programs didn't make it across the line with null as an option. Will they really do much better without it? I'm not convinced it is a sure thing. So, for example, a place where null comes up. When you create a file. Programs that didn't check just threw up on an exception now. It is just as likely that without that option, the code would have just checked for a value, or thrown an error. So... what changed?
  - scott_s 12y ago
    Maybe they don't throw an exception immediately. Maybe that null value gets stored somewhere, and you don't hit it until three hours later, when the system goes to save data to disk. Now your exception gets thrown far away from where the error occurred, both in terms of code and actual time. (For the record, I'm assuming an interface such as: fileOpen -> FileHandle Where the FileHandle object can be null, and it being null is used to indicate that the call to fileOpen failed.)
    - taeric 12y ago
      Couldn't that happen with an optional type, as well? Especially if you let it get inferred. Only when you go to use it would you realize you have to map over the value. And then you are back in the world of messed up.
      - scott_s 12y ago
        It depends on the language, and the API of the libraries you use. If we have a Haskell-like Maybe type, you should be able to create functions that refuse to take a Maybe. That would force you to determine soon after the fileOpen call: did it succeed or not? To be clear, this would involve the static type system for your language forcing certain things to happen, or not compiling. The sequence: 1. fileOpen returned a Maybe<FileObject> 2. You want to store the FileObject somewhere, and it expects an actual FileObject. 3. Maybe<FileObject> is not itself a FileObject, so you have to figure out: is it Nothing, or a FileObject? 4. You have to handle the Nothing case (language forces you to, even if you do nothing about it - you explicitly decided to do nothing). 5. If it is indeed a FileObject, you store it for later use, and you are guaranteed it is, indeed, a FileObject.
andolanra 12y ago
Consider, in the Ariane Rocket incident, they were using a dependently typed language. Didn't magically prevent errors in assembly. Since when is Ada a dependently typed language? The actual code that caused the overflow can be read here[^1] and the report on the overflow can be read here[^2]. [^1]: http://en.wikipedia.org/wiki/Cluster_%28spacecraft%29#Arithmetic_overflow http://en.wikipedia.org/wiki/Cluster_%28spacecraft%29#Arithm... [^2]: http://sunnyday.mit.edu/nasa-class/Ariane5-report.html http://sunnyday.mit.edu/nasa-class/Ariane5-report.html
tel 12y ago
As far as I know Ada doesn't have dependent types.
- taeric 12y ago
  Apologies, I had thought it was. (This goes to everyone that corrected me on this.) I can only guess that I got confused over reading about Agda at some point. Again, apologies.
kjs3 12y ago
The Ariane incident shows that if you combine misuse of type checks and practice poor software engineering methodologies you can get failure, not that proper use of the type system wouldn't have prevented it.
- taeric 12y ago
  Right, my point is ultimately that proper software engineering methodologies means more than more powerful types.
  - deleted 12y ago
    [deleted]