Live data from Hacker News

Five Years of Tinygrad

geohot.github.io

91–100 of 167 posts

Re: Five Years of Tinygrad

#91
post #82
post #50

Earlier quoted context omitted.

You're not supposed to admit it, but I never cared for Dijkstra's arguments on the matter. The same goes for his GOTO tirade, although that has been distorted by time somewhat. Pascal is using 1-ord, Fortran, R, Mathematica. If anything, it seems there's a longer tradition of 1-ord in scientific computing. In this view, I must agree insofar I don't think Julia people are serious about their "general purpose" stance w…

> I never cared for Dijkstra's arguments on the matter. It resonates with me, as does little-endian. There are evergreen arguments about both of these, but they stand out to me as two of the few places where I appear to be in sync with the majority. > Pascal is using 1-ord, Fortran, R, Mathematica. If anything, it seems there's a longer tradition of 1-ord in scientific computing. Actually, Pascal let you define the s…

Maybe it's wrong to call it homoiconicity, but Julia code in symbolic form is a first-class citizen in a way that has no remote equivalent in Python.

    Expr(:call, :+, 1, Expr(:call, :*, 2, 3)) |> eval # 7
The fact that it displays as 1 + 2 * 3 instead of (+ 1 (* 2 3)) ... meh. The whole point is to make metaprogramming easy, which Julia is quite successful at (for better or worse -- some people shouldn't be allowed near macros).

Re: Five Years of Tinygrad

#92

I've looked at the "only 18,935 lines of code" python code and it made me want to poke my eyes out. Not sure what's the point of this extreme code-golfing.

yes, it's really crazy, if people think you're exaggerating look at this: https://github.com/tinygrad/tinygrad/blob/master/tinygrad/co... One of the cases why I think obsession with lines of code is one of the most counterproductive metrics, it always produces code like this.

You’re getting some pushback but one look at pm_reduce_collapse and I’m glad I don’t have to work in this codebase.

Re: Five Years of Tinygrad

#93
post #90

Earlier quoted context omitted.

Looks fine to me. I'm going to guess that you're used to codebases that use an autoformatter. There's definitely a case to be made for autoformatters in projects with a very large (>100) number of developers, but the price you pay for that is much poorer information density per screenful of code. For things like tinygrad or sqlite with a small dev team it's possible to use whitespace, style, and formatting to communi…

Even with autoformatters, it's a choice of what criteria you pick. It's possible to have consistency without enforcing low information density.

I wish. Stuff like Prettier is purposely unconfigurable and leads to the unreadability of JS code across the ecosystem.

Re: Five Years of Tinygrad

#94

I've looked at the "only 18,935 lines of code" python code and it made me want to poke my eyes out. Not sure what's the point of this extreme code-golfing.

yes, it's really crazy, if people think you're exaggerating look at this: https://github.com/tinygrad/tinygrad/blob/master/tinygrad/co... One of the cases why I think obsession with lines of code is one of the most counterproductive metrics, it always produces code like this.

Huh. This is more readable than almost any large python codebase to me at first glance. It’s 2D, and well commented. I find it an excellent use of screen real estate. Perhaps it would be a different story if most of us weren’t stuck in 16:9?

Re: Five Years of Tinygrad

#95

I've looked at the "only 18,935 lines of code" python code and it made me want to poke my eyes out. Not sure what's the point of this extreme code-golfing.

yes, it's really crazy, if people think you're exaggerating look at this: https://github.com/tinygrad/tinygrad/blob/master/tinygrad/co... One of the cases why I think obsession with lines of code is one of the most counterproductive metrics, it always produces code like this.

I think the discomfort I felt at looking at that was because of the stylistic difference. There isn't any part of it that looks terribly hard to understand when compared to other code. I presume anyone dealing with this codebase would know what ctx entails and most things seem to logically flow from what it provides.

I think if I dealt with this on a daily basis I might end up finding if vastly more preferable, albeit at the risk of alienating fellow developers. In that respect it seems much like learning to use Emacs or vi

Re: Five Years of Tinygrad

#96

>People get hired by contributing to the repo. It’s a very self directed job, with one meeting a week and a goal of making tinygrad better I find this organizational structure compelling, probably the closest to reaching 100% productivity in a week as you can get.

It’s hard to argue against hiring contributors, but a bounty system that pays pennies vs. market value for skilled developers shouldn’t be the only interview path, it’s borderline exploitative.

Re: Five Years of Tinygrad

#98

Earlier quoted context omitted.

yes, it's really crazy, if people think you're exaggerating look at this: https://github.com/tinygrad/tinygrad/blob/master/tinygrad/co... One of the cases why I think obsession with lines of code is one of the most counterproductive metrics, it always produces code like this.

You’re getting some pushback but one look at pm_reduce_collapse and I’m glad I don’t have to work in this codebase.

I see the advantage of the inline lambdas, but also it seems like it would hamper the ability to test the functions which can often have intricacies that catch you out. I believe one of the principles of Tinygrad is that tests shouldn't be part of the core codebase and shouldn't add to the total linecount.

I think there is an opportunity there to have a tag in comments for tests.

Have a hotkey to generate an id so you could have

  # lift x+y out of reduce on lt               :testID: color_adjective_noun  
  ((UPat.var("x")+UPat.var("y")).or_casted() 
and it creates a test that exists away from the main codebase. A process that runs tests could scan the code for testID's, intelligently extract the relevant part of the code into the test harness and runs the tests. There would need to be some infrastructure needed to handle placing the code to be tested into the right context but you could have

  1. A codebase that contained no active code required simply to facilitate tests, 

  2. All test tags auto removable for distribution builds

Re: Five Years of Tinygrad

#99
post #33

Earlier quoted context omitted.

I hate it when ‘inspirational’ quotes are attributed to the person with the largest audience and not the people who came up with it, like in this case, the engineers at Lockheed’s Skunk Works.

You would be amazed https://en.wikipedia.org/wiki/TRIZ

Ok this wins my “best wikipedia article of December” award

Re: Five Years of Tinygrad

#100

Earlier quoted context omitted.

That's comma.ai's policy since they make hardware and solve physical problems. The tiny corp has been hybrid (remote-first) since day 1 because it primarily writes open source software, and there's a long track record of success with remote for this kind of task. We have a few whole-team meetups in Hong Kong each year for 2-4 weeks, and there's a San Diego or Hong Kong office that anyone can work from as they choose.…

Have you run into problems with contributors who can't enter the PRC?

Actually the opposite is the problem:

“International scientists rethink U.S. conference attendance“

https://www.science.org/content/article/international-scient...

Post reply on HN