up vote 5 down vote favorite

I've recently forayed into the world of functional programming (FP) and am wondering how to "think functionally" for even moderately sized applications? Especially w.r.t. the analysis and design of FPs.

With OOP we're trained to think in terms of objects, their attributes and relations. We model our analyses/designs using class and sequence diagrams. However, the same models seem to be a bad fit when designing for FPs. What are the equivalent modeling paradigms for functional programming? It seems DFDs maybe a good fit but I maybe wrong.

For example: I was thinking of designing a simulation of Monopoly, the board game using Haskell, just to learn the language. When doing OOAD you come up with classes like board contains items that have attributes/methods attached to it. You have player and various other objects and their associated relations that can be captured in a class diagram. And their interactions in a sequence diagram. However, these modeling paradigms doesn't seem to transfer well for functional programs. So just "how" do you model functionally?

Note: I'm looking for concrete references/examples that can explain how to analyze and design functional programs given that I'm coming from a heavily object-oriented way of thinking/modeling.

share|improve this question
1  
I don't really think a simple Monopoly simulation is likely to be the best project for getting the flavor of functional programming. Monopoly has a rather imperative feel, and I think you'll likely be tripping over yourself trying to code it functionally. Why don't you try something like a parser, or a regular expression matcher, or even a compiler for a toy language? – dfeuer Mar 25 '14 at 6:30
up vote 18 down vote accepted

According to Simon Peyton Jones:

The language in which you write profoundly affects the design of programs written in that language. For example, in the OO world, many people use UML to sketch a design. In Haskell or ML, one writes type signatures instead. Much of the initial design phase of a functional program consists of writing type definitions. Unlike UML, though, all this design is incorporated in the final product, and is machine-checked throughout.

Source: Masterminds of Programming

So instead of drawing all the fancy UML diagrams, you actually write type definitions coupled with undefined in the design phase.

share|improve this answer
up vote 3 down vote

All of my programming these days consists of single-person projects. If I were collaborating on a project with other programmers, I think that writing type definitions and using undefined would be a good approach.

But I gather what you're really looking for is some advice about how you can learn to think functionally. So here are some thoughts.

When programming in Haskell, there are two ways I think about the program I'm writing.

  • If the program is mathematical, I think of the program as a set of equations.

  • Otherwise, I tend to think of the program as one or more chains of of data transformations. (So perhaps DFDs would be useful.)

So in your Monopoly example, my first thought would be to figure out how I'm going to represent the state of the board (e.g., which properties have houses, who owns them). Then I might have a function that transforms the board when someone buys a property, and other functions for other things players might do. (There's also monads for representing state, State and StateT. I might use them, if and when I feel they will make the code clearer, but I usually keep things basic to start.)

One of the mistakes I made most often as a beginner was to create a lot of unnecessary classes and data types.

share|improve this answer
    
Also see this blog post. This is a good example of how to think functionally. neilmitchell.blogspot.ie/2013/09/… – mhwombat Mar 24 '14 at 13:09
    
Unnecessary classes are likely bad, but unnecessary datatypes are likely either a matter of taste or a necessary part of the learning process. I wouldn't be scared to throw down some datatypes to start off, even if they don't turn out to be necessary in the end. Just don't implement a bunch of functions for manipulating them until you know that your plan for using them actually makes sense. – dfeuer Mar 25 '14 at 6:21
up vote 3 down vote

Short answer: composition of smaller programs.

You first study the problem before you, then you develop a set of small operations (often in the form of combinators) that you reckon make sense in that problem's context, and finally you build the solution around those operations. I'm under the impression that all packages found on Hackage follow this approach.

In this way the final solution is (more often than not) simple, clear and elegant. As you can appreciate the aforementioned set of small operations you choose for your solution is critical; with practice, you'll develop the sensibility to pick it wisely.

My book suggestion is Pearls of Functional Algorithm Design, by Richard Bird, Google Books (preview). In this book you'll learn about the calculational approach to functional programming, which I think is most valuable.

share|improve this answer
up vote 2 down vote

Two books you might be interested in:

  1. Structure and Interpretation of Computer Programs - a classic intro to CS textbook in Scheme. I think it's a must for programmers interested in FP.

  2. How to Design Programs - similar to SICP, slightly more modern and focuses on design. The language of choice here is Racket.

If you want a hands-on project in Haskell, I'd recommend Write Yourself a Scheme in 48 Hours, a wonderful tutorial for implementing an interpreter for Scheme. AST manipulation is where FP (and especially Haskell) shines, so I think writing an interpreter is a good experience for new FP programmers.

share|improve this answer
    
Scheme and Racket are dynamically typed. That's a huge difference from Haskell, which is statically typed. Only static typing allows to "express your design by types and have it machine-checked". – d8d0d65b3f7cf42 Mar 24 '14 at 13:41
    
As I recall, How to Design Programs is written at a more introductory level than Structure and Interpretation of Computer Programs, but might be good to skim first. – dfeuer Mar 25 '14 at 6:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.