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

From: Grant Rettke (grettke at acm.org)
Date: Tue May 15 23:16:13 EDT 2007

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.


Posted on the users mailing list.