Re:Should you split that file?
by PH95VuimJjqBqy on Friday December 01, 2023 @05:00PM
(#38493088)
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.
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.