Patterns for functional, dynamic and aspect-oriented programming

Question

We have a very nice GoF book (Design Patterns: Elements of Reusable Object-Oriented Software) about patterns in Object Oriented Programming, and plenty of articles and resources in the web on this subject.

Are there any books (articles, resources) on patterns(best practices) for functional programming?

For dynamic programming in languages like Python and Ruby?

For AOP?

Answer 1

A related question was asked before: "Does functional programming replace GoF design patterns", with great responses.

The equivalent of "design patterns" is very vague in FP. In general, every time you see a "pattern" in your code you should create something to cover all of its uses in a uniform way. Often it will be a higher-order function.

For example, the following C code

for (int i = 0; i < n; i++)
  if (a[i] == 42)
    return true;
return false;

can be thought of some basic "design pattern" - checking if there's some special element on the list. This snippet could appear many times in code with different conditions. In FP, you simply use a higher order function several times. It's not a "pattern" anymore.

Functional programming has its own practices, but they are much different from "design patterns" in OOP. They include use of polymorphism, lists, higher-order functions, immutability/purity, laziness [not all are essential or specific to FP]... See also "what are core concepts of FP". Also, type classes (Haskell), modules and functors (OCaml), continuations, monads, zippers, finger trees, monoids, arrows, applicative functors, monad transformers, many purely functional data structures (book) etc. Functional pearls, already mentioned by Randall Schulz, form a very rich resource of FP at its best.

To learn how to write idiomatic code, any book/resource on a functional programming language will suffice IMHO (for example, RWH and LYAH); differences between thinking imperatively and functionally are always explained there.

In dynamic languages, Jeff Foster's link is a good collection; here is a very clever use of memoization in JavaScript that could be considered a "design pattern".

Answer 2

The list of design patterns described in GoF is written for languages like C++ and Java. It is sometimes considered a list of workarounds to make inflexible languages more dynamic. For example the Visitor pattern is not really needed in Ruby because you can simply change add member functions to your class at runtime. The Decorator pattern is obsolete if you can use mixins.

It's my experience that when I'm implementing a solution in C++ I tend to spend most of my time writing scaffolding code. I begin with creating a platform that allows me to think in my application's program domain. Design patterns probably were developed as a way to categorize different kinds of scaffolding.

I should mention that when I am programming in Ruby I don't have much supporting code. There just doesn't seem to be a need for it.

My theory is that other languages don't emphasize the concept of design patterns simply because their basic language constructs are sufficient. In defense of Java and C++: maybe this is because functional and AOP languages are often used in more specific problem domains or niches, while Java and C++ are used for everything.

And now for something different. If you are getting a bit bored with OO design and you want to learn something new then you might be interested in the the book Elements of Programming written by Stepanov. In this book he explains how programming can be approached from a mathematical point of view. For a preview, check out his Class notes for Adobe (found among others on this page). You may also be interested in Adobe's Collected Papers.