Tinygrad

jonahx wrote: post #2

>tinygrad will always be below 1000 lines. If it isn't, we will revert commits until tinygrad becomes smaller. Love this ethos so much. Wish more projects would follow suit.

I think it's a bit unnecessary. A small set of operations should be enough to make it easy to port to new accelerators, and there's lots of nice to haves in many programs that don't affect compatibility.

If you don't plan on ever doing anything but the core it does seem pretty reasonable though.

Re: Tinygrad

#7

Post by [deleted] » Mon, Apr 04, 2022, 7:27 PM UTC

jonahx wrote: post #2

>tinygrad will always be below 1000 lines. If it isn't, we will revert commits until tinygrad becomes smaller. Love this ethos so much. Wish more projects would follow suit.

[deleted]

Re: Tinygrad

#8

Post by erwincoumans » Mon, Apr 04, 2022, 7:28 PM UTC

jonahx wrote: post #2

>tinygrad will always be below 1000 lines. If it isn't, we will revert commits until tinygrad becomes smaller. Love this ethos so much. Wish more projects would follow suit.

Agreed. It still leaves the loop hole of writing infinitely long lines of code (or is there a line length limit?)

I also enjoyed watching the life streaming videos https://www.youtube.com/watch?v=Xtws3-Pk69o and the videos videos documenting the neural network ANE M1 chip reverse engineering efforts for this project. See video links here: https://news.ycombinator.com/item?id=30852818

Re: Tinygrad

#9

Post by hmate9 » Mon, Apr 04, 2022, 7:28 PM UTC

This is the guy that did some iOS jailbreaks, reverse engineered the PS3 and now runs a self driving car startup.

Re: Tinygrad

#10

Post by babelfish » Mon, Apr 04, 2022, 7:29 PM UTC

jonahx wrote: post #2

>tinygrad will always be below 1000 lines. If it isn't, we will revert commits until tinygrad becomes smaller. Love this ethos so much. Wish more projects would follow suit.

Completely disagree - limiting lines of code as an ethos makes as much sense as using lines of code written as a business metric.

What if they want to add a new feature that takes another ~1000 LoC? Can they just write it as a separate library and include it as a dependency? IMO trying to minimize LoC creates a perverse incentive to split up your package when it might not need it (in the same way maximizing LoC creates a perverse incentive to write the most verbose code possible, not necessarily the most readable/maintainable)