Re: [Caml-list] (Mostly) Functional Design?

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Montag, den 18.07.2005, 01:59 -0600 schrieb Robert Morelli:
> I've been lurking on this list for several years.  This seems as good a
> time as any to delurk and jump on a soap box.
> 
> I think you've put your finger on one of the main reasons functional
> languages have failed to attract significant use beyond a few niche
> areas.

Well, I don't believe that. There aren't any technical reasons why
people don't think FP languages are attractive. There are social
reasons. Adult programmers and decision-makers must sit down again on
the school bank. It has to do with the difficulty to get into existing
and working relationships. IMHO, a marketing expert can say much more
about this than a techie.

> I contend:
>    1.  The FP community tends to emphasize low level issues rather than 
> the larger scale issues that concern most programmers.  It is also
> inept at practical documentation and advocacy.

This is entirely nonsense. Although current FP languages have certain
typical "low level" mechanisms like functional composition, they also
have lots of other higher level mechanisms (e.g. a module calculus). 
A current FP language may also be an imperative language or an OO
language at the same time. At least O'Caml is a true multi-paradigm
language.

Another remark: Designers of FP languages often try to avoid the inner
contradictions of the widespread practical languages, and to only
include "sound" language concepts. Sound concepts work for small-scale
and for large-scale programs. For example, if you compose two functions
f and g to a new function, it does not matter how large f and g are. If
f and g are stateless, you don't run into the typical problems of
large-scale imperative programming, i.e. managing the state in a
reasonable way. Well, of course, the term "sound" should be seen
relative to the intentions of the language designer.

>    2.  There isn't much of a theory of large scale functional design.
> At least,  there is no consensus.

Your thesis also includes that other languages have some theory of
large-scale programming. I doubt that. Design patterns, for example, are
medium-scale at best. They help organising the relationships of only a
few classes. Even worse, if you translate design patterns to FP
languages, you often get small-scale counterparts. And is there anything
beyond design patterns?

I also miss that "large-scale" is a multi-dimensional term. It is very
different to design reusable data structures or to design a single large
program. Current FP languages are quite good at supporting reusability. 

>    3.  Point 2. is not the consequence of point 1.;  it's not simply a
> matter of communication,  but an instrinsic void in the FP paradigm.
> The FP paradigm is intrinsically poorly adapted to the kind of large
> scale design concepts that concern most programmers.  Object oriented
> programming is a much better match,  not because of a conspiracy of
> commercial giants in the software tool business,  but because of
> intrinsic technical reasons.  

My view is very different. OO languages like Java or Eiffel are extreme
languages in the sense that they only allow OO to structure the program
and nothing else. (And in the past many OO programmers were really
extremists because they thought the OO paradigm reflected how the world
was structured.) At least O'Caml isn't designed with extremism in mind,
and you _can_ program in it as it were an OO language. This easily
proves that there aren't such technical reasons: O'Caml is a superset of
OO languages.

> Functional programming is a niche
> technology ideally suited to simple domains like language tools and
> formal methods.  It does not have much to say about complicated
> systems.

This only has to do with marketing. It is much simpler to be successful
in a niche where other technologies have clear disadvantages than to be
successful in a universal sense.

I hope the programmers of the world will learn, and will see that much
of the complexity OO pretends to solve has been created by the extreme
view of OO before. For example, compare how GUIs are customised in an
extreme OO language and a multi-paradigm language like O'Caml. In the
extreme language you often must use quite heavy constructs like
subclassing to get a new behaviour where you can simply pass a closure
in O'Caml.

One clear disadvantage in the large scale _application_ of FP languages
is that the programmers must learn much more primitive concepts, and it
takes longer until they can combine them in a reasonable way to large
programs.

Gerd

> Kyle Consalus wrote:
> > There are a wealth of resources related to object oriented design techniques
> > (which can certainly be applied to OCaml), but I've been pretty much unable
> > to find any good resources on large scale design of functional programs.
> > I realize that this is the sort of thing that develops over time with
> > experience.
> > Just the same, there is (most likely) a lot to learn and consider, and a 
> > resource would be helpful. My recent uses of OCaml for fairly small projects
> > have been effective, but a lot of things were cumbersome in the design
> > and I suspect that I may be thinking about it wrong.
> > So, could anyone suggest a good resource or perhaps weigh
> > in on their thoughts on the topic?
> > 
> > Thanks,
> > 
> > Kyle
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------