[erlang-questions] Design methodology going from Object oriented to functional programming?

[Richard Carlsson]

Alexander Lamb wrote:
> I am trying to understand what is the design process (intellectual, that 
> is) when building a program in Erlang.
> 
> Indeed, in the object oriented world, I would start by finding what my 
> classes might be and the relationship between them. Gradually I would 
> add functions (class or instance methods) to the classes in order to 
> provide solid foundations on top of which I can write an application.

In functional programming, you'd similarly begin with at least an idea of
what your data structures should be, that is, what information do you need
to work on, and what is the most suitable representation of that
information. A big difference from the OO thinking is that you'd immediately
try to identify and in as much as possible factor out all stateful data.
If you're lucky, all state can be mapped naturally to processes, and the
rest of the code is purely functional. Otherwise, you'll have to put some of
the state in a table or database. For many smaller problems, state is best
modelled as threading a State variable through those functions that need it.

I've seen very little written about programming methodology and design in
functional languages; perhaps this is because the field is too small (in $)
to attract the sort of people who write that sort of books. But it could
also have something to do with the following selected quotes:

   "It is better to have 100 functions operate on one data structure than
   10 functions on 10 data structures."
   (Alan Perlis)
   http://www.cs.yale.edu/quotes.html

   "I think part of the reason people in big companies like object-oriented
   programming is because it yields a lot of what looks like work. Something
   that might naturally be represented as, say, a list of integers, can now
   be represented as a class with all kinds of scaffolding and hustle and
   bustle."
   (Paul Graham on language design)
   http://www.paulgraham.com/langdes.html

   "... When I see patterns in my programs, I consider it a sign of trouble.
   The shape of a program should reflect only the problem it needs to solve.
   Any other regularity in the code is a sign, to me at least, that I'm using
   abstractions that aren't powerful enough..."
   (Paul Graham on the relative power of programming languages)
   http://www.paulgraham.com/icad.html

   "16 of 23 patterns are either invisible or simpler, ..."
   (Peter Norvig on Design Patterns in Dylan or Lisp)
   http://www.norvig.com/design-patterns/

<rant>I've read the GOF book on Design Patterns, and think it is a great
work. Every programmer should have read it, and keep an awareness of these
patterns in the back of his head. But to consciously use patterns, to the
point where you name classes after them and write in the documentation that
this-or-that implements the thingummy pattern, is just as misguided as if an
architect, after reading the original work by Christopher Alexander
(http://en.wikipedia.org/wiki/Christopher_Alexander) would keep noting in
his blueprints which sections of a building implement which architectural
patterns (or even name a back garden the "PUBLIC OUTDOOR ROOM").</rant>

     /Richard