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

On Wed, Mar 14, 2007 at 05:13:10AM -0700, 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.

Actually, I seem to recall a very recent discussion about objects vs. 
closures.

> 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?

No. There are various things that could explain the observation, one of 
them being that OO is currently main stream, attracting lots of 
programmers, and thus getting lots of tools developed for it.

It could also be that the perceived lack of literature and solutions to 
programming in the large with functional languages is just that: 
perceived. Lots of literature and tools have been developed for Lisp and 
Pascal, in their heydays, too. They are just not as visible as the Java, 
C#, etc. tools at the moment, because the latter are new.

> Is that why so many functional language implementations usually offer 
> at least one 'flavor' of object system?

I think the ability to model Real World objects and similar as objects 
in programs (with object identity, encapsulation, etc.) is very useful, 
regardless of ideology. That was also the prevailing sentiment in the 
discussion about closures vs. objects I referred to earlier. People try 
to pit functional programming against object-oriented programming, but 
the two are not mutually exclusive, and both have their places. I think 
it is in recognition of this that many "functional languages" (I dislike 
the term - in my opinion, languages aren't functional, algorithms are) 
offer objects as well.

I think it's a pity that people believe there is One True Paradigm to 
programming. This leads to many flamewars, but that's not the worst of 
it. It also leads to languages that support one paradigm, but not 
others. For example, functional programming can lead to very elegant and 
concise programs, consisting of many small functions - but not in Java. 
The fact that Java has no first-class functions, all methods must be 
associated with classes, and syntactic salt is required around both 
class definitions and method definitions makes functional programs a lot 
less elegant in Java than they could be.

A point related to this discussion is what actually constitutes an 
"object". In a sense, functions are objects in Common Lisp. You can test 
if two functions are the same object (with eq). Functions even have 
classes (although I think they all belong to the same class). In fact, I 
would argue that _every_ value in Common Lisp is an object. However, not 
all of them are objects in the sense that they have fields (and, even 
trickier, methods) associated with them.

Regards,

Bob

-- 
Give a man a fish and he will eat for a day. Teach a man to fish and he
will eat for a lifetime.
	-- Confucius

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF+CPMfb9wcmD+WN4RAnHZAJ4+Bqf82PUR6Q10Ah1h/b3w77b+KQCcDfvx
oniILut3IGSonOMbQYBA5qw=
=os39
-----END PGP SIGNATURE-----