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

[Chris Campbell <cyberdanx@gmail.com>]

On 18/07/05, Robert Morelli <morelli@cs.utah.edu> wrote:
> 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.
> 
> 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.

Problems with documentation plague software as a whole whether they're
written in "OO" languages or "FP" languages.  Tools like Javadoc did
change things slightly.  They made it easier to put some documentation
in at low cost.  It still only works if programmers can be bothered
and don't necessarily do anything for the quality of documentation
(people will always write crap comments in code, now they just get
javadoc'd).

As for advocacy I agree that sometimes it is counter productive but
sometimes people make the mistake of assuming the purpose of the
language is to become popular and widely used in the mainstream. i.e.
it's the next Java/C# or is the silver bullet to end all software
ills.  It's not.  The reality is more complex.

Many "functional" languages are research vehicles.  They're not about
converting the masses, they're about exploring ideas.  Sometimes the
goal is not to create a language for widespread use, it is to create a
language which explores a problem or satisfies curiosity.  Some are
intended to change the world and some of those do fail.

Also note that on the whole, any language other than C, C++, Java, C#
face advocacy problems in someway.  The comment about gains in
productivity is correct, but is so not because it may not be true for
a particular language but because everyone claims it without proof. 
That's the problem with language advocacy, it's subjective not
objective.

It's probably worth noting that languages that succeed in some way do
so in a niche or fill a particular need and spread out into the wider
world, being used for problems they solve well and those they do not. 
Sometimes that helps people develop better languages, sometimes it has
a negative affect.

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

There is no consensus in mainstream industry either.  We have
guidelines in the form of patterns, and good rules of thumb for aiding
maintainance (low coupling, high cohesion, ...) and newer (or old ones
becoming popular) ideas that look like they make good tools to use
when appropriate ("test first", "let it fail").  None are appropriate
for all situations and their is no consensus as to what those
situations are.

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

Which are what?  I don't think there's any consensus on that.

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

First you have to define what a functional language is to talk about
that.  Let's say for the sake of argument it's charaterised mainly by
declarative variables, with emphasis on higher order functions and
structuring code through repeated function application with state
present in some way but not the default.  This isn't everyones
definition, but it's what I tend to think of FP being about.  Note
that takes in a lot of systems, doesn't say anything about
"typed-ness" and can be applied to many languages outside the FP
mainstream.  That's intentional.  I don't think there is one set of
baskets to classify all systems, and it's pointless doing so.  It's
better to realise there is a scale involved and some languages are
high up in some parts and low in others.

There are complex systems where those lend a hand in major ways.  The
absense of a stateful default is a major boost in developing
distributed systems.  It allows you to isolate state to where it is
really necessary and to not worry about consistency all the time. 
State becomes a major pain fast in such systems when it's the default.
 The rules become much more complex.

HOFs enable reuse.

> The use of type checking is a point where the FP community
> has not reached consensus,  as there are widely divergent views from
> the Scheme community and the ML and Haskell communities.  

The static vs dynamic debate is a really annoying pointless way to
increase enthropy, so I won't go there.  I will say however that
statically typed systems like ML prevent me from doing some things I
can do easily in dynamically typed systems unless they're sufficiently
rich (like say specifying functions which operate on a family of
records containing a given set of fields is trivial in dynamically
typed languages but requires something more in statically typed
systems) but come with other benefits.  I use both.

Besides, I'm pretty sure there are "dynamically typed" OO languages. 
So there are differences in the OO camp too.

> Even between
> ML and Haskell,  there are significant differences in the treatment of
> imperative features,  type inference,  objects and type classes,  etc.

This is bad?  Each shows a different choice and the consequences of
making that choice.  Each opens up different avenues of research which
leads to a greater understanding of languages and their concepts as a
whole.  Each has different trade offs.

You can limit your search to one path, but if you do that you may
never realise your on the wrong one or understand the consequences of
the choices you made.

> These differences,  it seems to me,  are more fundamental than anything
> you find in the OO world,  even the difference between,  say,  Java
> and Smalltalk.

Even if this is true, why is it a bad thing?  Sometimes there can be
more than one solution with different trade offs.  Choice isn't a bad
thing.


Chris