Re: Functional Programming in the Larger or Functional Oriented Software Engineering

On 14 Mar 2007, at 13:13, Lewis Brown wrote:

> Hello.
>
>
>
> Several years back on this list there was a great discussion about  
> what ought to be the basic, elemental foundation of a language: the  
> function or the object.
>
>
>
> The object school has developed a huge volume of literature to  
> address the engineering issues involved with “Programming in the  
> Large.” It has given us not just languages, but processes, modeling  
> languages, etc.
>
>
>
> It would seem that the functional school has been relatively mute  
> on this topic.
>
>
>
> Does this imply that, despite your choice of foundational element,  
> all large systems require objects to manage the complexities? Is  
> that why so many functional language implementations usually offer  
> at least one ‘flavor’ of object system?

I see two possible reasons:

- Functional programming seems to require more abstract thinking than  
object-oriented programming. Objects seem to be more tangible than  
functions. The idea of presumably better being able to model the  
"real world" is related, because I guess a simplified physicality of  
the "real world" is implicitly assumed here. (I don't understand what  
"modeling the real world" is actually supposed to mean. I don't think  
this idea makes any sense. But that's a different topic... ;)

- Functional programming doesn't scale very well. Function  
composition seems to be very straightforward because it allows you to  
take two functions and combine them into one. However, as soon as  
functions are defined recursively by calling themselves, function  
composition doesn't work that well anymore. Consider:

(define (fac x)
   (if (= x 0) 1 (* x (fac (- x 1)))))

There is no straightforward way to compose fac with another function  
in a way such that the recursive call inside fac to itself gets  
redirected to the composite function.

Object-oriented programming provides better facilities here: When a  
method performs a recursive call to itself, any redefinition of that  
method in a subclass also affects the recursive call (and you have to  
do very little to get this effect).

When an OOP language supports delegation between objects, you  
actually get a composition operator that allows you to combine two  
objects in a way such that recursive calls are handled "correctly".  
(There remains the issue that object identity is typically not  
handled well, but this may not matter that much in practice.)

Of course, it is also possible to create similar composition  
operators for functions. See for example my paper on dynamically  
scoped functions at http://p-cos.net/documents/dynfun.pdf or Robert  
Hirschfeld's and my follow-up work on context-oriented programming,  
for example at http://p-cos.net/research.html


Pascal

-- 
Pascal Costanza, mailto:[email protected], http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium