Hacker News Reader

Comment by babelfish | Hacker News Reader

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)

View on HN

> What if they want to add a new feature that takes another ~1000 LoC?

They don't.

The LoC limit exists as much to avoid scope creep and maintain focus as it is about anything else.

It trades off utility for managing scope creep. Keeping this code base tiny necessarily means that anything that uses it would need to write more code. If the point is a demonstration instead of a usable library, then that is good because it is much easier to follow without excess complexity.

Necessarily is a strong word; there are assuredly many users of this tool who find it sufficient in its scope as it is, based on the project activity. If a user needs significant feature additions they can write them as a separate tool that interacts with this one.

This one arguably does have a bit of scope creep it's just in a separate directory.

Maybe don’t add that feature then? Not every library is meant to solve all problems

No, but every library tries to solve at least _one_ problem, and maybe it needs to go over 1000 lines to do that.

This one doesn't, apparently.

Not all software is intended to grow indefinitely. Keeping things small and grokkable is very valuable for learning.

This is a semi-educational project, so it makes sense to keep the number of lines small.

It serves an important gatekeeping function by discouraging low-effort contributions.

simplicity is a virtue. the project goal apparently isn't to have a lot of features, it's to do the core thing in the simplest way possible.

And if someone does some code golf to stay under the 1000 line limit rather than go to 1050 lines that’s an improvement?

Then the human responsible for approving the PR will decide whether it's worth it. Personally, I love it.

no that's another bloated ml library with code compression.

i suspect a part of the motivation for this library is learning and teaching.

and maybe a little flexing on overcomplicated autograd libraries.

You say 1000 lines is an arbitrary number. Do you actually have a feature in mind that takes it above this artificial limit? Did you even read the code?

They like this round number. Fork. Why argue.

It's how you get commits like these, though https://github.com/geohot/tinygrad/commit/050636bcb1068beff6...

  Subject: here's two extra lines of precious code (#307) 
  
  diff --git a/tinygrad/__init__.py b/tinygrad/__init__.py
  index 0deab3e9..31ac75d5 100644
  --- a/tinygrad/__init__.py
  +++ b/tinygrad/__init__.py
  @@ -1,3 +1 @@
  -import tinygrad.optim
  -import tinygrad.tensor
  -import tinygrad.nn
  +from tinygrad import optim, tensor, nn

There's a difference between "I will refuse features like X/Y/Z" and "I want the length of the code file to be N lines at most". The former tells you both explicitly and implicitly which features not to bother contributing. The latter is just nonsense.

This is why the good lord gave us: https://github.com/psf/black

Import line is actually improved with this commit. LGTM, ship it.

We now return to your regularly scheduled bikeshedding.

You're saving yourself from one kind of golfing, but not all of them.

Additionally, I feel like installing an additional tool is kind of against the spirit of 1kLOC simplicity.

I'm getting distinct uses Eclipse to write vogon poetry and Jira Master vibes from you.

Any notes on the actual code in the OP beyond the import lines formatting?

I'm sorry to have offended you, but I don't feel personal insults over the README of an open source project are particularly reasonable.

This affects the actual code, too! See, for example, https://github.com/geohot/tinygrad/commit/cfb7a4c41a2b6bcc09..., which includes this gem:

  diff --git a/tinygrad/ops/ops_cpu.py b/tinygrad/ops/ops_cpu.py
  index a454f56f..0686f810 100644
  --- a/tinygrad/ops/ops_cpu.py
  +++ b/tinygrad/ops/ops_cpu.py
  @@ -2,22 +2,15 @@
   from ..tensor import Function
   
   class CPUBuffer(np.ndarray):
  -  def log(x):
  -    return np.log(x)
  -  def exp(x):
  -    return np.exp(x)
  -  def relu(x):
  -    return np.maximum(x, 0)
  -  def expand(x, shp):
  -    return np.broadcast_to(x, shp)
  +  log = lambda x: np.log(x)
  +  exp = lambda x: np.exp(x)
  +  relu = lambda x: np.maximum(x, 0)
  +  expand = lambda x,shp: np.broadcast_to(x, shp)
  +  permute = lambda x,order: x.transpose(order)
  +  type = lambda x,tt: x.astype(tt)
  +  custompad = lambda x,padding: np.pad(x, padding)
     def amax(x, *args, **kwargs):
       return np.amax(x, *args, **kwargs)
  -  def permute(x, order):
  -    return x.transpose(order)
  -  def type(x, tt):
  -    return x.astype(tt)
  -  def custompad(x, padding):
  -    return np.pad(x, padding)
     def toCPU(x):
       return x
     @staticmethod

The "actual code" is being golfed for no other reason than to keep the line count down, for the sake of a promise that never needed to be made. This commit recovered a total of seven lines wherein new code can be added, in exchange for readability. It is not just a quirk, not just some sort of interesting aside like one could argue for suckless' `dwm`: this promise actively makes the code worse over time, for no reason.

No offense taken and no offense intended at all friend.

In my opinion we are down the rabbit hole of arguing style over substance. I just think you are grasping at straws. Tools like black (if there was a just god it would just be part of the language, like gofmt) can easily settle stylistic choices.

Really not worth endlessly debating, what next, tabs vs spaces?

This commit seems fine to me as well. Consider the golfing serves the purpose of "the lols" if you must. Heck this particular commit looks slightly better with the change!

Excessive golfing to the detriment of code quality over time is a well known and wholly irrelevant point to make with something like Tinygrad.

If you are so convinced of what you are saying, fork and rewrite it as verbosely as you prefer and demonstrate some significant improvement to the project quality. Would be insightful.

I think I've proven my point well enough here by making it clear that in order for them to stay under 1kLOC they have had to make golfing-style changes that cannot be automated.

If I were hell-bent on convincing you, I could fork their repo and add literally any feature requiring more than ten LOC and win. They would have to bend over backwards to get enough lines back to be able to merge whatever it is I wrote, with exponentially worse effects per individual line contributed.

But I'm not hell-bent on convincing you. You know that I'm not actually going to write code for you. You might think it's a clever rhetorical strategy, but it's not. Because I have other things to do, like a day job and personal projects, whose preemption of my jumping through your hoop are completely disconnected from the veracity of my line of reasoning.

That's just like, your opinion, man.

And it isn't a rhetorical strategy. It is socratic questioning.

Should you sit down and attempt to write something out of spite (an excellent motivator, as good as any) it would go slightly differently than how you theorize.

In order to add a feature requiring more than ten LOC you'd actually have to come up with one in the first place :)

That would require reading Tinygrad, which shouldn't take very long for obvious reasons. Probably we've been arguing about this for longer.

At which point you'd realize there is not much to add to it and you are splitting hairs over whether it is 1200 lines or 999 lines.

In which case you could just run black on it and leave it at whatever line count it spits out. That wouldn't even require any additional coding on your part!

Then you can compare the black'd version to theirs and realize they made a very very small sacrifice as a lark. Thereby finally understanding the difference between the principal of "code golf bad" and the reality of "tinygrad l33t demo" you ol' fuddy duddy.

Socratic questioning involves questioning, not unexplained assertions. You definitely don't come off as a modern-day Socrates when you use the latter.

I'm not against something like a 64k or 4k intro competition, because the results are generally that you get to see someone take advantage of every inch of their machine, like in https://linusakesson.net/scene/a-mind-is-born/, filing down an executable byte by byte until it does what they wanted it to do. That's rad as hell.

The results here are that... someone has filed down their Python program in a way that makes it smaller. Not even in number of bytes, just in number of lines. In a really uninteresting way. It's not even like the Python examples on StackExchange's codegolf in that sense, because we could go the complete opposite route and merge most of these statements together with semicolons. It doesn't become more interesting as it gets smaller, or less interesting as it gets bigger. It's the same program regardless of how many lines it occupies, which makes it that much less interesting.

So, yes, to some extent we agree, you can just run this through automated tools and it will be as many or as few lines as you like. I see that as pointless because other restrictions would be much more stimulating, and not restricting yourself so heavily would probably lead to better (or at least more legible) results.

But sure, that'll just be this fuddy duddy's opinion.

> The results here are that... someone has filed down their Python program in a way that makes it smaller. Not even in number of bytes, just in number of lines. In a really uninteresting way.

Egads. No, it isn't the focus of the repo. You keep on missing the forest for the trees.

Tinygrad expresses its ideas succiently and clearly. It is not an exercise in code golfing. Close to the end of feature completeness they noticed it is hovering a round number and spent a minor effort pushing it down slightly for street cred.

Those changes did not impair readability or harm the project in any way. They did not go over board. You say they did, I reckon, just because you are allergic to any such changes - that is your personal subjective opinion. A waste of time you say! Bah humbug!

Well, yeah, so? Heh.

I say run it through black and make it objective, it is a great tool. It will reveal just how minor the difference is in this specific case.

I keep trying to focus on the substance. Did you actually read this project? Not through the eyes of a human linter? Was it difficult to follow? What are we arguing about if not the absolutely least interesting aspect of it really?

i think it's an improvement. there's nothing wrong with functional style.

It could be written:

    def log(x): return np.log(x)
    def exp(x): return np.exp(x)
    ...

And keep the same line count, and the functions would keep their __name__.

I would merge this PR.

Dev dependencies and release dependencies are distinct. There would be no sense in complaining about hypocrisy if a zero-dependency C project uses clang-format or valgrind, and similarly for a python project using black or mypy.

Reply on news.ycombinator.com