[jheriko]

i'd be curious what makes this a useful abstraction compared to thinking about providing useful features with simple interfaces?

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).

what i can't see is how it implies that we must implement a new feature. this seems to be the real driver behind solving the "revision pinning" 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...)

personally when approaching these problems i try thinking about things like "what features are needed to solve the user problems?" and "how can the interface for features as simple as possible?". it seems a lot simpler as an approach, more intuitive, and can be extended to be made more useful (e.g. "how do i make feedback as clear as possible?"). some of these questions are very complicated to answer, especially since they might involve things like user's mood or past experiences... i think that just shows that this is a complicated problem space.

minimising statefulness feels sort of "necessary" rather than "sufficient", and only in some cases. i'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.