Good code but on the way to terse Better comments needed

Funny to me that it is called simplify.py

That doesn’t look super awful to me? Hardly extreme code golfing.

The far more interesting part is the order of magnitude. If they can pull off a 20k LOC with zero dependencies (implying a pretty concise project size) and it still works well on meaningful applications, that’s pretty neat. A 1000x reduction in code size and matching/exceeding in perf is worth looking at. Probably also implying a better architecture as code golf isn’t gonna get you 1000x less code. Again - their claims not mine, so we’ll see.

But at that point they can triple the LOC to 60k with nothing but white space, new lines, and comments, for all I care. It won’t even add a zero.

TBH that looks pretty decent to me. GPU programming is very very complicated. A simple kernel in torch is hundreds to thousands of LOCs, with much worse style.

I agree with some poster above, the code looks hard simply because the problem is very hard, not because they want to write it that way.

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

Running a formatter on that codebase would probably at least triple it.

I don't think this is bad, if you know Python then most of the code will be fine for you. I think you're probably referring to pm_reduce_collapse, but while it looks daunting at first, it really isn't when you consider the alternatives, I'd be curious on how you'd improve it short of creating a DSL.

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.

This is like a JIT, generating code (machine code?). It’s a complex operation and IMO the code doing it is very clean and clear.

It helps that a single person can read all related bits on one screen.

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?

Doesn’t seem too bad to me. It reminds me a bit of Clojure. Like Clojure, though, the lack of static types would be a headache.

It’s not crazy at all, but personally I like simple code that flows down the page more, not across

Is is code a form of AST rewrite rules for optimization? This operation still looks like a incomprehensible wall of code 40 years later (I looked in the past inside the C++ compiler).

to quote an old academic research programmer: "Two-letter variable names are fine, as long as both letters are meaningful" :-)

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 communicate important information, just like mathematicians do. The AMS journals don't autoformat mathematicians' equations!