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

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

On 5/15/07, Grant Rettke <grettke at acm.org> wrote:
>
> 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 ADO.NET), UIs (Swing,
> JSF, ASP.NET, 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070515/ffd4c059/attachment.html>