4 ms·

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 articl

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?

ziddoap 3y ago
>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.
Bjartr 3y ago
> 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.
rustyminnow 3y ago
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.
TeMPOraL 3y ago
> 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.
- PH95VuimJjqBqy 3y ago
  People have been saying this forever. History has shown they were wrong then and history will eventually show that you're wrong too.
  - TeMPOraL 3y ago
    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.
    - trealira 3y ago
      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.
      - TeMPOraL 3y ago
        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.
cjaybo 3y ago
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.

ziddoap 3y ago

>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.

Bjartr 3y ago

> 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.

rustyminnow 3y ago

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.

TeMPOraL 3y ago

> 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.

PH95VuimJjqBqy 3y ago
People have been saying this forever. History has shown they were wrong then and history will eventually show that you're wrong too.
- TeMPOraL 3y ago
  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.
  - trealira 3y ago
    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.
    - TeMPOraL 3y ago
      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.

cjaybo 3y ago

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.