4 ms·

Concentrating on NPEs and stuff like sum times is misunderstanding the problems with software quality to the point of misunderstanding the magnitude of impact o

Concentrating on NPEs and stuff like sum times is misunderstanding the problems with software quality to the point of misunderstanding the magnitude of impact of different flaws. Working tightly with QA for over ten years by now, I can assure you that NPEs are exceptionally rare in bug reports filed by QA. No matter if that's a common problem in the language the application is written in (eg. Java or C++) or virtually nonexistent (eg. Kotlin or Haskell). Here are some examples of more common bugs: * Misunderstanding of the desired functionality (eg. giving admin permissions to regular users). * Not being able to predict all valid input forms (eg. user names with accented characters). * Forgetting to handle errors coming from multiple levels below the immediate level that's being worked with (eg. dealing with SSL-related problems in HTTP client / server communication). * Simply forgetting to implement some uncommon bit of functionality (usually related to cleanups, deletion etc.) ---- Currently in-use programming languages have roughly the same ability to deal with these, as I call them, "macro-problems" of programs. All of them are equally ill-equipped and unprepared for them. Tightening the type system or chasing after nulls is working at a resolution that's too fine. At this resolution programmers usually still have a good chance of figuring out the problems without the aid of types or similar automation.

JambalayaJim 3y ago
NPE safety and sum times deal with issues that developers face on the day to day, long before the product ever gets used by end users in the first place. NPE issues are also very very difficult to chase down.
- crabbone 3y ago
  I'm talking about QA, not end-users. "very very difficult" on what scale? How many "verys" before it gets really hard? Again, the proof is in the pudding. You take a language that doesn't make any special efforts to protect against nulls (eg. Java), and you take Kotlin that does, and the difference in the number of problems associated with NPEs is barely noticeable. Perhaps some automation offered by Kotlin for dealing with NPEs makes developers' experience more pleasant / easier, but the Java side just isn't hard enough to make this a substantial benefit. And, just to not be misunderstood: I'm not saying that automation in how to deal with missing values is bad, not at all! It's good. But, strategically, there are much bigger problems / juicier targets than NPEs. If you compare this to health, then NPEs are a headache, while misunderstood requirements are a cancer. It's great if you can treat both, but if you have limited resources, then cancer gets a priority treatment.

JambalayaJim 3y ago

NPE safety and sum times deal with issues that developers face on the day to day, long before the product ever gets used by end users in the first place. NPE issues are also very very difficult to chase down.

crabbone 3y ago
I'm talking about QA, not end-users. "very very difficult" on what scale? How many "verys" before it gets really hard? Again, the proof is in the pudding. You take a language that doesn't make any special efforts to protect against nulls (eg. Java), and you take Kotlin that does, and the difference in the number of problems associated with NPEs is barely noticeable. Perhaps some automation offered by Kotlin for dealing with NPEs makes developers' experience more pleasant / easier, but the Java side just isn't hard enough to make this a substantial benefit. And, just to not be misunderstood: I'm not saying that automation in how to deal with missing values is bad, not at all! It's good. But, strategically, there are much bigger problems / juicier targets than NPEs. If you compare this to health, then NPEs are a headache, while misunderstood requirements are a cancer. It's great if you can treat both, but if you have limited resources, then cancer gets a priority treatment.