A caller of a function in an imperative environment cannot assume anything about the scope of that function's access of mutable state within the program. My characterization of the situation might be a little spectacular w.r.t. specifics (e.g. 316 arguments, etc), but I've not seen a robust refutation of the principle.
There's no doubt that there is subjectivity w.r.t. practices and methodologies, not to mention domain-specific tendencies and requirements. But it's a little absurd to claim that, very specifically, mutable state is on par with persistent data structures (or, at the very least, immutable state constructs) on almost any axis of reliability or ability to reason about a program's operation, especially in conjunction with any degree of concurrency.
"Pain" is definitely subjective. IMO, if you're not feeling at least a little pain, you're not pushing your skills, your craft, etc. Too much pain, and it's possible you've not kept yourself limber enough to stretch for the big wins, regardless of context.
"A caller of a function in an imperative environment cannot assume anything about the scope of that function's access of mutable state within the program"
This really doesn't make sense.
main() {
A a = new A();
f();
...
}
the caller main() can assume that "a" is not in scope of f().
Is it the robust refutation you need ?
The caller can further assume that the scope of f() is limited to the part of the state for which there is a path from a global variable or from one of its parameters (You can see the state as a graph. The nodes are the data and the links are the references) Therefore, this scope is not the whole state but a limited subset of the state.
Claiming otherwise is wrong and does not help to bring attention to what need to be improved : this subset is itself a superset of the part of the state that the function really need. We need new techniques to hide more state to the function, for example some kind dereferencement control ?
I believe cemerick meant, "A caller of a function in an imperative environment cannot assume anything about the scope of that function's access of mutable state within the program without reading the entire program." If they verify it by perfectly understanding the underlying code, the of course that doesn't hold.
But even in the code snippet you gave us, we really don't know if global state is being manipuated. For example, A could be handling global counters or referencing global variables (common example: stdin and stdout). And how do you know that a doesn't get manipulated by f()? You'd have to check! Perhaps A's constructor registers all A's it every creates and then f() marks all A's for protection from garbage collection?
Really, we can't assume anything about the code snippet you gave us without verifying it. The code might be modular, it might be reasonably modular, or it might be a complete mess.
This boundary of uncertainty is what functional programmers are railing against, and what you're defending.
