4 ms·

It seems like the community fork would be the better link for most people. https://github.com/ManimCommunity/manim/ https://github.com/ManimCommunity/manim/

Waterluvian 1y ago
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.
- 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 ago
    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.
    - mistercow 1y ago
      This 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 ago
        Hm, 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 ago
    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.
    - 0_____0 1y ago
      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'?
      - 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 ago
        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.
      - kevindamm 1y ago
        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.
- pbronez 1y ago
  Looks like the projects have slightly different goals. Grant developed the software originally as a personal tool for his YouTube videos. The software is optimized for his personal needs. The community version tries to make the tool useful for more people. They’ve built out the docs and apparently improved testing.
- snitty 1y ago
  https://www.youtube.com/watch?v=rbu7Zu5X1zI&t=19s&pp=ygUFbWFuaW0%3D https://www.youtube.com/watch?v=rbu7Zu5X1zI&t=19s&pp=ygUFbWF...
the__alchemist 1y ago
The sort of project Grant made is exquisite. It's not built by OSS library maintainers: It's built by someone who is interested in the application, and is an expert in the domain. Suitable tools didn't exist, so he built and maintains a tool that works well for his real-world applications. My pattern-matching brain thinks the fork is by people who want to build infrastructure that will suit its own end, at the cost of the original purpose of supporting the applications that call it. It is and will continue to decouple from the intended application. Design-by-committee, expanded to too many use cases, and just a general loss of UX. I think this is a clear case of comparing "Expert who wants to get-shit-done" / "Library maintainers who want to maintain and promote a library"
- f1shy 1y ago
  Grant himself advocated for the use of the fork and discourages the use of his own version. I’ve heard that directly from him in person.
  - mindcrime 1y ago
    Yes. I have not interacted with him directly, but I have observed him making the same statements in recorded interviews. It really is the case that for most "not Grant" people, the community version is probably where you should start (and possibly remain).
- redbluered 1y ago
  The fork is better for normal people. There is no drama or controversy here. Grant built a brilliant tool for himself. He's not interested in doing the work to make it useful to others, or even allow PRs to do so. He's glad to have others do that in their own fork. The community edition does all the stuff needed to make this useful to anyone who isn't Grant. Everyone, Grant included, seems to appreciate that. Grant's version has poor documentation, bugs, quirks, etc. Unless you're Grant, get CE. Grant did the hard work of inventing this thing. That's harder than it sounds; many tried before and failed. CE did the boring work of making it usable for others.

Waterluvian 1y ago

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.

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 ago
  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.
  - mistercow 1y ago
    This 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 ago
      Hm, 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 ago
  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.
  - 0_____0 1y ago
    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'?
    - 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 ago
        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.
    - kevindamm 1y ago
      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.
pbronez 1y ago
Looks like the projects have slightly different goals. Grant developed the software originally as a personal tool for his YouTube videos. The software is optimized for his personal needs. The community version tries to make the tool useful for more people. They’ve built out the docs and apparently improved testing.
snitty 1y ago
https://www.youtube.com/watch?v=rbu7Zu5X1zI&t=19s&pp=ygUFbWFuaW0%3D https://www.youtube.com/watch?v=rbu7Zu5X1zI&t=19s&pp=ygUFbWF...

the__alchemist 1y ago

The sort of project Grant made is exquisite. It's not built by OSS library maintainers: It's built by someone who is interested in the application, and is an expert in the domain. Suitable tools didn't exist, so he built and maintains a tool that works well for his real-world applications. My pattern-matching brain thinks the fork is by people who want to build infrastructure that will suit its own end, at the cost of the original purpose of supporting the applications that call it. It is and will continue to decouple from the intended application. Design-by-committee, expanded to too many use cases, and just a general loss of UX. I think this is a clear case of comparing "Expert who wants to get-shit-done" / "Library maintainers who want to maintain and promote a library"

f1shy 1y ago
Grant himself advocated for the use of the fork and discourages the use of his own version. I’ve heard that directly from him in person.
- mindcrime 1y ago
  Yes. I have not interacted with him directly, but I have observed him making the same statements in recorded interviews. It really is the case that for most "not Grant" people, the community version is probably where you should start (and possibly remain).
redbluered 1y ago
The fork is better for normal people. There is no drama or controversy here. Grant built a brilliant tool for himself. He's not interested in doing the work to make it useful to others, or even allow PRs to do so. He's glad to have others do that in their own fork. The community edition does all the stuff needed to make this useful to anyone who isn't Grant. Everyone, Grant included, seems to appreciate that. Grant's version has poor documentation, bugs, quirks, etc. Unless you're Grant, get CE. Grant did the hard work of inventing this thing. That's harder than it sounds; many tried before and failed. CE did the boring work of making it usable for others.