Part of the craft of programming is expressing a computation or interaction as simply as possible. Now, somehow the original point (http://prog21.dadgum.com/54

Part of the craft of programming is expressing a computation or interaction as simply as possible. Now, somehow the original point (http://prog21.dadgum.com/54.html http://prog21.dadgum.com/54.html) has missed its mark. The original point was this: that for certain kinds of interactions, an imperative solution with shared state solution is vastly less complicated and preferable to a purely functional solution. This is because in some cases the purely function solution will litter a whole hierarchy of function calls or an entire set of data structures with additional data, but the imperative, stateful solution will not. Now, obviously the problem with imperative is: "...that state gets threaded everywhere, and you can't look at any function individually and know how it will behave." But what is the problem with functional programming? That you can't look at any bit of state in the program unless some other part of the program has explicitly given it to you. Now, I'd say that 95% of the time I'd rather have that problem than the problems that come with state - like having to worry about call order semantics, reentrancy, etc etc. But dammit - 5% of the time I'd rather use the state and be done with it! And more generally speaking, 100% of the time I'd rather have a concrete example of something that is implemented simply today than an abstract idea of why something might be complicated in the future.