I was working on a CAD program in OCaml a year ago. It was an interesting exercise on what exactly is state, and what needs state and what state isn't (I'll po

I was working on a CAD program in OCaml a year ago. It was an interesting exercise on what exactly is state, and what needs state and what state isn't (I'll post the program once I salvage my svn repo off the old HDD). In short, I found that the most useful definition of state is a set of data that is interrelated or correlated in some way, shape or form, but in actual usage, those pieces of data interact weakly. In terms of graph theory, if you were to say that we live in a purely functional world, and all functions are bipartite graphs from one set of points to another set of points, then "state" could be defined as those points where the functions involved are sparse. Sparse can be defined as: -most of the vertices involved are untouched in any given function -all of the vertices are involved in one function or another -all of the vertices are related in that you can reach one vertex from another by following the edges of the graph. Using that definition of state, I found that it was easy to program everything in a purely functional, no-side-effects paradigm, in OCaml, without using the object system. Furthermore, I found that the stateful bits tended to grow in an annoyingly stateful manner, that is that they added edges to the graph at random (i.e. it was hard to tell ahead of time what depended on what). The difficulty in using named tuples to store state as such is that then all the bits that need to modify state need to pass it around continuation style, and it can be hard to know ahead of time when you want to be in the stateful context or not. Haskell beginners (like me) will understand this to be the "do I need to be in the IO monad" problem. Indeed, the problem seems to manifest itself differently in Haskell, but I am not sure of this yet because I'm still learning Haskell. Some hunches: - I concluded that statefulness seems to be a function of what you are building for. UI is stateful, but the backend work that supports it is not. -> Since the web's architecture enforces a client-server model, I argue that the whole statefulness debate is going to become moot for the backend supporting those services. Hybrid languages will be nice, but not really necessary. - Cellphones, with their need for a self-contained platform that can operate somewhat independently of whether the connection is operating or not, may benefit from hybrid languages.