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

[Doug Kirk <dbkirk@gmail.com>]

First, since this thread was started by somebody asking for ideas on  
learning FP, I can site a couple of printed resources that have  
helped me, but none are written using Ocaml:


"Haskell School of Expression", Hudak, ISBN 0-52164-4089
"Algorithms: A Functional Programming Approach", Rabhi, Lapalme, ISBN  
0-20159-6040
"Structure & Interpretation of Computer Programs", Sussman, Abelson,  
Sussman, ISBN 0-26269-2201

With regard to the mailing lists, I've found that the Haskell list  
has a higher percentage of general FP information than the Ocaml  
list. It's almost as if the Haskellers are the theoretic bunch, and  
the Ocamlers are the applied-technology bunch. (see disclaimer at  
bottom)


On Jul 18, 2005, at 10:26 AM, Alex Baretta wrote:

> This does not justify a
> large scale attempt to catalog all FP "design patterns" in a single
> book.

Large scale? Was not "Design Patterns" originally a Ph.D. thesis? I  
wouldn't call that "large scale". It just so happens that the work  
was very helpful in a practical application for the programming  
community at large to describe things that were already being done  
(see below). So much so that it remains a bestseller in the  
programming world.

<rant>
Unfortunately, what I see today is that too much emphasis is placed  
on the GoF patterns; many coming out of college and into the "real  
world" now see those as the entire toolbox, instead of simply a  
collection of tools that may or may not apply.
</rant>

> These ideas are more general coding strategies requiring a specific
> design from the programmer, rather than parametrized design patterns
> abstracting from the (absence of) cognitive abilities of the  
> programmer.

Yet before "Design Patterns" was released, I used those patterns in  
my day-to-day design activities. It's just that nobody had catalogued  
(formalized) them. I even used them while coding in C, as any good  
programmer wanting to maximize maintainability of code would soon  
learn to do.

So for me at least, the DP book was a formal description of what I  
had already been doing, which I would call "general coding  
strategies". However, having the book formalize the commonly-used  
paradigms raised the level of thinking in the entire (OO) programming  
community, even for programmers that hadn't had the opportunity to  
informally discover the techniques themselves.

In the OO world, it is common now to speak of a design as an  
application of one or more of the patterns; if somebody listening  
doesn't understand a mentioned pattern, he can simply be directed to  
"look it up" so that progress on the design may continue. The point  
here being that speaking in patterns is a communication short-cut  
describing widely understood and accepted concepts. For instance,  
when you say "Indefinite recursion through tail call optimization",  
what does that mean? What is required to accomplish it? What resource  
is available that describes this and the others that you listed and  
the requirements for achieving each of them? If your answer is  
graduate school, then FP is doomed to the sidelines of the mainstream.

Having a resource such as that *is* a valuable tool that enables  
novices to raise their level of thinking, and even more so,  
understanding, of the environment in which they are operating. (The  
danger of having the resource without experience is pointed out in  
the rant above...it may be easy for novices to see it as the entire  
toolbox.)

For myself, I've been lurking on this list for awhile, and trying to  
learn FP practices using Ocaml. Since I have 3 mouths to feed, I must  
spend most of my time doing work that clients are willing to pay  
for...the last 9 years that means Java. So the lack of resources to  
learn FP/Ocaml seriously affects my ability to start using it for  
anything "real".

I am not so much interested in Ocaml as I am FP (I chose to look more  
closely at Ocaml over Haskell because of the results of the ICFP  
challenges, and because of some comments on the Haskell list).  
Generally, I am dissatisfied with OO (as I was with structured  
programming before it) as a methodology for solving mid- to large- 
scale problems (essentially they are the same methodology; OO just  
localizes the structures). I am looking to find a way to advance the  
state of the art of problem-solving software systems ("languages").


<disclaimer>
All of the preceding is simply my opinion based upon my own  
observations and experience. It is not intended to incite controversy.
</disclaimer>


Cheers,
--doug