damodar kulkarni wrote:
Curiously, whenever I use state, my programs start to become similarly brittle. There is no reason why state should be a fundamental element of a programming language, and as a design pattern, state is best avoided at all cost.
Just as a curiosity, how would one avoid state in cases like protocol design? e.g. protocols specifications (like TCP/IP) do have a large element of state dependent behavior that "seems essential" to the problem. How would one deal with such cases?
Well, in a protocol like TCP/IP, the response of a participant does depend on the history of the communication, and that history can neatly be summarized in a small amount of state. I don't think it's possible to avoid state in this case. But I meant something else, actually, and should have been more precise. Namely, it is best to avoid *mutable* state as a *design pattern*, i.e. the use of IORef and thelike. Pure functions State -> State are fine, but anything were the meaning of an expression depends heavily on the context (the program state) is prone to bugs. The problem is more about source code than it is about state. To avoid bugs, each piece of source code should be understandable in isolation, i.e. it should give the same results in all contexts ("code paths"). This way, it is a lot easier to determine its correctness. Of course, "source code" has different scales, and can include protocol design. After all, protocols are made by humans, and clever design can prevent headaches later. For instance, HTTP GET requests were designed to be stateless, and that makes the protocol a lot more robust. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com