Hi Grant - Thanks.  As you said, choosing the best abstraction for the job and that OOP is best today because it's most familiar - we are in agreement here.  My question for asking these questions isn't to debate that point, but rather to educate myself on another paradigm ( i.e. FP), so I can intelligently choose the best abstractions - otherwise the best abstraction (i.e. OOP most of the time) is best only because it's most familiar. Thanks, 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;"> On 5/15/07, YC <<a href="mailto:yinso.chen@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">yinso.chen@gmail.com</a>> wrote: > 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. The question is "What is the best abstraction by which we may represent both our problem and the solution to our problem?" > 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. Is it easier or is it familiar? Remember that C was used for enterprise projects for a long time and was considered to be "normal". Show one of those projects to todays enterprise programmers and they'll pass out. Collectively the industry has said that for %80 of the work, OO is the abstraction we will use not matter if the solution is a good fit or not. Luckily, it is a great fit more than %80 of the time when it comes to enterprise projects. > 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. OO is a good way to abstract the solution, but I've worked on plenty of (small  by many folks standards, 5-10 developers) projects that had 200+ classes. I don't know much about FP, but I do know that Scheme is all about empowering the developer to choose the right abstraction. That is the important thing whatever language you use, choose the right abstraction and your problem will be easier to solve. For the project on which I am working, we are using Java, and there are still plenty of abstractions from which to choose for the UI, persistence, and data representation, to start with. It is all OO work, and it is a good fit. While there are definitely places where FP could be an interesting fit, they fall into the area where %20 of the work falls. They wouldn't be a good investment. </blockquote></div>