Hacker News new | ask | show | jobs
by hyperpallium 3914 days ago
What about reducing bugs through code reuse, in the form of libraries and frameworks? Because they have more users, more bugs have been found, reported and fixed. e.g. using standard libraries instead of writing your own.
3 comments

code reuse is actually dangerous though. It's possible to use a library, have an expectation on how it will work, and then forget about that assumption, upgrade/fix something in the library, and proceed to break your assumption. It's a pretty common problem.

Often the time saved using a library is worth the small risk, but if we're talking about "how to write correct software" you'll want to be weary of code reuse.

That works only when the quality of the libraries and frameworks are high. When they are crap, you just spread the pain around and you've made things worse.
Most libraries found in the wild are kinda crap, because as an industry we have a massive problem where most of our stuff is built on free labour that people have performed in their spare time to scratch their own itch.

Using libraries is still generally a good idea, but its effect on software correctness is a bit of a coin toss.

Yes, libraries and frameworks vary in quality. My e.g, was for "standard libraries", meaning those that come with the language, though I didn't emphasise this.

Another problem with libraries in the wild is that as they add features, they add bugs. If they don't add features, they lose popularity and don't get used. If they are commercial, they are less popular, and get fewer bug reports (and fewer eyeballs checking for closed source). People don't want to pay for correctness.

I think you're right: correctness is pretty far down the priority list. Good enough is good enough.

BTW: static types have correctness benefits, but dynamically typed languages are very popular - and when static types are used, it's for performance and documentation. Languages using static types for correctness (e.g. ML family and haskell) are not mainstream.