Thinking in FP vs OOP for large scale apps => Re: [plt-scheme] Imperative programming : missing the flow

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

On 5/15/07, Grant Rettke <grettke at acm.org> wrote:
>
> On 5/15/07, YC <yinso.chen at gmail.com> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070515/4b6f0075/attachment.html>