Philip Wadler

in ACM SIGPLAN Notices
(33) 25-33 , February 1998

The functional community splits in two camps. Lazy ,languages evaluate arguments on demand and so require a highly disciplined use of side effects; strict languages evaluate arguments eagerly, but make it easier to exploit side effects.[ ..]

Most functional lanuages now provide some means of interworking with C or other imperative lanuages. [...]

Functional programmers often proclaim that the use of high-order functions promotes reuse. The classical examples are the map and folder functions, which encapsulate common forms of list traversal, and just need to be instantiated with an action to perform for each element. Most, but not quite all, list processing can be easily expressed in terms of these functions.

[ The experience with the strict functional language Erlang] suggests this notion of reuse scales up to support the current client-server architectures. A set of libraries encapsulate the common server requirements, and just need to be instantiated with an action to perform for each request. Most, but not quite all, servers can be easily expressed in terms of these libraries.

The usefulness of a programming language is generally greatly enhanced if it is ``functional'' (as opposed to imperative). A functional language (Hudak 1989) is, broadly speaking, a language ``that emphasises the evaluation of expressions, rather than the execution of commands. The expressions in these languages are formed by using functions to combine the basic [data] values'' (Jones 1994). Functional languages support and encourage programming in a functional style. They are usually very expressive and often allow a direct translation of algorithms in mathematical notation into executable code.

read