Comment by duped
2 years ago
> But what about an archived project that does exactly what you need it to do, has 0 bugs, and has been stable for years? That’s like finding a hidden gem in a thrift store!
Either the library is so trivial to implement myself that I just do that anyway, which doesn't have issues w.r.t maintenance or licensing, or it's unmaintained and there are bugs that won't be fixed because it's unmaintained and now I need to fork and fix it, taking on a legal burden with licensing in addition to maintenance.
Bugs happen all the time for mundane reasons. A transitive dependency updated and now an API has a breaking change but the upstream has security fixes. Compilers updated and now a weird combination of preprocessor flags causes a build failure. And so on.
The idea that a piece of software that works today will work tomorrow is a myth for anything non-trivial, which is why checking the history is a useful smell test.
Consider an at-the-time novel hashing algorithm, e.g. Keccak.
• It's decidedly non-trivial — you'd have to 1. be a mathematician/cryptographer, and then 2. read the paper describing the algorithm and really understand it, before you could implement it.
• But also, it's usually just one file with a few hundred lines of C that just manipulates stack variables to turn a block of memory into another block of memory. Nothing that changes with new versions of the language. Nothing that rots. Uses so few language features it would have compiled the same 40 years ago.
Someone writes such code once; nobody ever modifies it again. No bugs, unless they're bugs in the algorithm described by the paper. Almost all libraries in HLLs are FFI wrappers for the same one core low-level reference implementation.
In practice, this code will use a variety of target-specific optimizations or compiler intrinsics blocked behind #ifdefs that need to be periodically updated or added for new targets and toolchains. If it refers to any kind of OS-specific APIs (like RNG) then it will also need to be updated from time to time as those APIs change.
That's not to say that code can't change slowly, just the idea that it never changes is extremely rare in practice.
Keccak is perhaps not the best example to pick. https://mouha.be/sha-3-buffer-overflow/
I submit math.JS and numeric.JS. Math.JS has an incredibly active community and all sorts of commits numeric. JS is one file of JavaScript and hasn’t had an update in eight years if you want to multiply 2 30 by 30 matrices, numeric.JS works just fine in 2023 and is literally 20 times faster.
I'm checking the zlib changes file [1] and there are regular gaps of years between versions (but there are times where there are a few months between versions). zlib is a very stable library and I doubt the API has changed all that much in 30 years.
[1] https://www.zlib.net/ChangeLog.txt