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.
I 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.
It'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'?
It's the same sort of thing, parts obsolescence. The world around you changes and the interfaces you used to interact with the world may not exist anymore. Your dependencies may have been abandoned and have gone through their own bitrot.
I think the best defence is to choose a platform that has longevity, like x86 Linux, and then seriously limit dependencies beyond the platform to the point of maybe not having any extra dependencies.
The problem is eventually platforms change too. The longest lasting platform for software ever created is x86 + BIOS which lasted from 1981 to 2020 when Intel officially deprecated BIOS.
The 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.
Write it in a specific version of a language with a strong history of backwards compatibility, like Fortran90. Maybe c99? And just use very famous libraries, like BLAS, that are never going away.
Think you need to go with a "dead" language with a simple runtime and keep everything vendored. My top contender would be Lua 5.1. Simple runtime (~20k(?) lines of C) which has been implemented in many other platforms (Javascript, Go, Rust). The side benefit of 5.1 is while you can make the standard compiler your target, you can probably run on LuaJIT (not dead, sophisticated assembly, and potential for breaking changes) as well.
Great question. It really depends. 10 years isn’t very long, so most well known languages & platforms will be fine. But 20 or 30 or 50 or 100 years, that gets more interesting.
I’ve kept all my dumb little side projects for my entire life, starting from Basic, Pascal & x86 assembly as a teenager 30 or more years ago, lots of C++ and OpenGL in college, python over the last 15 years, and HTML+Javascript mostly from ~10 years ago.
Surprisingly, the stuff that still runs with the least trouble from my teenage years several decades ago is the assembly code. Basic and Pascal I can do with emulators, but it takes more work. My C++ OpenGL projects from 15-25 years ago take some work to resurrect, but can be done. C++ command line code from 25 years ago compiles and runs without issues. Python from 15 years ago still runs, even the python 2.x code. HTML+JS from 10 years ago still runs without changes. My Arduino projects from 10 years ago might have bit rotted the most; they almost require starting over to get them going again.
Ironically even though the JS ecosystem has had some of the highest churn, I feel like it’s one of the safer bets, as long as you keep dependencies down. Don’t pull a ton of crap from npm/yarn/whatever. Use mostly vanilla JS+HTML, and it will definitely run on almost any OS and mobile device 10 years from now.
Anything with standards behind it necessarily moves pretty slowly. What C++ looks like is changing over time, but old code is pretty safe most of the time, and code written today should continue to work for 10 years easily.
> 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'?
ABI 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.
There is also the coopling issue: when your code depend of another part of your own code, it may be broken by this inner dependecy.
If the code is not intégration tested enough, then rarely used features may be broken without you noticing, thus the roting expression.
Modern standards help protect against this with the test pyramid.
C? Java? Perl? PHP? I have significant amounts of 20+ year old code in production, you just need to steer clear of the desire to use a huge framework/tons of dependencies and a language that breaks compatibility every few years.
That’s actually a really good point! I wonder if one day there will be analogues for music and writing?
I suppose you have gumroad / serialized novels or webcomics but I’m not sure if there’s any albums where the musician is putting out one song at a time
And more common nowadays, to re-release/master the recording as 'the artist intended'. But once you are familiarised with an original work and its (unintended) artefacts, a re-do is likely to lose some of the initial magic that drew you to the work in the first place.
And it shouldn't need to. Making (relatively) simple changes like checking-in fixed versions of dependencies in the code base and abstracting away core logic from the platform layer goes a long way. This works well for video games
Yeah 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.
> 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
I think it’s health related, as the article mentions.
>One executive in the entertainment industry said younger people were less inclined to go out raving until 6am as they were more health conscious and less frivolous with money than previous generations
This is the same generation that has 12 step skincare routines, eats only organic food, chooses to vape or zyn rather than smoke because of secondhand smoke, everyone has an Apple watch on their wrist tracking calories, etc.
If anything I’m surprised that binge drinking and going out late as survived as long as it has.
And as far as the money comment, this generation is not less frivolous there’s just less money to go around haha.
Having seen this generation at music festivals, I kind of disagree. I feel like the current generation go really hard on drugs.
In Australia, nightclub entry can be expensive, ranging from $20-50 per club. 10 years ago, you’d club hop, maybe going to 3-4 clubs from 11pm until 7am. These days, it’s not worth it. Drinks are like $12-16 for a basic mixed drink. A lot of patrons just drink at home, then drink (free) water and take MDMA and/or ketamine at clubs, which is significantly cheaper than a night of buying drinks.
There’s some recency bias to that for sure though - silent and greatest generations were not as big on partying like x or the boomers. Of course things like smoking were more common but the heath risks weren’t as well understood.
But most generations before us also didn't have the same awareness about the health risks associated with a lot of those acts unlike younger people today.
And the generation after us will probably think we were dumb about stuff as well (eg. social media, disinfo, Delta9, etc).
A classic example would be that if you have a test (say for cancer) with a false positive rate of “””only””” 5%, and your disease has an incidence of say 1 in 1000.
Let’s say that you get a positive diagnosis for the disease, and you ask someone the question:
What is the probability you actually have the disease?
Most people will say 95% or 99%, but your actual probability of having the disease in this example is <2%
Unfortunately that well-worn example usually only proves that "false positive" as a technical term fails to match people's intuitions. The underlying problem about the base rate is important to teach, but it's easy for well-meaning people to try and teach the base rate lesson but fail by instead teaching a bullshit gotcha about the definition of "false positive."
Well, theoretically you could make your current "Add Link" button and your current "Remove" button just trigger a server-side request and then refresh the page.
maybe some combination of the <noscript> tag and then if so wrapping the buttons in <form> and making the buttons submit those forms?
And in the Transformer architecture you’re working with embeddings, which are exactly what this article is about, the vector representation of words.