Re: Design Methodologies
On 02-Feb-1998, Richard Emberson [EMAIL PROTECTED] wrote: I am investigating whether an organization can build large applications ( 50Kloc - thats c++ lines of code) using a functional language, specifically Haskell. Since 1993 I've been working on what is now a 150Kloc project written in Mercury (a pure logic/functional language), namely the Mercury compiler. The project is written in the logic subset rather than the functional subset, but it would be easy to translate the design to a pure functional language such as Haskell. I was told by another that a "very famous software engineering researcher" had said that the reason there was no emphasis on the use of functional languages in large software systems was: "... functional approaches do not permit you to create an abstract notion of system state that can be modeled. Functional languages are great for people to think about problems (especially recursion), but they are no good for large software systems. It's not that people haven't looked at them in this context; they don't work." Oh, codswallop. What I am looking for are the formal design methods and tools supporting those methods that lead one through the task of decomposing a problem (possibly specified in a requirements document) into a design that can be used as the starting point for coding with a functional language. The documentation should not only cover the engineering task of (using generic terms) top-level-design, intermediate-design, detailed-design, unit-codingtest, testintegration, requirements-testingsell-off, etc, but also how one manages such a project. Yves Deville has written a good book on systematic programming development in logic programming languages (not quite what you were after, I know). But the point I want to make is that the design process for functional or logic programming languages need not be different to that for imperative languages. Modern logic and functional languages provide convenient ways of implementing imperative style algorithms or imperative designs. Imperative languages let you write stateless code too. With regard to the design process, the differences between functional and imperative languages are just differences in degrees; while they will affect the trade-offs between different design choices (e.g. with a functional language you will tend to prefer more functional-style designs, whereas with an imperative language you would tend to use more imperative-style designs), the overall process need not be significantly different. The final detailed design and coding steps and perhaps glass-box testing are of course highly language-dependent, but the differences between say C and COBOL are probably of similar significance to the differences between say Java and Haskell. Testing, project management, source code control, documentation, etc. are all pretty much language-independent. For example, for imperative langages one has the Waterfall design cycle with volumes of texts showing one how to design and manage such a project. There are also many design tools supporting such an approach. And you can use these same approaches and design tools for functional or logic languages. If you look at the ten pages of top-level design documentation for the Mercury compiler, which are available at http://www.cs.mu.oz.au/mercury/developer/compiler_design.html, you will find almost nothing that is specific to the implementation language. The compiler could just as easily have been implemented in C using the exact same high-level design. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
Re: Design Methodologies
What I am looking for are the formal design methods and tools supporting those methods that lead one through the task of decomposing a problem (possibly specified in a requirements document) into a design that can be used as the starting point for coding with a functional language. The documentation should not only cover the engineering task of (using generic terms) top-level-design, intermediate-design, detailed-design, unit-codingtest, testintegration, requirements-testingsell-off, etc, but also how one manages such a project. Good question. Both Erlang and Natural Expert have been widely used in industry, and both have training courses that cover at least some of what you want. For a quick intro to these, see www.cs.bell-labs.com/~wadler/topics/recent.html#angry and follow the pointers from there. (This paper also contains just what you don't want, a list of serious applications of FP. :-) Your quote represents what I suspect is a widely held view. "... functional approaches do not permit you to create an abstract notion of system state that can be modeled. Functional languages are great for people to think about problems (especially recursion), but they are no good for large software systems. It's not that people haven't looked at them in this context; they don't work." This claim is belied by the success of Erlang and Natural Expert. Also, there are scores of functional programs containing over 50K lines. While not large in software engineering terms, these go well beyond merely being used to `think about problems (especially recursion)'. If the quote is not confidential, I'd appreciate if you could give a source for it. Yours, -- P --- Philip Wadler [EMAIL PROTECTED] Bell Laboratories http://www.cs.bell-labs.com/~wadler Lucent Technologies office: +1 908 582 4004 600 Mountain Ave, room 2T-402 fax: +1 908 582 5857 Murray Hill, NJ 07974-0636 USA home: +1 908 626 9252 ---
Design Methodologies
I am investigating whether an organization can build large applications ( 50Kloc - thats c++ lines of code) using a functional language, specifically Haskell. I was told by another that a "very famous software engineering researcher" had said that the reason there was no emphasis on the use of functional languages in large software systems was: "... functional approaches do not permit you to create an abstract notion of system state that can be modeled. Functional languages are great for people to think about problems (especially recursion), but they are no good for large software systems. It's not that people haven't looked at them in this context; they don't work." Now what I am NOT looking for is a list of applications that have been built with functional languages. What I am looking for are the formal design methods and tools supporting those methods that lead one through the task of decomposing a problem (possibly specified in a requirements document) into a design that can be used as the starting point for coding with a functional language. The documentation should not only cover the engineering task of (using generic terms) top-level-design, intermediate-design, detailed-design, unit-codingtest, testintegration, requirements-testingsell-off, etc, but also how one manages such a project. For example, for imperative langages one has the Waterfall design cycle with volumes of texts showing one how to design and manage such a project. There are also many design tools supporting such an approach. For an object-orient approach there is again many papers and books describing how to go about such a design and how to manage such a project. There is the new UML (unified modeling Language) specifically created to provide a common OO design technique for such projects (and, no doubt, to create a single larger tools market, rather than a number of smaller, disjoint markets). What exists for functional languages? Thanks. Richard Emberson
