As I learn and discover more about functional programming each day, I personally feel that have I wasted these many years (over 15+) in working with objects and object orientation… It does leave me frustrated to an extent, but hey, its never too late to pick up things.
I just feel bad that with typical web apps what we really do is take the data, convert it to object hierarchy and graphs and eventually persist them in some Relational DB using an OR mapper; only to be read back as some view or to be iterated over a collection of objects for projections or aggregated views. Just makes me feel stupid….all these years, did I do that type of work and get paid?
I ask further – Why do we need these intermediary steps, when data can simply be transformed by transforming operations like flat map, map, groupBy etc… in a functional way? Why do we have to do this lifting with heavy tooling like objects? Can we not use the data as it is and avoid casting them into objects?
When we design objects, we really make decision about the design of data and the operations that work on that encapsulated data. With that, we have confined that data (as well as the operations that are possible on that data) within the boundaries of an object. This object representation of information in problem domain is in some sense like pre-mature optimisation. In other words, as my friend – Ryan Lemmer says – “we have poured concrete on the data and essentially lost the plasticity” – or the liquidity, which is inherent with data when left uncasted.
This is because the pace at which business changes, forces a change in the information that needs to be viewed and manipulated. This in turn means, that the representation of that information (i.e data) changes and the question then is….can these Objects which are like “concretes” be morphed to a new form with least resistance? If we did not have them in first place, we would then have been able to deal with that information directly without having to go through the additional layer of object graphs and hierarchies and persist it using some OR mapper, thus avoid wading through viscosity.
Also, the entropy is quite high in systems that front-end the business directly, and modelling using objects may not be best way to deal with that at this inter-change, where fluidity is an essential trait to meet business needs. Instead, object modelling may be more suitable for parts in the system that are relatively stable from business perspective (less frequently changing parts).
All I am saying is that the cost of changing the objects here is higher as compared to cost of changing data in its original form. So, would it make more sense to approach this in Data-Driven fashion rather than Object-Driven (Domain-Driven) fashion at inter-changes where changes are frequent?
Further, as I look at the talk by Dean Wampler (thanks again Ryan for this link), I feel quite convinced about the thoughts above.
He goes on to say that for apps to work with large volumes of Data (at scale – Big Data), going functional is a necessity. OO would not cut it…
Also, I really like the way he says – “as God intended”….true that!
expertalks.wordpress.com 
check out CLOS, OOPS is not JAVA or even C++.