Is there a software-engineering methodology for functional programming?

This seems like a poorly-expressed question. The premise is that one set or another of tools are used only for OOP.<p>UML is a modeling language for talking about abstract constructs. That means it's as good for working with FP as OOP. What you model in UML and how much you do and how you do it? That's an entirely different thing.<p>You have to have data. In FP, more than anywhere else, data is king. So I use UML to initially model data structures, just like I would no matter what paradigm I was working with. Let Codd be your copilot.<p>It's never right. There are those who model code ad infinitum and try to code the world completely top-down. This never works. There are those who don't model anything and try to code completely bottom-up. This works, but can become unmaintainable if not implemented correctly. The trick is to do a little top-down, a little bottom-up, a little top-down, etc. Usually within a couple cycles of this your basic program/data structure is nailed and you can move to being bottom-up and refactoring. I've probably described it more complicated than it actually is. But it works the same in OOP as FP (although I've noticed a quicker tendency to move towards bottom-up in FP and a tendency to stay top-down in OOP)<p>If the questioner is talking about software development methodologies, like Agile or RUP or CMM or waterfall, then it's also the same. After years of beating ourselves up in various ways, we've pretty much all agreed that short timeboxes, with concrete deliverables, public demonstrations, and constant adaptation to changing conditions beats everything else. However else you want to do it is up to you, but it should conform to those basics. FP or OOP really has nothing to do with it.<p>I think maybe the questioner is making the assumption that all this _stuff_, UML sequence diagrams and use cases and tiered architectures and whatnot -- that it's really how you program in OOP. But it's not. It never was. All that crap is just various tools that are useful in various situations to communicate about complex problems. They're not actually how you _do_ anything.

Sadly, programming is not a step-by-step process, and so the search for methodologies is pretty fruitless IMHO.<p>Instead of looking for "proven" programming methodologies, one should develop an aptitude and taste for how to write good programs. This can only come from "doing" it and seeing how other people do it.<p>"Bottom up programming" is not a methodology. It's not a step-by-step process, nor is it a set of strict rules and guidelines. It's just a general idea; and it's not something you implement, it's a mindset you absorb and imitate.<p>By the way, UML &#38; co. are horrible abominations and you should steer away from them. If you want to sketch something out on a piece of paper, just use your common sense: draw boxes, circles, arrows, trees, or whatever you like.

A methodology for software engineering or a methodology for programming? Not necessarily the same, as I see it.<p>You may have one methodology you use for your overall engineering. A framework for supporting your problem analysis, architecting your system, and doing system design. You may have another methodology for detailed design and implementation of the parts of the system that goes into programs. It may of course be advantageous if the latter support the paradigm of your programming language. The former less so.<p>A software based system has three main dimensions, state, event streams, and functionality. Your methodology should support all three dimensions evenly. If it does not, you should be aware of that and do your own compensation.

This is one of my least favorite types of questions. It's like asking, "is there a painting methodology for latex-based paints?" Well, no. You use latex-based paints just like you use oil-based paints. Apply it to the paper until your sense of taste tells you you have art.<p>Programming is the same way. Write a small amount of code until you have something beautiful. This methodology will get you far with any language.<p>The hard part is refining the sense of taste. Just like there are a lot of poor starving artists who never get it, there are going to be a lot of poor starving programmers who never get it. That's sad, but that's the reality of creativity. Not everyone has it.<p>But you can try, and the way you try is by reading other programs and writing your programs in a similar style. There are low-level things and high-level things to look out for, and you're not going to get them by reading Stack Overflow. You have to play with a language and its libraries on a daily basis for years. Then you will begin to find the "methodology" you are looking for.<p>There are no easy answers.

UML and its manipulations are only a relatively small thing -- the Unified Process covers much more than that.<p>So, as a question on <i>process</i>, OO or functional does not matter much: the software is treated really as modules or parts. Whether those are composed of lists or objects, methods or functions, is a minor concern. Process deliberately works at a higher level. There is some specialisation to OO, but translating it to FP would seem essentially straightforward.<p>But as a question on that particular sub-area, it is valid and interesting, and there does not seem to be such a functional specialisation.<p>Perhaps there is a way to answer by looking back to the history of the Unified Process. A substantial basis of it was developed by Jacobson while working at Ericsson on phone switches etc. And that was the same place and same kind of work where Erlang was later created. So maybe investigating how to use Erlang might lead to some approaches.

Lots of talk of UML. Surely if there is a software engineering concept that suits functional programming, it's formal methods.<p><a href="http://en.wikipedia.org/wiki/Formal_methods" rel="nofollow">http://en.wikipedia.org/wiki/Formal_methods</a>

<a href="http://clojure.blip.tv/file/4457042/" rel="nofollow">http://clojure.blip.tv/file/4457042/</a> This video with Rich Hickey(Creator of clojure) is the closest to a functional programming methodology you will find.<p>Software engineering and programming are simply problem solving with an abstract tool set.