Approach to designing large functional programs

I've been reading lots on functional languages and would like to maybe play with re-writing some parts of my appl开发者_开发知识库ication in F#. Is it better to design from the outside in or the inside out?

---

One of the influental works on the subject of FP Why Functional Programming Matters by John Hughes can be considered as a direct answer:

Our ability to decompose a problem into parts depends directly on our ability to glue solutions together. To support modular programming, a language must provide good glue. Functional programming languages provide two new kinds of glue — higher-order functions and lazy evaluation. Using these glues one can modularize programs in new and useful ways, and we’ve shown several examples of this. Smaller and more general modules can be reused more widely, easing subsequent programming. This explains why functional programs are so much smaller and easier to write than conventional ones. It also provides a target for functional programmers to aim at. If any part of a program is messy or complicated, the programmer should attempt to modularize it and to generalize the parts. He or she should expect to use higher-order functions and lazy evaluation as the tools for doing this.

I would also recommend looking at contemporary interview with John Hughes in InfoQ.

---

One article that really helped me come to terms with functional programming is this one:
http://prog21.dadgum.com/23.html
It is a tutorial for how to create a Pac-Man clone using functional-programming techniques. I don't even recognize the language he used (it might have been Erlang,) but the explanation helped me understand the correct mindset which I used when rewriting one of my programs in Scheme.

---

I'm not an expert at all on this subject, but here is a link to an article on this subject, by 'our' very own Brian:

How does functional programming affect the structure of your code?

And some questions from SO & Programmers (where - incidentally - I suspect this question would be a better fit)

• Real world pitfalls of introducing F# into a large codebase and engineering team
• How to organize F# source of large project (>300 classes) in Visual Studio?

---

Not sure I understand what is meant by "inside out" / "outside in", but FP is most useful "in the small" -- at the function level. OO is probably still the best way to organize projects in the large. It's easiest to deal with objects that correlate with your business domain.

---

I guess by outside in you mean top to bottom approach and by inside out you mean from bottom to top. If this is what you mean than FP is more suited towards bottom up approach i.e inside out.

While designing FP programs think about solving the problem using:

• Data Structure : What all data your application needs to handle and which data structure is most suitable to represent that data.
• Function : A function does one thing (and do it correctly).
• Composition : Create new functions which achieve their goals by composing other functions using technique like higher order functions and compositions.
• Other more advance and abstract FP techniques like Monads etc.

So basically you start from bottom, for each atomic problem you write a function and then as you move upward in the design you use these atomic function to create functions at higher level using composition.

Remember always think of solving problem using abstractions and composition of those abstraction rather than thinking sequentially as you would do in a imperative programming.