<story><title>When it comes to Git history, less is more</title><url>https://brennan.io/2021/06/15/git-less-is-more/</url></story><parent_chain><item><author>cellularmitosis</author><text>It is a shame that we don’t have better tools, and that we are still hand-editing text files in order to write programs.&lt;p&gt;Imagine having an editor which automatically applied your local preferences around tabs&amp;#x2F;spaces, code formatting, variables up top vs nearest use, function definitions nested to minimize top-scope surface area vs all functions flat at top scope, etc etc etc&lt;p&gt;And when you are done editing, all of these local changes are reversed and you submit the minimal possible diff.&lt;p&gt;(and if we want to really talk pipe dreams, the dev only sees an AST editor and the underlying text is never even exposed in the first place)&lt;p&gt;Our tools are so far behind mostly because everyone’s thinking is still chained to 1970’s hand editing text files mentality.  This is the flying car which isn’t being worked on because everyone is still thinking about making better bicycles.</text></item></parent_chain><comment><author>ajuc</author><text>The benefit is minimal, the task is hard, there&amp;#x27;s decades worth of tools that won&amp;#x27;t work, and it&amp;#x27;s easy to mess up introducing &amp;quot;impossible bugs&amp;quot; with behind-the-scenes transformations.&lt;p&gt;Also - AST isn&amp;#x27;t THAT important when reading the code. Let&amp;#x27;s say I give you this:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    X (X X X X; X X X; X X) {
        X (X X X) {
           X(X X X X X)
        }
    }
&lt;/code&gt;&lt;/pre&gt;
Do you know what this code does? How about this:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    for int i = 0 i &amp;lt; 10 i ++ if i % 2 printf &amp;quot; %d &amp;quot; , i
&lt;/code&gt;&lt;/pre&gt;
I&amp;#x27;ve used several graphical languages professionally (not AST-based, graph-based, but the problem remains) and the main problem was - structure wasn&amp;#x27;t fully describing what happens - the &amp;quot;meat&amp;quot; of the behaviour was still in text form and was hidden behind the pretty graphic form - in case of both of these languages the meat was in the names of the subprocesses called and in the mapping of process variables &amp;lt;-&amp;gt; subprocess parameters.&lt;p&gt;And there were A LOT of these, so you couldn&amp;#x27;t show them at once on the same screen as the graphical view of the process. So programming with both of these languages was very frustrating - you had to click on each node and look through long lists of x:y substitutions to track how parameters flow through the system.</text></comment>
<story><title>When it comes to Git history, less is more</title><url>https://brennan.io/2021/06/15/git-less-is-more/</url></story><parent_chain><item><author>cellularmitosis</author><text>It is a shame that we don’t have better tools, and that we are still hand-editing text files in order to write programs.&lt;p&gt;Imagine having an editor which automatically applied your local preferences around tabs&amp;#x2F;spaces, code formatting, variables up top vs nearest use, function definitions nested to minimize top-scope surface area vs all functions flat at top scope, etc etc etc&lt;p&gt;And when you are done editing, all of these local changes are reversed and you submit the minimal possible diff.&lt;p&gt;(and if we want to really talk pipe dreams, the dev only sees an AST editor and the underlying text is never even exposed in the first place)&lt;p&gt;Our tools are so far behind mostly because everyone’s thinking is still chained to 1970’s hand editing text files mentality.  This is the flying car which isn’t being worked on because everyone is still thinking about making better bicycles.</text></item></parent_chain><comment><author>spaetzleesser</author><text>Agreed. It seems silly that we still have to deal with things like tabs vs spaces or formatting in different ways. This should be handled by IDEs and editors.</text></comment>