[plt-scheme] Re: Thinking in FP vs OOP for large scale apps

Thanks Chongkai -

below are some of my clarifications and comments and hopefully I don't cause
the thread to degenerate ;)

On 5/15/07, Chongkai Zhu <czhu at cs.utah.edu> wrote:
>
> > > How to think in FP rather than OOP, especially for large scale apps?
>
> > First of all, FP/OOP and danamic/static typing is two totally different
> idea. Languages such as ML and haskell are both static typing >and FP.


Agreed - I didn't attempt to separate the two concepts in my messages as
much as I probably should have - my fault (I do realize Haskell & ML family
are strongly typed and FP).

The reason I lumped them together has to do with types and dispatch - I seem
to come across (cond ((number? x) ...) ((string? x) ...)) quite often so far
in Scheme, and dispatch by type is a central concept in OOP.  I can ask this
question separately, but I just thought that they are related ;)

> Second, I can't see any intrinsical difference between FP and OOP. Scheme
> is the result of merging FP and OOP.


(aside: my understanding is that Scheme is quite a bit of FP, with OOP
bolted on as optional features - i.e. class.ss is not part of R5RS, but I'm
likely misinformed...)

IMHO there are differences between OOP & FP, especially in the concepts that
they embodied.  OOP promotes statefulness via data encapsulation, whereas
pure FP promotes statelessness.  OOP promotes binding between methods and
data (as you know- I am talking about mostly single-dispatch class systems
like C# & Java) , and FP appears to promote loose coupling between functions
and data.  etc.  And the main difference for me personally is that I can
think about a whole large app in objects, but have difficult to do so with
only functions (the original thread on imperative flow John/Anton describe
that FP allows piecing an app together - it's the piecing together that I am
missing here...).

i.e. it is natural to represent GUI windows, menus, buttons, etc as
objects... how would one represent such in FP style?  It is simple to model
a database schema as one class per table... how would one represent such in
FP style?  At large app level I am so accustomed to think in objects so it's
difficult for me to see things differently and would love some
enlightenment.

Gene has sent me a few source code links for studying, so I'm going down
that path, but would love to hear from others who have gone down the path of
constructing large scale FP-based applications on their experiences.  If the
answer is such that it makes better sense to structure some parts of program
in FP and some other part of program in OOP and this is why modeling such
and such in FP or OOP is better, that's what I am after as well, i.e. why FP
style suites a particular problem domain better, and vice versa ;)

> Third, by making proper use of macros, the code size should be much
> smaller.


Couldn't agree more on this point ;)

Chongkai


Thanks,
yinso
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070515/31173081/attachment.html>