Late answer, but nevertheless... I don't particularly think that it's a good idea, but I believe that the original intention was to build "living" data. So you

Late answer, but nevertheless... I don't particularly think that it's a good idea, but I believe that the original intention was to build "living" data. So you would look at your object structure and could treat it as data, but internally some objects could be proxies to backend system and fetch data on-demand. Some data fields might also be calculated from other fields. This is the idea which Java promotes by having the JavaBean standard. You never know if your data element is backed by actual data or is the result of a computation. This type of abstraction can simplify certain problems by giving the illusion of a simple data structure, whereas a lot of computations are taking place behind the scene when the data is traversed. This abstraction is used in may ORM frameworks for instance. You can follow relations between entities and these will be lazily loaded behind the scene as you move around in the object graph. The problem is that such a living object can only live in its own environment. For ORMs, you cannot move outside the current DB transaction, or else the objects "die". To see some of these problems in the Java world, google "LazyInitializationException". Pure data, on the other hand, is "dead by definition" so to speak. It does not contain any own logic and can be moved between environments without any problem. The backside of pure data is the very fact that it is dead, that is that you often have to accompany it with logic to interpret it. With live objects, the interpreting logic is intertwined with the data. This is both the advantage and flaw of OO. With OO, you have data and logic close together, and have to pay the price if you try to pry them apart. With FP, you have the data separately, and have to cope with the mental load of knowing which logic you need to apply where in your data structures in order to interpret them.