Answer. I don't know of any defiend method for software engineering which is built around FP in the same way that USDP/UP was built around UML.

Note. Booch and Jacobson have moved to agile practices which are orthogonal to languages. Booch in particular emphasizes the human interaction aspect (http://vimeo.com/agile3d/review/48753174/fd92ea4563) and Jacobson that software engineering consists of essential "Alphas." (http://www.ivarjacobson.com/Software_Engineering_Method_and_Theory/).

Thought. Personally, I would suggest that functional programming may fit well with methods still being developed around SBVR/DMN/BPMN as a (rede) chained set of decisions and constraints.

http://www.brcommunity.com/b597.php

Chalise/Skip

Thanks so much for your inputs. I am inclined to believe that the old structural systems design and programming is still adequate for functional programming work.

What do you think of that conclusion?

LPC

Hmmn, looking at SBVR makes me think it is amenable to being represented in a domain specific language which functional programming languages can do.

LPC

At late 80's, Abelson and Sussman proposed an interesting methodology to develop programs with Lisp (or Scheme) basead on Metalinguistic Abstractions. In fact, that proposal has appeared later with different clothes in many other contexts. The key idea is very simple: you design language abstractions suited to your problem, implement an interpreter for those abstractions and implement the solution with proposed abstractions. In more recent words, you design a Domain-specific Language (DSL) and implement it to produce a modeling language in which you can model (solve) your problem. In theory, this is a very beautiful solution, however the practice has shown that designing and implementing good DSLs is difficult and is not well-suitable for every problem you have in hand. Nonetheless, depending on the problem, you may consider this "methodology". For the seminal paper of Abelson and Sussman, see http://dspace.mit.edu/bitstream/handle/1721.1/6064/AIM-986.pdf

Thanks so much for the link I am interested in this paper.

Salamatin, JINR Preprint Р13-2013-74, Dubna, 2013

Do you have an English version of this paper?

It's a shame that the FP community hasn't put more resources into this. I keep reminding folks that what made Booch, Fowler, etc. did more to help OO take off than any number of Smalltalk or C++ books. It let people understand how to map the structure of their application onto an object-oriented solutionOf course the pattern books took this one step further in teaching people architect a solution to particular patterns of problems. Hoping someone will write similar books for FP, but we will have to see.

I can remember that before those books came out you would hear things like "if you are using a Relational DB you shouldn't use OO". Nobody would say that now because we know who to structure our solutions.

In response to Lito's comments, I do think that say data flow diagrams are a nice way to represent many functional programs. That said, FP is a good match for agile agile application development, but the down side is that we need industrial grade GUI development support that is currently lacking in most FP systems as most customers need that kind of feedback early when doing agile development.

For applications where a DSL based solution works, modern higher-order functional languages like Haskell or OCAML are really the only way to go.

Dear Alwyn,

The comments in this thread have drawn me back to the old style data flow analysis - DFD and structured design processes and what a great affirmation of that when I saw your comment.

Last week I tried to do an MVP pattern for my Dr. Racket code. MVP does not work as per my experiment. It does not apply because the paradigm in FP is totally of a different kind. It is just awkward trying to do an MVP style in my FP code. Now having said that DFDs and Structured Design are suitable for FP - there is still more food for thought - because what are those patterns that can been seen as we do them form an FP stand point?

So why don't we write a book about this...:-)

LPC

Will closures lead the way to FP design patterns, perhaps monads too? Can we simulate an object using closures? I have a gut feel the answer is yes. I know the question can be asked - but don't you have objects too in your FP? Why not use them? My answer - for purist and patriotic reasons I guess.

Salamatin, JINR to L.P.Cruz. Not, most of our papers are in russian, but today I will try to add a raw text in english of new paper, which can explain our approach.

Thanks for this pointer on SOFL I have requested a copy on his paper.

@Stefan,

Thanks for this, I do agree that at the moment, structured methods like DFD is still the best tool for FL programming. Liu's book is interesting to me considering I have been assigned to teach formal verification this semester.

LPC

Try the schematic functional programming language Clarity: http://www.clarity-support.co.uk.  There is also a book: called Drawing Programs:  

http://www.springer.com/computer/swe/book/978-1-84882-617-5

It is down-loadable free:

http://www.clarity-support.co.uk/products/clarity/claritykit.html

Thanks so much Jan, that is a nice touch on FP.

LPC