[Haskell] Re: Modelling languages for FP (like UML for OO)

[Srinivas Nedunuri]

<ajb at spamcop.net> wrote in message 
news:20060119185325.iw9di8gwcc0kkkgw at webmail.spamcop.net...
> G'day all.
>
> Quoting Benjamin Franksen <benjamin.franksen at bessy.de>:
>
>> However, not everyone in the OO camp thinks that UML is really useful:
>>
>> http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html
>
> Having actually used it (once), the consensus seems to be:
>
> 1. It only applies to a "pure" OO style.  Just about all useful 
> programming
> languages for programming-in-the-large (Haskell included) are 
> multi-paradigm.
>
> 2. It's difficult to refactor.  This makes it useless for design purposes,
> especially if your development development methodology is sufficiently 
> agile.
>
> The upshot is that UML's only use is for docmentation after the fact, or
> for Big Design Up Front projects.  But only if you use a strict subset
> of what most programming languages give you.
I am no rabid UML fan, but I am reasonably familiar with it, and I have to 
say this is garbage. UML class diagrams are invaluable both for the 
conceptual analysis and design work as well as for after the fact overview 
of the class structure. State models are essential for designing the 
behavior of interesting objects. Slightly less important (IMHO) but still 
useful are acitivity charts (for use case flow), and interaction diagrams 
(although I have found them personally less useful for the initial 
conceptualization. I have found them more useful for explaining method 
interactions to someone). The fact that highly popular tools like TogetherJ 
put a lot of effort into recovering the class diagram and the interaction 
diagram from code should be some indication of their importance and 
usefulness. In addition, the latest MDA model compilers can generate entire 
applications from UML models. Some documentation that is!

I have personally noticed less of a need for modeling tools with Haskell b/c 
the language itself is fairly abstract, but also because i tend not to write 
stateful, structurally rich applications in Haskell. If the next version of 
Haskell does support a more convenient and extensible datatype mechanism, 
then i can see people using Haskell for such applications and therefore a 
need for some kind of diagrammatic modeling tool there too.

cheers
-s