6 ms·
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
by thamer 6y ago
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 https://github.com/nodejs/http-parser
- megous 6y agoHttp 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.
- derangedHorse 6y agoThe 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
- megous 6y agoI 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.
- thamer 6y agoLots 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.
- BigJono 6y agoThere'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.
- maple3142 6y agoI think the main benefit of single file is that it will be easier to used in other projects, but this is just my assumption.
- fiddlerwoaroof 6y agoI’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.
- geocar 6y agoIf you learn how deal with programs organised this way, you won’t have “maintenance concerns” and you’ll be a better programmer. Win-win!
- thamer 6y agoOh 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!
- geocar 6y agoMate. 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.
- thamer 6y agoOh, 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.
- geocar 6y ago> 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.
- userbinator 6y agoRather 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.
- bigyikes 6y ago> 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.
- coder4life 6y agoWorking 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.
- forty 6y agoExactly, I think it's trading write efficiency for readability. It's good for write only projects (so mostly personal projects I'd think)
- derangedHorse 6y agoAlthough 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
- andykx 6y agoYeah. 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.
- nimrody 6y agoOne 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.
- kwhitefoot 6y agoIn 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
- jonex 6y agoIt 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.
- derangedHorse 6y agoI 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.
- interfixus 6y agoWell, 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.
- deleted 6y ago[deleted]