[Haskell-cafe] Re: capture of idioms and patterns

[John Zabroski]

On Wed, Sep 22, 2010 at 5:20 AM, Johannes Waldmann <
waldmann at imn.htwk-leipzig.de> wrote:

>
> > - are there any prior art in documenting idioms and patterns in FP [...]
>
> you got this backwards: what some folks call "idioms and (design) patterns"
> actually *is* FP, because it is just this: higher order functions.
> And it's been there some decades (lambda calculus).
> That also explains the absence of any Design Patterns/Gang-of-Four
> kind of book for Haskell - it's just not needed.
> (as you say, map and fold are your patterns.)
>
> Best - J.W.
>

Most developers misunderstand the Gang of Four design patterns, including
the authors.  For example, the GoF State Pattern is described synchronously,
but anyone who has thought about this is in deep detail, e.g. actor theory,
knows that asynchronous transitions are possible and that the target state
can be decoupled from the source state.  In mathematics, the most basic way
to understand this is through finite state automata, since an automaton is
only dependent on its current state and input to determine the next
transition.  GoF confuses the issue by insistenting on synchronous
communication between classes that represent states.  GoF has subpar
explanations, but please separate the intellectual wheat from the chaff.

I have also heard some argue that GoF patterns all have the same structure.
This is not true.  I've heard confused programmers say that the Proxy
pattern and the Decorator pattern "look the same".  Decorators provide
structural support of nesting and Proxies do not, but the key difference
between the two is that a Decorator is about adding or removing properties
*dynamically*, whereas a Proxy is about accessing existing properties
through a known static structure.  How does higher order (recursive)
functions make such patterns obsolete?

Some existing design patterns are applicable regardless of paradigm, and
will continuosly get re-invented until people learn better and start to
realize how general the patterns are.

Example: Deterministic systems are easier to debug than non-deterministic
systems, due to the fact non-deterministic systems cannot generalize the
Kahn Principle (this is known as the Brock-Ackerman Anomaly).  Ergo, one of
the best things you can do as a programmer is isolate nondeterminism.
Patterns for doing so have been known for decades in the embedded systems
community, and go by names such as Processor-Actuator, Watchdog, etc.  I've
suggested to some interested in FRP research that they'd be wise to look at
those patterns, not as competitors but as complementary material to enhance
every student's ability to inhale the FRP approach.  Otherwise you end up
with an engineering discussion that is more focused on the cute details on
FRP and not how to design good systems!

Currently the functional programming research community seems very aware of
GoF design patterns but completely unaware and/or uninterested by real-time
design patterns.  I predict this will change within the next 5 years.

Luc Taesch,

Probably my favorite book on the subject is Thomas Kuehne's Ph.D. thesis
which went out of print within the last year, but is freely available from
the author's page:
http://c2.com/cgi/wiki?FunctionalPatternSystemForObjectOrientedDesign

One of the patterns Kuehne discusses, Transfold, is something every computer
scientist should understand.

Unfortunately, the book uses the Eiffel language and not a functional
language.  However, the author brings up good points that transcend what
language is being used for implementation. Also, since it is a book, it is
more coherent than reading many papers on object-functional patterns.

If you don't use Haskell in your day job (like me), then you might use a
more conventional language like C#.  If that is the case, then papers by
Jeremy Gibbons will likely also be right up your alley (they will likely
help you better communicate ideas to your coworkers).  He has written a
number of very readable papers about datatype generic programming.
http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/

+1 to the idea of a book on patterns in a functional language.

Cheers,
Z-Bo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100923/2492481f/attachment.html