5 ms·
Well, to me it seems like he just shared the original so that others could benefit from the work he had already done, but that since his main priority is to con
by Jorge1o1 1y ago
Well, to me it seems like he just shared the original so that others could benefit from the work he had already done, but that since his main priority is to continue making new videos, he may not have the time resources to:
- Avoid breaking changes
- Keep APIs stable
- Test and document everything, etc.
I personally think there's nothing wrong with that. We wouldn't say that a musician is *obligated* to put out a second album or a remaster. We wouldn't say that an author *must* make a sequel to their popular book. But when it comes to code sometimes we feel like the original author has an obligation to keep working on it just because it would convenience us.
(edited for formatting)
- Waterluvian 1y agoYeah for sure! Listing that kind of thing would probably be helpful. I think this is one of those “you’ve gotta already be on the inside and already know” things as the fork’s read me doesn’t seem to explain it.
- mistercow 1y agoThis is pretty clear from the readme though? > While Grant Sanderson continues to maintain his own repository, we recommend this version for its continued development, improved features, enhanced documentation, and more active community-driven maintenance. If you would like to study how Grant makes his videos, head over to his repository
- Waterluvian 1y agoHm, yeah. And I read that. But I still didn’t feel equipped to know which I ought to focus on. Maybe it’s just too early on a Saturday for me.
- dleeftink 1y agoI agree, but want to add that while we may perceive other creative works as 'finished' (to an extent), code often is not. It unfortunately, needs perpetual work.
- 0_____0 1y agoIt's pretty wild to me (I do hardware) that data goods like code can rot the way they do. If my electronics designs sit for a couple years, they'll need changes to deal with parts obsolescence etc. if you want to make new units. If you did want your software project to run the same as today when compiled/interpreted 10 years from now, what would you have to reach for to make it 'rot-resistant'?
- vntok 1y ago> If you did want your software project to run the same as today when compiled/interpreted 10 years from now, what would you have to reach for to make it 'rot-resistant'? Target Windows, avoid Linux.
- the__alchemist 1y agoABI compatibility is one of several components involved. The OS the software runs out plays a small role in this problem. There is a relevant point about OSes though, and it has a different conclusion from yours: Write our software (And OSes) in a way that doesn't create barriers and friction between systems.
- kevindamm 1y agoThe biggest factor is dependencies' changes, so a good defense against bitrot is to reduce the dependencies as much as possible and try to limit dependencies to those which are exceptionally stable. This greatly limits velocity, though, and still doesn't help against security issues that need patching.. or if any of the stable dependencies made certain assumptions about hardware that has since changed. But, with the right selection of dependencies and some attention to good design, it is possible to write code durable against bitrot. It's just very uncommon.
- iamflimflam1 1y agoOne big thing is just losing knowledge of why things were done a certain way and how they actually work. Documentation helps and keeping code simple helps. But what really what rots away is human memory.