[erlang-questions] "Design patterns" for functional languages?
Fri Aug 8 00:53:16 CEST 2008
I think Patrick makes several good points here, as do others in this thread.
Maybe the ideal format for an Erlang book on "design patterns" is
along the lines of the "Ruby Cookbook", "Perl Cookbook", "Python
Cookbook" and probably many other books covering other languages that
have been released by O'Reilly.
In a nutshell, they're just full of sample code. Each example puts
forward a fairly specific problem (e.g. "How do I reverse a string?",
"How do I create a UDP server?", "How can I convert an integer to
Roman numerals?") that is really just a good example of a much larger
set of generic problems. This gets highlighted, then there's a code
sample that outlines a "good" solution to the problem, then there's a
discussion of how the solution works and what makes it "good".
They rarely discuss things in terms of "patterns" or "pattern names",
although I seem to recall "Singleton" making an appearance on
occasion. Instead, the focus is on letting the reader recognise when
they're facing one of these types of generic problems, and giving them
an approach to deal with it.
Maybe that's what the Erlang "design patterns" book should look like.
If there's not a broad set of useful Erlang design patterns, and I'm
not sure whether I agree with this or not, a set of cookbook-style
examples could be the best approach to take for getting this
Hmm, that's about all my brain can handle this early in the morning...
So who's up for writing the "Erlang Cookbook"? ;->
2008/8/8 Patrick Logan <>:
> "The OTP is a collection of GoF-style patterns for Erlang."
> I think this list, as well as the softwate community as a whole, has
> lost sight of the original intent of the "patterns movement".
> The original intent of a "pattern" is the format of the information,
> more than the information per se.
> The format should be written in (one of several) pattern styles. The
> overall presentation of some set of patterns should form a "patterns
> So to say the "OTP is a collection of patterns" is true only in the
> worst definition of "pattern".
> A really useful pattern language for OTP would guide the programmer
> from some initial kind of problem through the application of some
> patterns that address that problem and associated forces that would
> direct the programmer through a set of choices and partial solutions,
> toward an overall solution.
> And stuff.
> erlang-questions mailing list
More information about the erlang-questions