[derefr]

Writing foundational algorithms/data-structures libraries (e.g. language-runtime stdlibs like libc) is usually treated as a sort of sacred ritual in programming—something where it’s “obvious” that it should be done slowly, carefully, and without distraction, with each change audited carefully by many peers before accepting a merge.

It’s not often that you’re writing such code “in anger”, under time-pressure to ship to fix downtime, with no time to get peer review.

This is in large part because the downstream client of an algorithms/data structures library, would almost-always prefer a robust but less-efficient option, over an alpha-quality implementation of a more-efficient option. Dataset-size scaling challenges that recommend algorithmic efficiency increases can, almost always, be temporarily put off by “throwing machines at the problem” until the more-efficient library becomes high-quality enough to be fully relied upon. Until then, the business logic will make do with the simpler/more naive algorithm.

And in most language runtimes, there’s a simpler/more naive algorithm or data structure to solve every problem already laying around in the core stdlib; so it’s not like you, as the library writer, have to implement that code “in anger” either. Your internal customers can upgrade from depending on stdlib types, to depending on your lib’s types, when using your lib becomes an unalloyed win for them; and until then, do nothing.

[DSMan195276]

> Writing foundational algorithms/data-structures libraries (e.g. language-runtime stdlibs like libc) is usually treated as a sort of sacred ritual in programming—something where it’s “obvious” that it should be done slowly, carefully, and without distraction, with each change audited carefully by many peers before accepting a merge.

I'll be honest, I think you're vastly overestimating how well these things are actually developed :) I agree with what you said, I just found this part a little bit funny.

[derefr]

What I really meant, without the fancy language, is that stdlib programmers are crotchety greybeards who don't like change-for-change-sake and so default-deny rather than default-accept random patches. That by itself creates a very different level of stability in these projects, where things only ever change if they really need to to fix a specific bug—and even then, the change is pared down to have as little architectural effect as possible.