Hacker News Reader

Comment by thamer | Hacker News Reader

Currently composed of 85,624 lines of C code, mostly in quickjs.c (53,575 lines in that one file alone), but also with a couple other large ones.

I can't say I understand the reason for such massive files. Surely it would be easier to maintain if it was split into a few well-defined modules?

In addition to the maintenance concerns, a JavaScript engine has quite a few parts that could be used as individual components. One good example of this is node's http-parser[1] that was extracted to a self-contained C file with associated headers and is a pleasure to use.

[1] https://github.com/nodejs/http-parser

View on HN

Rather than trying to figure out which of dozens of files has what you're looking for, you can just search one or two large ones.

On the other hand, I hate finding a project that looks useful, but then the code is scattered across many files which are barely one screen long, or worse, also spread throughout different deeply nested directories. Regardless of whether the organisation makes sense, navigating directory trees is annoying.

> Rather than trying to figure out which of dozens of files has what you're looking for, you can just search one or two large ones.

Why is this a good thing? The same amount of code and same number of results need to be scanned either way. With many files, you at least have the file name to give you some small amount of context without needing to read the code.

Working with 1 or 2 large files is vasty more productive/faster (for me) than working with 50

Seeing as Bellard is very prolific and has done more than you me and three others in a lifetime, there must be some merit to his approach.

Exactly, I think it's trading write efficiency for readability. It's good for write only projects (so mostly personal projects I'd think)

Although I agree with the fact it was easier/faster for him, don’t fall into the fallacy of him being productive meaning he was efficiently productive

Yeah. This seems like something that the industry decided was a bad practice many years ago.

My best guess is that this is more of a fun project than anything and spending too much time on such concerns would detract from the fun. I do the same with my side projects.

> you can just search one or two large ones.

if the LOC is similar in size, i don't see why having them in different files vs same file makes any difference at all.

Also, your IDE should be able to navigate you to definitions and usages etc. If it doesn't, it's not a good IDE. So the problem of understanding code reduces understanding the abstract structure, not how that structure is represented on file.

Your IDE should be able to split a single file codebase into different readable modules. If it cannot do that, its not a good IDE.

And slippery slope...

Is there a term for this type of refactor? Often I might end up with 2 exported classes in one file, both being used across other files. I then want to separate them into 2 files and update the imports. I feel like my IDE should be able to do this, I just can’t seem to google the right term.

Ah, in VS Code it is just:

1. Click class name (or any other top level identifier).

2. Click light bulb.

3. Click move to a new fie.

Do IDEs really do that type of refactoring? As a long time Emacs user I long forgot what a good IDE is capable of.

I know of automatic renaming, moving parts you select automatically to another file, but full automatic refactoring to multiple modules is something I haven’t seen.

How does this tackle circular dependencies etc. I guess the IDE must parse the code, generate the syntax tree, populate symbol tables etc. and then make the refactoring.

A side point I sometimes dream of writing an emacs module which would let me to write in a single file (for easy search and edit reasons), and then cut it into several modules where I mark them with =======xyz.h========= etc.

I also want to use this in each repo where it automatically does this. I’ll hopefuly stop procrastinating and write the thing one day :).

To end with a Game of Thrones analogy, hearing about the latest developments I sometimes feel like we editor/linux/bsd/cli users are like Wildlings beyond the wall. We live in harsher conditions, but are amazed when we see large cathedrals, castles being built inside the wall. Our life is more free but also burdensome.

I think that's actually a good analogy and I have felt the same from time to time!

Yes. Modern IDEs are incredibly productive because they have a high-level understanding of your program, going beyond just symbols in the code and way above just text processing.

Try using Visual Studio or Jetbrains IDEs and you'll see the difference.

Searching in one file is easy in any text editor. Searching across files (and directories) is more difficult.

I don't use an IDE. In fact, I'd say it's a problem if code requires an IDE in order to work on it effectively (Enterprise Java is the most prominent example of this.) I'm nowhere near Bellard level, but would consider myself above average, and have observed that some of the most productive programmers don't either --- and their code is far easier to understand than e.g. the mostly-autogenerated, split-into-many-tiny-files projects created by those far less skilled.

To suggest that not using an IDE is a sign you're a better developer makes as much sense as suggesting that not using an electric screwdriver to fit things is a sign of a better handyman.

To suggest that GP could have written better software had he used an IDE is to suggest that Michelangelo could have painted a better Sistine Chapel fresco had he used an electric paint sprayer.

Or, to bring it back within realistically achievable levels of talent, that Bob Ross's trees would've been happier if he used one.

No one suggested OP could do a better job had he used an IDE (and I have no idea if he did). The claim was that NOT using an IDE somehow signals you're a better developer, which is simply absurd.

So your comparison is wrong in this aspect, as the correct comparison would be "Painters who do not use modern tools made specifically to make painting easier are probably better painters. Michelangelo was the greatest master and he did not use modern tools, after all". Would you agree with that??

To me it sounds like he/she was saying that mediocre programmers have to rely on IDE features and that various excellent programmer realized they can write better code without it. Before that the statement was that it is bad for project if a IDE in needed to navigate it.

Maybe I am steelmanning too much but it could have simply meant to indicate the existence of a trend that move people toward IDEs and another trend that moves people away from IDEs

> code is scattered across many files which are barely one screen long

... one third of which is the copyright notice and license, and another third is boilerplate.

One advantage of using multiple files is that you can have functions that are private to the file (static functions). So when looking at a specific file you know it can use either functions in this specific file or functions #include-d from other files. But it cannot use the private functions of other non-included files.

This reduces the cognitive load and gives the compiler a way to enforce separation.

In short - files in C can give you namespaces -- which are sometimes a useful way to organize code.

In Pascal you can define functions inside other functions. So if, as is often the case, the file consists of one public function that calls a number of private ones this can be enforced without needing to put them in separate files.

In newer languages like C# you can do the same. Probably works in lots of other languages too, see Rosetta Code: Nested Function:

    https://rosettacode.org/wiki/Nested_function

There's plenty of workflows that work just fine with large files. As long as you're segmenting the code somehow and have a quick way to navigate to a specific section, it doesn't really make a difference how code is layed out.

It could be that his workflow is to always navigate by searching function names. Then it doesn't really matter if the project is 1 file or 1000.

It would probably be easier to read, but as a one-man project, my guess is that readability is less of a concern than for the average code base. Splitting code up in files requires some extra work and makes refactoring harder as you have to spend a lot of effort on trivial tasks such as moving dependencies between files and updating includes all over the place.

Personally I tend to want to split up code written by others so I can focus on the parts that go together without having to read through irrelevant parts, but I can easily navigate larger files/classes I've authored myself. I mainly split it up for the sake of future readers.

I do agree that it’s easy for a single programmer to not think about future readability for other all that much but in terms of refactoring code and straitening file dependencies, an IDE or code editor like VSCode can probably do it for you.

If you learn how deal with programs organised this way, you won’t have “maintenance concerns” and you’ll be a better programmer. Win-win!

Oh man. I had to deal with programs organized this way when you were my manager and I had tons of maintenance concerns :D

Fun to run into you, Geo!

Mate. You didn’t have to do anything. You got to do whatever you wanted and you wanted “smarter coworkers” who didn’t use PHP.

But I stand by what I said now and nearly a decade ago, and now try to be blunt: Fabrice Bellard didn’t organise quickjs this way because he isn’t as smart as you. He did it because it makes things easier for him to write quickjs and qemu and tcc and ffmpeg and all sorts of other stuff used by all sorts of other people. And if you ever figure out how to learn from watching people who can do things you cannot, I think you could be an amazing programmer.

All the best.

Oh, I would never compare myself to him and can only learn (a ton) from someone like him who can indeed do many things I cannot. Just something I found curious, I'm sure he has a good reason for it.

> who can indeed do many things I cannot

No. This is exactly my point.

You can do it too, you just might need to organize your code this way to do it.

Well, this sparked off a whole and quite predictable thread.

We can only hope Fabrice Bellard reads it all so he can learn himself some coding.

Http is not part of JS engine, because it has nothing to do with JS.

I kinda like large files (vs splitting the code), because they are easier to navigate in vim. I have no idea about why the choice was made for QuickJS, aside from ease of inclusion into other projects, mentioned in the docs.

The original comment was about separating components out for reuse in other projects. He wasn’t wondering why http wasn’t part of the js engine, that was just the example he chose

I don't see how any part of quickjs engine itself can be used in other projects. It all looks highly tailored to quickjs, aside from things that are already separated.

Lots of parts can be used separately! The parser for code analysis or refactoring tools, the JIT to accelerate programs (anything state machine based for example is pretty much like a VM), the garbage collector to embed in other programs (especially interpreters). I mean… these are just the most obvious, there are many more use cases.

I think the main benefit of single file is that it will be easier to used in other projects, but this is just my assumption.

I’ve always found that lots of definitions in one file is easier than splitting code over 100 files. It reduces reliance on complex, and often slow, tooling for analyzing directory structures and, most development tools support opening the same file twice at different offsets.

Reply on news.ycombinator.com