The author didn't put any effort into actually trying to articulate a concrete example of a system that was already well-architectured but also needed section headers. All of the examples they brought up would be better-served by more sensible refactors that didn't go to one extreme (4 line files) or the other (2000 line files). I'm sure there are rare files where having section header comments really is helpful, but personally I've never found it a useful way to organize my code, even in >500k LoC projects.

Sometimes, you really are just holding it wrong.

Should the OP have written a manuscript to make you feel better? In your mind, should a long, drawn out article only be refuted by something of similar length?

> Sometimes, you really are just holding it wrong.

Yup. We all are. This is only a problem because editing raw plaintext code as single source of truth is a bad idea, and we're reaching its limits. "Split or don't split" is one of many holy wars that can't be solved, because they happen on the Pareto frontier. The only way to move forward is to accept that different coding tasks need different representations, and the computer should synthesize them for us, and we generally should not touch the underlying single source of truth, anymore than we manually poke in assembly files generated by our compilers.

People have been saying this forever. History has shown they were wrong then and history will eventually show that you're wrong too.

I beg to differ. The industry existed only so long, and while some people have been (rightfully!) saying this since the early days, the market opted to push a shitty solution to its limits, and only now we're starting to feel the pain of pressing against those limits.

I can't imagine it will ever become mainstream to store source code using anything but plain text unless we stop using Git and representing files and directories in the classical Unix fashion.

The alternative to plain text is programming-language specific version control and source code formats, and managing codebases using some external database tool, or something similar. It also means you can't easily interoperate with existing plain text code.

I predict the only way people will switch is if there's some overwhelming competitive advantage in storing code as something other than text files, to the point where business competitors will go bankrupt from not upgrading technologies. And then the open source community will adopt it after the industry does.

We can keep storing code in text files, that's not the point. Point is, we should not be editing this storage form directly, but rather its slices and projections relevant to the task at hand.

They should at least address the actual points raised by the article (which does already touch on the trade offs involved in doing what the commenter suggests, none of which were addressed by their comment). As it stands it sounds like they’re responding to nothing more than the title of the post.

It’s a shallow criticism by HN standards.

> Should the OP have written a manuscript to make you feel better?

Nope

> only be refuted by something of similar length?

No, but if you don't address the points that have been made, you're not refuting. The comment says "refactor your codebase to put the related code together", but the article already addresses some downsides to this approach.

Does the commenter believe that those downsides are more avoidable than the article states? Or maybe they believe the downsides are dwarfed by the upsides? Or maybe something else. We don't know, so we can't evaluate the position effectively.

>Should the OP have written a manuscript to make you feel better? In your mind, should a long, drawn out article only be refuted by something of similar length?

It's not about "feeling better"? It's that the comment is very dismissive and sums up to "just refactor". Advice of "just refactor" (or "just do x") is lazy and ignores all context.

That would make me feel better. Without actionable advice, OP is just just grumbling. It's not helpful.

> Refactor your codebase to put the related code together, and then this "problem" will disappear

But how do I do that exactly? What does this even mean? I could literally put the whole codebase into one file since it is all related somehow or another.