4 ms·
But when the type system can ensure that you handle nil values safely and can check that every case is covered in a switch statement I'm sure that covers more t
by josephlord 12y ago
But when the type system can ensure that you handle nil values safely and can check that every case is covered in a switch statement I'm sure that covers more than 2% of bugs.
- mpweiher 12y agoWhy are you sure?
- NotAtWork 12y agoNot properly guarding for None has been over 2% of my bugs in working with Python. I'd guess it's more like 5-10%. There's probably another 5-10% that are problems dealing with trying to uniformly iterate over different kinds of structures, but I'm willing to admit I might just not know the correct way to do it (ie, map or fold or something).
- actsasbuffoon 12y agoThe interesting thing is that the majority of statically-typed languages wouldn't catch the null for you. C, C++, Java, C#, and many others accept null as a valid input for any type. There are plenty of languages like Haskell, Haxe, Idris, Agda, Roy, Rust, and Elm that get this right. Anecdotally it seems that most developers who advocate static typing aren't using these languages. It seems like the majority are writing in one of the Algol derived languages from the first paragraph. Scala gets it half right with Option, but included null for Java compat. I've not written much Scala, but I've already encountered numerous bugs that resulted from some library returning an unexpected null, and the type system decided that was totally fine.
- josephlord 12y agoYes C/C++ are pretty weakly typed and Null pointers are an issue in them all. They still catch some issues though and I find it does help me sometimes compared with Ruby for example. If they only caught 2% of the issues I would be a little surprised but it is certainly in the range of possibilities depending on the stage of development (I think it would catch more as you type your code but possibly 2% or less when evaluating a finished, debugged tested product). You can also add Swift to the list of languages that get it right in this regard. When receiving a return value from obj-c that can be null it comes back as an optional so you SHOULD safely transform it to a real value or only perform conditional actions on it. Of course there is the possibility to coerce it into the full type.
- anonymoushn 12y agoProbably experience. I can confirm this based on my work in dynamic languages. I don't check in most of these bugs though, so the methodology used to arrive at 2% would miss them.
- adamnemecek 12y agohttp://www.impredicative.com/ur http://www.impredicative.com/ur Bam, static typing system that prevents a bunch of those exploits from the list of 25 most exploited bugs. The generics paper is not exactly relevant. Or I'm not quite sure what it's supposed to prove. The other research paper is kind of disingenuous: a.) They measure programmer productivity on a small, 27 hour project. Advantages of static typing grow proportionally with the size of the project. I personally am of the opinion that scripting languages are ok for smaller projects, but not that great for larger projects. b.) They use two custom languages, one inspired by Smalltalk, one inspired by Java and based on the results make a pretty general conclusion about static typing. I'm not convinced that such conclusion can be made based on the experiments they present.
- josephlord 12y agoExperience. Tony Hoare's speech about being to blame for nil and the estimate the financial damage caused. I'm also suspect I've seen a coverage of a research doc about bugs where nils were a noticeable share but I've no idea where that is. One of the recent bugs in my app that was causing a crash from time to time involved the platform library returning nil when there was no user input in the text field rather than the empty string it promised in the doc.