<story><title>Clean your codebase with basic information theory</title><url>https://taylor.town/compress-code</url></story><parent_chain><item><author>valty</author><text>&amp;gt; In my experience, the key to maintaining readability is developing a healthy respect for locality&lt;p&gt;I think this pursuit of &amp;quot;locality&amp;quot; is what actually causes more complexity. And I think its mainly around our obsession with representing our code as text files in folder hierarchies.&lt;p&gt;&amp;gt; coarsely structure codebases around CPU timelines and dataflow&lt;p&gt;This is why I would prefer code to be in a database, instead of files and folders, so that structure doesn&amp;#x27;t matter, and the tree view UI can be organized based on runtime code paths, and data flow - via value tracing.&lt;p&gt;&amp;gt; don’t pollute your namespace – use blocks to restrict variables&amp;#x2F;functions to the smallest possible scope&lt;p&gt;Everyone likes to be all modular and develop in tiny little pieces that they assemble together. Relying on modularization means that when stuff changes upstream in the call stack, we just hack around these changes adding some conditionals to handle these changes instead of resorting to larger refactors. People like this because things can keep moving instead of everything breaking.&lt;p&gt;Instead, what we need to do is make it easier to trace all the data dependencies in our programs so that when we make a change to anything, we can instantly see what depends on it and needs updating.&lt;p&gt;I have actually started to think that, against conventional wisdom, everything should be a global variable. All the issues with global variables can be solved with better tracing tooling.&lt;p&gt;Instead we end up with all these little mini-databases spread all over our code, when what we should have is one central one from which we can clearly see all the data dependencies.&lt;p&gt;&amp;gt; group related concepts together&lt;p&gt;Instead, we should query a database of code as needed...just like we do with our normalized data.</text></item></parent_chain><comment><author>verinus</author><text>I was thinking about code along the same lines: we are modeling, not writing text. 
This just happens to be the best way to express our models in a way a computer can be made to understand it, be formal enough and still be understandable by others.&lt;p&gt;What current languages are bad about is expressing architecture, and the problem of having one way to structure our models (domain models) vs. the actions&amp;#x2F;transformations that run on them (flow of execution).&lt;p&gt;I strongly disagree on the global variable side though...</text></comment>
<story><title>Clean your codebase with basic information theory</title><url>https://taylor.town/compress-code</url></story><parent_chain><item><author>valty</author><text>&amp;gt; In my experience, the key to maintaining readability is developing a healthy respect for locality&lt;p&gt;I think this pursuit of &amp;quot;locality&amp;quot; is what actually causes more complexity. And I think its mainly around our obsession with representing our code as text files in folder hierarchies.&lt;p&gt;&amp;gt; coarsely structure codebases around CPU timelines and dataflow&lt;p&gt;This is why I would prefer code to be in a database, instead of files and folders, so that structure doesn&amp;#x27;t matter, and the tree view UI can be organized based on runtime code paths, and data flow - via value tracing.&lt;p&gt;&amp;gt; don’t pollute your namespace – use blocks to restrict variables&amp;#x2F;functions to the smallest possible scope&lt;p&gt;Everyone likes to be all modular and develop in tiny little pieces that they assemble together. Relying on modularization means that when stuff changes upstream in the call stack, we just hack around these changes adding some conditionals to handle these changes instead of resorting to larger refactors. People like this because things can keep moving instead of everything breaking.&lt;p&gt;Instead, what we need to do is make it easier to trace all the data dependencies in our programs so that when we make a change to anything, we can instantly see what depends on it and needs updating.&lt;p&gt;I have actually started to think that, against conventional wisdom, everything should be a global variable. All the issues with global variables can be solved with better tracing tooling.&lt;p&gt;Instead we end up with all these little mini-databases spread all over our code, when what we should have is one central one from which we can clearly see all the data dependencies.&lt;p&gt;&amp;gt; group related concepts together&lt;p&gt;Instead, we should query a database of code as needed...just like we do with our normalized data.</text></item></parent_chain><comment><author>Sakos</author><text>I think the main problem is that we think of code as text. So the only way to determine if code is related is by parsing all of the text again. I&amp;#x27;m not sure if a database representation is really the correct path to take, but I think we need some other way to represent code and give parts of code meaning.</text></comment>