In typical concatenative code, a function usually has only 1–2 inputs and outputs, so it only ever uses a tiny part of the “implicit state” (typically a stack)

In typical concatenative code, a function usually has only 1–2 inputs and outputs, so it only ever uses a tiny part of the “implicit state” (typically a stack) being passed between functions. It’s not much different than configure(authenticate(connect(open()))); in a C-style language. Those functions might be returning and accepting all kinds of complex objects or tuples, but you can use purely local reasoning and just treat that expression as a pipeline of black boxes, as long as the inputs and outputs match up. Static types help a lot with this (and I’ve actually been working on a statically typed concatenative language for a while) but even basic arity checking (as in Factor) is enough to make it a very minor issue. To me, the point is not that you should avoid local variables entirely. Rather, it’s that most code doesn’t actually need local variables to be perfectly readable, because the most common dataflow patterns in regular business logic can be captured by simple composition of functions.