←back to thread

Manim: Animation engine for explanatory math videos

(github.com)
434 points pykello | 3 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{3}[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. bee_rider ◴[23 Aug 25 14:22 UTC] No.44996206{4}[source]▶
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.

No idea what to do if it needs a gui, though.

replies(2): >>44996743 #>>44997705 #
2. miki123211 ◴[23 Aug 25 15:38 UTC] No.44996743[source]▶
Try to run it on a 20-year-old system.

If it ran 20 years ago and it still runs now, it's very likely to still run in another 20 years.

3. 3eb7988a1663 ◴[23 Aug 25 17:45 UTC] No.44997705[source]▶
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.