RE: "I'm sure there's some way that we can see this as a form of single responsibility violation." Agreed. More precisely, there are two violations, one of the responsibility rule, one of the open/closed principle. (As you suggest in a recent article, these violations tend to be coupled.) First, the traditional if/then/else control structure tightly (via syntax) couples the responsibilities of "observing a condition" with "action based on that condition". Second, we're forced to squeeze all the conditional actions into one block, i.e. the if/then/else actions are open to modification but closed to extension. It isn't a surprise that we end up invasively modifying code to add more actions, rather than extending a condition with more actions. RE: "What can we do?" We solve those problems! It isn't difficulty, and answers already exist. My own favorite is based on ArrowChoice in Haskell: a condition is expressed as a sum-type value (a + b), and conditional action is expressed by `left :: (a ~~> a') -> ((a + b) ~~> (a' + b))`. I favor a more monadic variation that also separates the conditional action from the point of application: `leftM :: ((a ~~> a') * (a + b)) ~~> (a' + b)`. The technique you're describing is closer to using numbers as conditionals based on `f^4 = f . f . f . f` vs. `f^0 = id`. This isn't open to extension, though, since the number is 'consumed' by this expression form. So I wouldn't recommend it as a general technique.