Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!ut-sally!seismo!gatech!akgua!whuxlm!whuxl!houxm!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsb!robison
From: robison@uiucdcsb.CS.UIUC.EDU
Newsgroups: net.lang
Subject: Re: Functional vs. Object-Oriented
Message-ID: <8900036@uiucdcsb>
Date: Fri, 27-Jun-86 19:10:00 EDT
Article-I.D.: uiucdcsb.8900036
Posted: Fri Jun 27 19:10:00 1986
Date-Received: Mon, 30-Jun-86 04:46:43 EDT
References: <8900035@uiucdcsb>
Lines: 36
Nf-ID: #R:uiucdcsb:8900035:uiucdcsb:8900036:000:1481
Nf-From: uiucdcsb.CS.UIUC.EDU!robison    Jun 27 18:10:00 1986


The two paradigms do not necessarily contradict each other.  
There is a paper in the reference listed below that shows
how a functional language can incorporate objected-oriented
language features.  One way of looking at it is that when an
object receives a message, a new object must be generated, i.e.
call-by-value semantics are required.  By doing such, the polymorphism 
and data encapsulation of Smalltalk can be added to a functional
language.

Also, if one allows lazy evaluation in a functional language,
then infinite lists behave like message streams.  Thus the
two approaches converge in another way.

I think the two paradigms represent different frames of reference.
In the Smalltalk model, you stand on the objects and watch the
operations go past.  In FP, you stand on the functions and watch the
objects go past.  It is sort of a programming relativity.

Here's the reference.  I can't remember which paper described the
object-oriented FP, but it shouldn't be too hard to find.

Reference:

     J. Darlington, J.V. Guttag, P. Henderson, J.H. Morris, J.E.Stoy, 
     G.J. Sussman, P.C. Treleaven, D.A. Turner, J.H. Williams, D.S. Wise
     *Functional Programming and its Applications*,
     Edited by J.Darlington, P. Henerson, and D.A. Turner. 
     Cambridge University Press
     1982

Arch D. Robison
University of Illinois at Urbana-Champaign

P.S. Both paradigms also share another common property: they are both
     difficult to implement efficiently!