From: adams@crcge1.UUCP (Drew Adams)
Subject: Re: Software Reuse -- do we really know what it is ?
Date: Thu, 2-Jul-87 03:55:43 EDT [thread overview]
Date: Thu Jul 2 03:55:43 1987
Message-ID: <2637@crcge1.UUCP> (raw)
In-Reply-To: 8706160502.AA26398@ucbvax.Berkeley.EDU
Let me play provocateur and recommend a little known paper introducing
another point of view regarding software reusability and modularity:
Hughes, John, "Why Functional Programming Matters", Report 16, Programming
Methodology Group, University of Goteborg and Chalmers
University of Technology, Goteborg, Sweden, 1984,
ISSN 0282-2083
Here's the abstract:
As software becomes more and more complex, it is more and more
important to structure it well. Well-structured software is easy
to write, easy to debug, and provides a collection of modules that
can be re-used to reduce future programming costs. Conventional
languages place conceptual limits on the way problems can be
modularised. [Purely f]unctional languages push those limits back.
In this paper we show that two features of functional languages in
particular, higher-order functions and lazy evaluation, can contribute
greatly to modularity. As examples, we manipulate lists and trees,
program several numerical algorithms, and implement the alpha-beta
heuristic (an algorithm from Artificial Intelligence used in
game-playing programs). Since modularity is the key to successful
programming, functional programming is vitally important to the real
world.
Hughes argues that the usual "advantages" of declarative languages over
imperative ones (no assignment, no side effects, no flow of control)
are negative expressions of some of the problems with imperative
languages, but that they leave unexplained 1) why these problems are
problems and, more importantly, 2) what are the real POSITIVE advantages
of declarative programming. To quote from the introduction:
If omitting assignment statements brought such enormous benefits
then FORTRAN programmers would have been doing it for twenty years.
It is a logical impossibility to make a language more powerful by
omitting features, no matter how bad they may be.
Even a functional programmer should be dissatisfied with these
so-called advantages, because they give him no help in exploiting
the power of functional languages. One cannot write a program which
is particularly lacking in assignment statements, or particularly
referentially transparent. There is no yardstick of program quality
here, and therefore no ideal to aim at.
Clearly this characterisation of functional programming is inadequate.
We must find something to put in its place - something which not only
explains the power of functional programming, but also gives a clear
indication of what the functional programmer should strive towards.
Hughes finds that the importance of functional languages is that they allow
program modularisation in ways which imperative languages cannot.
To quote again:
... recent languages such as Modula-II [Wirth 82] and Ada [DOD 80]
include features specifically designed to help improve modularity.
However, there is a very important point that is often missed.
When writing a modular program to solve a problem, one first
divides the program into sub-problems, then solves the sub-problems
and combines the solutions. The ways in which one can divide up the
original problem depend directly on the ways in which one can glue
solutions together. Therefore, to increase one's ability to
modularise a problem conceptually, one must provide new kinds of
glue in the programming language.
... functional languages provide two new, very important kinds of
glue [(higher order functions and lazy interpretation)]....
This is the key to functional programming's power - it allows
greatly improved modularisation. It is also the goal for which
functional programmers must strive - smaller and simpler and more
general modules, glued together with the new glues....
If you only read one article about (purely) declarative languages, let it
be this one. You won't be disappointed.--
Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherche de la Compagnie
Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE
Tel. 64.49.11.54, adams@crcge1.cge.fr
prev parent reply other threads:[~1987-07-02 7:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
1987-06-16 1:55 comments on Ed Berard's S/W reuse part 5 CONTR47
1987-06-18 8:46 ` Software Reuse -- do we really know what it is ? craig
1987-06-22 0:50 ` Lawrence Crowl
1987-06-22 15:40 ` Stanley Shebs
1987-06-22 18:59 ` Lawrence Crowl
1987-06-23 17:28 ` Stanley Shebs
1987-06-29 9:16 ` Software Reuse -- do we really know what it is ? (long) Ian Dickinson
1987-07-04 21:19 ` John B. Nagle
[not found] ` <glacier.17113>
1987-07-07 2:21 ` Software Reuse (short title) pase
[not found] ` <titan.668>
1987-07-06 5:28 ` Software Reuse -- do we really know what it is ? (long) David C. DiNucci
1987-07-07 15:18 ` Automatic implementation of abstract specifications debray
1987-07-09 22:40 ` Automatic implementation of abstrac ron
1987-07-14 16:00 ` Automatic implementation of abstract specifications Edward Hayes
1987-07-02 7:55 ` Drew Adams [this message]
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox