Hi Grant - <br><br>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. <br><br>Thanks,<br>yinso <br><br><div><span class="gmail_quote">
On 5/15/07, <b class="gmail_sendername">Grant Rettke</b> <<a href="mailto:email@example.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">firstname.lastname@example.org</a>> wrote:</span><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:email@example.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">firstname.lastname@example.org</a>> wrote:<br>> Hi Grant -<br>><br>> I am definitely interested in both as you described, but this is definitely
<br>> about a question about design and changing of programming paradigm.
<br><br>The question is "What is the best abstraction by which we may<br>represent both our problem and the solution to our problem?"<br><br>> Enterprise project is about moving data around, and you are right, at the
<br>> end of the day it's not rocket science. But maybe because it's not rocket<br>> science, it is just so much easier to conceive them as objects and classes,<br>> along with dealing with data input, validation, persistence, and query.
<br>> Boring, but works.<br><br>Is it easier or is it familiar? Remember that C was used for<br>enterprise projects for a long time and was considered to be "normal".<br>Show one of those projects to todays enterprise programmers and
<br>they'll pass out. Collectively the industry has said that for %80 of<br>the work, OO is the abstraction we will use not matter if the solution<br>is a good fit or not. Luckily, it is a great fit more than %80 of the
<br>time when it comes to enterprise projects.<br><br>> The complexity in enterprise projects come from the numerous object's<br>> interdependencies and specializations, i.e. each object is just different<br>> enough from another object that it requires additional code. Hence OOP's
<br>> ability to couple data with behavior helps with code organization.<br><br>OO is a good way to abstract the solution, but I've worked on plenty<br>of (small by many folks standards, 5-10 developers) projects that had
<br>200+ classes.<br><br>I don't know much about FP, but I do know that Scheme is all about<br>empowering the developer to choose the right abstraction. That is the<br>important thing whatever language you use, choose the right
<br>abstraction and your problem will be easier to solve.<br><br>For the project on which I am working, we are using Java, and there<br>are still plenty of abstractions from which to choose for the UI,<br>persistence, and data representation, to start with. It is all OO
<br>work, and it is a good fit. While there are definitely places where FP<br>could be an interesting fit, they fall into the area where %20 of the<br>work falls. They wouldn't be a good investment.<br></blockquote></div>