comp.lang.ada
 help / color / mirror / Atom feed
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

      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