3 ms·

Because humans are the constraint, not the bits. Humans (in a group, societal sense) need to context switch over time, and cannot perfectly retain equal, active

Because humans are the constraint, not the bits. Humans (in a group, societal sense) need to context switch over time, and cannot perfectly retain equal, active understanding of how to use all systems or frameworks ever invented, no matter how perfectly the bits are preserved. That being said, in an archival sense, it would be a shame and seems unnecessary to lose anything, since perfect preservation is achievable. But archival preservation, is different from staying in active use with a healthy community of practitioners perpetually ad infinitum.

dmix 5y ago
That’s a really good point, there can exist a distinction where the goal should be to make it always accessible (archives, emulation, documentation, etc) but not necessarily always accessible in widely deployed web browsers. So even if you have good reasons to remove an API or feature, you should also provide means or resources to those who wish to preserve and archive the data. And this is something that could be factored into the original design without committing the project to the technical overhead of supporting it forever. Additionally reducing the problem to humans just chasing shiny new things is simply not true. There’s no denying that some implementations are just bad or dangerous security wise or the world has completely changed in some way. Not letting things decay could risk the whole platform dying as a result, not just the feature. It could even get to the point where adding anything new is way too risky because of long term support obligations, so decay could be made worse because of efforts to prevent decay! Obviously we can still make sure great consideration is made both before adding something new and before removing it. There’s no getting away from the balancing act between change and conservation.

3 ms·

Because humans are the constraint, not the bits. Humans (in a group, societal sense) need to context switch over time, and cannot perfectly retain equal, active

by strgcmc 5y ago

dmix 5y ago
That’s a really good point, there can exist a distinction where the goal should be to make it always accessible (archives, emulation, documentation, etc) but not necessarily always accessible in widely deployed web browsers. So even if you have good reasons to remove an API or feature, you should also provide means or resources to those who wish to preserve and archive the data. And this is something that could be factored into the original design without committing the project to the technical overhead of supporting it forever. Additionally reducing the problem to humans just chasing shiny new things is simply not true. There’s no denying that some implementations are just bad or dangerous security wise or the world has completely changed in some way. Not letting things decay could risk the whole platform dying as a result, not just the feature. It could even get to the point where adding anything new is way too risky because of long term support obligations, so decay could be made worse because of efforts to prevent decay! Obviously we can still make sure great consideration is made both before adding something new and before removing it. There’s no getting away from the balancing act between change and conservation.