Hi Grant - I am definitely interested in both as you described, but this is definitely about a question about design and changing of programming paradigm. Enterprise project is about moving data around, and you are right, at the end of the day it's not rocket science.  But maybe because it's not rocket science, it is just so much easier to conceive them as objects and classes, along with dealing with data input, validation, persistence, and query.  Boring, but works. The complexity in enterprise projects come from the numerous object's interdependencies and specializations, i.e. each object is just different enough from another object that it requires additional code.  Hence OOP's ability to couple data with behavior helps with code organization.  As I explore FP I get the sense that FP is about decoupling data from behavior (as an example, in C++ STL is the quintessential example... quite a beauty, but a lot of C++ on Windows are done using MFC and others that are more in traditional sense of OOP; another example, CLOS also decouples behavior from data), and basically it's a different way of design/organizing problem for me... is this "better" - in the sense that I would end up writing fewer lines of code?  That's why I am interested to hear about other's experiences ;)  yinso <div>On 5/15/07, Grant Rettke <<a href="mailto:grettke@acm.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> grettke@acm.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Are you more interested in getting someone's account of using FP for a "real world enterprise project" or in hearing what folks thing about what Scheme offers over "OO alone"? I can comment on the latter, but not the former. "Enterprise projects" are usually about moving data around, modifying it, analyzing and reporting on it. Yes, it is difficult and has real problems, but then again, after you've done a few successful projects you realize that while it is to be taken seriously, it is not rocket science. One big goal for "enterprise folks" is to mitigate their risk, and one way to do that is to implement systems that are maintainable by just about anyone. That way, if folks leave, and documentation disappears, and the system lasts for years longer than expected (all of these things *will* happen), then said company can get a reasonably priced individual off the street and have them working on the reasonably quickly. One way to do this is to limit your programming language to a small set of abstractions because although you end up with a lot more code just to express something, and it will be more difficult to understand, said person off the street *will* be able to understand it, and then maintain it. "Enterprise languages" are all about limiting abstractions to make it easier to make commodities out of the developers. This makes a lot of sense. Add to this excellent tools to "get the job" done of representing data (JPA or <a href="http://ADO.NET" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ADO.NET</a>), UIs (Swing, JSF, <a href="http://ASP.NET" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> ASP.NET</a>, Winforms), and every transport layer in between, and you've got a reasonably good investment in the longer run. From this angle, a more expressive language would offer more productivity gains, but would decrease the available pool of resources to maintain that system. Perhaps this is why you here more about LISP-like languages being used at startups and in niche areas. That said, you *can* use LISP-like languages to solve your problems, and generate the implementation of your solution in your desired "Enterprise" language. </blockquote> </div>