Software Entropy

I think the intro description introducing entropy is missing something. If the shoe closet sorted by color and the chaotic one are both composed of the same set of shoes then they have equal entropy. You can transpose any two shoes of the same color to achieve an additional microstate whether or not they&#x27;re arranged by color.<p>I suppose it&#x27;s technically correct if what you&#x27;re interested in is the ways shoes can be positioned in a closet, but why bring up color then? The example sets up a comparison between some small finite number of ways to arrange shoes on a shelf and potentially infinite ways to arrange them in a pile. Better, I&#x27;d say, to stick to a grid in both cases and compare the number of microstates in the &quot;all black&quot; macrostate against the number of microstates in the &quot;half brown half black&quot; macrostate.

This is a description of Kolmogorov entropy.

This view is too simplistic. I&#x27;ve come to the realization that ultimately software is complex because it models some very complex real-world situation. E.g. how complex can tax software be? Answer: as complex as the tax code, which is not just complex, but also contains tons of unspecified behavior. Yes, sometimes you can take a simple problem and write spaghetti code for it, but IME that is often not the real problem.

This reasoning here is severely mistaken.<p>Static typing does not change the complexity dynamics of your programming model. It&#x27;s a mere tool.<p>If I statically type to DateTime I can still be wildy baffled to see a transaction take place in the future. Or even more baffled when at first glance the DateTime looks correct (ie in the <i>past</i> and recent) but to find out later when I get the support phone call that we incorrectly tallied the balance.<p>Static typing just restricts where I can put my shoes in my closet. If I find a need to sort all the &quot;righties&quot; together -- for example, to figure out how many lefties I&#x27;m short -- static typing makes things <i>more</i> complex -- because it will <i>disallow</i> this innovation.<p>Complexity is a count of <i>concepts</i> in your model, not a count of <i>instances</i> and not a count of state possibilities, which in any <i>real world</i> system are going to be endless no matter how much you waste time with static proofs.

&quot;You should call it entropy [...] nobody knows what entropy really is, so in a debate you will always have the advantage.&quot; John Von Neumann to Claude Shannon<p>(also why there is clearly of market for the concept of dynamic entropy: <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;2318&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;2318&#x2F;</a> )

Using TLA, spin and others will help compute actual numbers to see reachable states etc