i&#x27;d be curious what makes this a useful abstraction compared to thinking about providing useful features with simple interfaces?<p>i can easily see that reducing state implies reducing the number of steps a user takes to solve a problem (since each step implies some state somewhere).<p>what i can&#x27;t see is how it implies that we must implement a new feature. this seems to be the real driver behind solving the &quot;revision pinning&quot; problem in the article - the fact that it is preventing state from changing unexpectedly seems to be coincidental based on what the user actually desires. and actually the solution adds more state - pinned version numbers (or repo hashes, or URLs etc...)<p>personally when approaching these problems i try thinking about things like &quot;what features are needed to solve the user problems?&quot; and &quot;how can the interface for features as simple as possible?&quot;. it seems a lot simpler as an approach, more intuitive, and can be extended to be made more useful (e.g. &quot;how do i make feedback as clear as possible?&quot;). some of these questions are very complicated to answer, especially since they might involve things like user&#x27;s mood or past experiences... i think that just shows that this is a complicated problem space.<p>minimising statefulness feels sort of &quot;necessary&quot; rather than &quot;sufficient&quot;, and only in some cases. i&#x27;d be curious if there is any proof or reasoning to show that it has desirable properties beyond the clear connection to reducing needless user interactions.