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-coding&test, test&integration,
> requirements-testing&sell-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.
