Hacker News Reader

Comment by pveierland | Hacker News Reader

Considering the extremes of prolific developers gives interesting contrast to dogmas such as "functions/files should never be above x lines", where `quickjs.c` is 50k lines and has functions that are hundreds of lines long:

https://github.com/bellard/quickjs/blob/master/quickjs.c

(Obviously different approaches suits different circumstances.)

View on HN

The answer is simple: Bellard can recall all 50K lines of context, while most can't. I too happen to have a larger working memory and only later realized that my threshold for files and functions is way higher than most others. The dogma is only required when the file is to be read and written by multiple people.

tbh working on one file is most often much more ergonomic for me. Depends entirely on the sw architecture of course.

Tbh I've lived already through at least three different dogmas contradicting each other. Those are sometimes behaving like a fashion

I would say that dogmas are normally born out of necessity before they become dogmatic, so it is beneficial to analyze and extract core values out of dogmas instead of entirely ignoring them. In this particular case we can conclude that the threshold should be determined per team, because some team may have a member whose working memory is exceptionally smaller than the average. (Ultimately this shouldn't surprise anyone because the coding convention has to be per team anyway.)

I never ignored them and usually followed them. They always have reason but sometimes there appears another reason that longs for a solution contradicting the previous dogma.

E.g. monolith -> modular monolith -> microservices

https://bellard.org/qemacs/

Has written his own editor, presumably to support preferred working style, using emacs idiom for UI.

I have written long methods and will do so again and I wouldn't say it's because I have larger working memory or some other supposedly superior attribute. Some methods are just a long series of steps that you can just write one after another. Reading it from top to bottom is exactly as difficult/confusing/whatever as reading them as separate methods would be (assuming you put short comments in the same places where you would otherwise break it up). I think people just don't want inexperienced programmers to do that because they'll end up with tons of mutable state spanning the whole thing, and it's easier to tell them to break it up into methods than to explain what you mean by mutable state and limited scope.

Of course that's a legitimate case of longer files or functions, but I found that I was generally able to follow much larger functions, so comfortable with writing larger-than-average code in general.

Also I should note that longer code doesn't mean less abstraction; it rather means that abstraction is done without separate functions and files, and ordering and visual cues can (and probably should heavily) be used instead. Apparently this is not enough for most others though, as I have received multiple complaints in spite of such readability efforts.

I feel like this is an underrated superpower. I don't have it - my digit span[0] is about 3, well below normal, so I've always felt that while I'm pretty smart (and managed to get a scientific PhD at an Ivy, so my brain's doing /something/ right), I've always felt like I'm driving a Ferrari but the windows are all blacked out and I'm looking through a tiny hole.

[0] https://en.wikipedia.org/wiki/Memory_span

I work on that codebase (we forked it off to QuickJS-ng) and while daunting at first, it's somewhat easy to work with, with the right editor! Many of them choke on such a large file, alas.

While it being a very large file, it's sorted somewhat semantically, so it's easy to work on adding a new iterator method, for example, since they are all close to each other.

Because people you’re working with are not Fabrice. It is easier to say “don’t do X at all” than explain when it is safe to break the rule.

Also, this would depend on language of choice. JVM, for example, might not inline function above certain threshold of bytecode instructions.

Case in point: .NET's garbage collector which is a single 54k loc C++ file.

Rather one long function than does one thing well than multiple function that are strongly coupled and difficult to reason about. Programmers who apply dogmas can be harmful.

I think this person creates these marvels entirely by himself. There is no need for collaboration rules.

In the age of advanced IDEs/text editors with goto definition, find references/usage, fuzzy search, etc, what is even the point of multiple files?

I never navigate by files in my code bases, it's all based on search and "jump to" type navigation.

Reply on news.ycombinator.com