Hacker News Reader

Comment by tecoholic | Hacker News Reader

    One of the thorniest conversions was the session.ts file, which was over 30,000 lines of TypeScript that touched all aspects of the runtime.

This can’t be real. Single file with 30K lines? Which human being is working on it and how much RAM does it take for a code editor to load that with full symbol tree? I am genuinely curious. Is this common? I think most files I come across stretch to maybe 2-3k lines max.

View on HN

30000 is not that big in very old projects with many contributors. There are always one or two files that no one wants to take the time and responsibility to clean up. And 30000 is not a big number for RAM. The fact that you find it choking is more and of an indication of how bad our tools have become than anything else.

For example, until recently the main file for donet runtime GC was more than 50000 lines (it has since been split).

Copilot isn’t “very old”.

I’m sure it has changed a lot since inception

Behold the View.java[0] at 34k lines of human code. IIRC it’s slimmed down a bit these days and used to be more.

[0] https://android.googlesource.com/platform/frameworks/base/+/...

Wow. Somehow I feel my software creds just went by a notch by the mere existence of these files.

Until recently the .NET garbage collector used to be a single 30,000+ line C++ file. And it was maintained by one person if I remember correctly.

Amazed and horrified at the same time.

Just checked it and I underestimated. Just before the split it was at 54k LOC: <https://github.com/dotnet/runtime/blob/b96f3cc738f7fca9474fb...>

I’ve also read that a first version of the file came from a Common Lisp to C++ code generation step: <https://news.ycombinator.com/item?id=23295041>

I recently saw a ~60k lines / 3mb .cpp file in one vibe coded project (and yes I was a bit horrified) Surprised it works at all but it apparently does. Not really for a human though and even for an LLM it would be more beneficial for it to be split up.

This has to be 1) early LLM vibe coding or 2) “hand” vibe codingwhere the user asked the LLM to code sections and stitches them together manually, and the programmer is a novice. The second part I speak from experience; got to ~2k before realizing this is out of the script range and started to break it up. Regardless, it would be almost impossible to get an SOTA LLM agent to ever do this.

It is very possible. Sol Max created a 17k line monolithic file in a prototype not long ago. If I didn't stop it and make it refactor everything it easily would have went to 60k. I think it's the default if you start a new project and don't define the architecture concretely with files and folders beforehand. Models have zero concept of architecture or long-term planning, they just band-aid the fastest immediate solution that gets them the reward.

I find that specifically when you tell it you’re doing a prototype or POC, it takes that as a license to write huge single files and other shit coding practices.

I have seen 30k line cpp files even a decade ago (World of Warcraft server emulator, gameplay logic of a boss enemy), and was told it is fairly normal in large software (even 100K not being unheard of), so I'm not sure if it's that much of an LLM thing.

In the cpp world that’s indeed relatively normal for complex projects.

The question should be how can they ever let that file grow that big. What kind of engineers were working on that, like I hate seeing any file more than 300-400 lines of code

If well organized the number of lines of code in a file is really irrelevant. 300-400 loc is a tiny file in any professional project. Splitting in a large number of file doesn’t magically make things simpler to manage, in fact you fragment the context by doing that. And very likely end up with unnecessary abstractions

I disagree, that makes it more readable, maintainable and testable. Just because everything is in one file doesn’t mean you’ll be able to build the context, you’d forget what was at the start of the file when you get to the bottom of it if it’s like 3k lines

We don’t read a source file as a book, from the first line to the last one. A file is just a set of classes, functions, types, constants, and you generally navigate it by blocks. Splitting multiple functions, classes into multiple files just to match an arbitrary number of lines is bad engineering, prioritizing a dogmatic approach instead of a thoughtful one. File units should have a meaning. And there are quite a lots of situation where keeping more things tied together in the same file is a meaningful thing to do, even if the file is itself large. There is an argument for avoiding extremely large files based on the impact on the resulting artifact, but lots of tiny files (400loc is really short) pretty much always results in duplicated logic and over engineering

Was the documentation for each function a full-on essay?

> Which human being is working on it

If you've ever used that tool you wouldn't ask this question, since it's obviously fully vibecoded.

Reply on news.ycombinator.com