←back to thread

Manim: Animation engine for explanatory math videos

(github.com)
434 points pykello | 1 comments | 23 Aug 25 07:35 UTC | HN request time: 0s | source
Show context
esperent ◴[23 Aug 25 10:39 UTC] No.44994941[source]▶
It seems like the community fork would be the better link for most people.

https://github.com/ManimCommunity/manim/

replies(2): >>44995220 #>>44996923 #
Waterluvian ◴[23 Aug 25 11:35 UTC] No.44995220[source]▶
For good reasons or for drama reasons? I read the blurb about the fork and can’t tell why exactly if Grant is continuing to maintain the original.
replies(3): >>44995263 #>>44995281 #>>44995457 #
Jorge1o1 ◴[23 Aug 25 11:44 UTC] No.44995263[source]▶
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)

replies(2): >>44995283 #>>44995297 #
dleeftink ◴[23 Aug 25 11:51 UTC] No.44995297[source]▶
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.
replies(3): >>44995360 #>>44995363 #>>44995570 #
0_____0 ◴[23 Aug 25 12:05 UTC] No.44995360[source]▶
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'?

replies(9): >>44995467 #>>44995475 #>>44995548 #>>44995551 #>>44995594 #>>44996206 #>>44997847 #>>44997879 #>>44999676 #
1. dahart ◴[23 Aug 25 18:07 UTC] No.44997879{5}[source]▶
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.