5 ms·
Reinventing the wheel can also lead to difficult-to-find bugs that explode years down the road. Yeah, you could reimplement the parts of zlib you need in a coup
by AlotOfReading 4y ago
Reinventing the wheel can also lead to difficult-to-find bugs that explode years down the road. Yeah, you could reimplement the parts of zlib you need in a couple hours, but just use zlib, even if it's a core part of your functionality.
However, as an industry we don't have a great way to know what is or isn't reliable. I've started publishing component datasheets with my utility libraries because that conveys the sort of commoditization I think we should strive for, but they haven't been very useful so far.
- ChrisMarshallNY 4y ago> However, as an industry we don't have a great way to know what is or isn't reliable. That's the rub. Your zlib example is one of the "Platonic Ideal of Quality Open Source" libraries. Using that is a no-brainer. Any suggestion of rating/licensing/qualifying open-source projects, is met with ... resistance ...
- GoblinSlayer 4y agoIt's still a full plate of old good C spaghetti https://github.com/madler/zlib/commit/eff308af425b67093bab25f80f1ae950166bece1 https://github.com/madler/zlib/commit/eff308af425b67093bab25...
- randomdata 4y ago> However, as an industry we don't have a great way to know what is or isn't reliable. I'm not sure it matters. You can assume it will be as reliable as your own buggy code that you wrote yourself. The more important question is how maintainable or replaceable is it. Once you include a dependency it becomes your code to maintain, so it had better be something that you're comfortable jumping in and getting your hands dirty with if need be.