<story><title>Linus Torvalds: Git proved I could be more than a one-hit wonder</title><url>https://www.techrepublic.com/article/linus-torvalds-git-proved-i-could-be-more-than-a-one-hit-wonder/</url></story><parent_chain><item><author>cmarschner</author><text>To me the beauty of git stems from the fact that it is an implementation of a functional data structure. It‘s a tree index that is read-only, and updating it involves creating a complete copy of the tree and giving it a new name. Then the only challenge is to make that copy as cheap as possible - for which the tree lends itself, as only the nodes on the path to the root need to get updated. As a result, you get lock-free transactions (branches) and minimal overhead. And through git‘s pointer-to-parent commit you get full lineage.
It is so beautiful in fact that when I think about systems that need to maintain long-running state in concurrent environments, my first reaction is ”split up the state into files, and maintain it through git(hub)“.</text></item></parent_chain><comment><author>combatentropy</author><text>&amp;quot;. . . unlike every single horror I&amp;#x27;ve ever  witnessed when looking closer at SCM products, git actually has a simple design, with stable and reasonably well-documented data structures. In  fact, I&amp;#x27;m a huge proponent of designing your code around the data, rather than the other way around, and I think it&amp;#x27;s one of the reasons git has been fairly successful. . . .&lt;p&gt;&amp;quot;I will, in fact, claim that the difference between a bad programmer  and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.&amp;quot;&lt;p&gt;--- Linus Torvalds, &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;lwn.net&amp;#x2F;Articles&amp;#x2F;193245&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;lwn.net&amp;#x2F;Articles&amp;#x2F;193245&amp;#x2F;&lt;/a&gt;</text></comment>
<story><title>Linus Torvalds: Git proved I could be more than a one-hit wonder</title><url>https://www.techrepublic.com/article/linus-torvalds-git-proved-i-could-be-more-than-a-one-hit-wonder/</url></story><parent_chain><item><author>cmarschner</author><text>To me the beauty of git stems from the fact that it is an implementation of a functional data structure. It‘s a tree index that is read-only, and updating it involves creating a complete copy of the tree and giving it a new name. Then the only challenge is to make that copy as cheap as possible - for which the tree lends itself, as only the nodes on the path to the root need to get updated. As a result, you get lock-free transactions (branches) and minimal overhead. And through git‘s pointer-to-parent commit you get full lineage.
It is so beautiful in fact that when I think about systems that need to maintain long-running state in concurrent environments, my first reaction is ”split up the state into files, and maintain it through git(hub)“.</text></item></parent_chain><comment><author>BenoitEssiambre</author><text>I sometimes like to explain things the other way around in terms of functional programming immutability being like version control for program state.&lt;p&gt;I rarely use functional programming but I certainly see its appeal for certain things.&lt;p&gt;I think the concept of immutability in functional programming confuses people. It really clicked for me when I stopped thinking of it in terms of things not being able to change and started instead to think of it in terms of each version of things having different names, somewhat like commits in version control.&lt;p&gt;Functional programming makes explicit, not only which variables you are accessing, but which version of it.&lt;p&gt;It may seem like you are copying variables every time you want to modify them but really you are just giving different mutations, different names. This doesn&amp;#x27;t mean things are actually copied in memory. Like git, the compiler doesn&amp;#x27;t need to make full copies for every versions. If it sees that you are not going to reference a particular mutation, it might just physically overwrite it with the next mutation. In the background &amp;quot;var a=i, var b=a+j&amp;quot;, might compile as something like &amp;quot;var b = i; b+=j&amp;quot;;</text></comment>