C++ for Scientists - Technische Universität Dresden

7.4. FUNCTIONAL PROGRAMMING 209
7.4 Functional Programming
In contrast to the procedural and object oriented paradigm, which explicitly formulate algorithms
and programs as a sequence of instructions which act on a program state, the functional
paradigm uses mathematical functions for this task and forgoes the use of a state altogether.
Therefore, there are no mutable variable and no side effects in purely functional programming.
As such it is declarative in nature and relies on the language’s environment to produce an imperative
representation which can be run on a physical machine. Among the greatest strengths of
the functional paradigm is the availability of a strong theoretical framework of lambda calculus
(cite()), which is explained in more detail in Section ref(), for the different implementations.
Higher-order functions are an important concept of functional programming due to its usability
in procedural languages. They were studied in lambda calculus theory well before the notion of
functional programming existed and present the design of a number of functional programming
languages, such as Scheme and Haskell.
As modern procedural languages and their implementations have started to put greater emphasis
on correctness, rather than raw speed, and the implementations of functional languages have
begun to emphasize speed as well as correctness, the performance of functional languages and
procedural languages has begun to converge. For programs which spend most of their time
doing numerical computations, some functional languages (such as OCaml and Clean) can
approach the performance of programs written in C speed, while for programs that handle
large matrices and multidimensional databases, array functional languages (such as J and K)
are usually faster than most non-optimized C programs. Functional languages have long been
criticized as resource-hungry, both in terms of CPU resources and memory. This was mainly
due to two things:
• some early functional languages were implemented with no concern for efficiency
• non-functional languages achieved speed at least in part by neglecting features such as
checking of bounds or garbage collection which are viewed as essential parts of modern
computing frameworks representing an overhead which was built-in to functional languages
by default
Since a purely functional description is free of side effects, it is a favourable choice for parallelization,
as the description does not contain a state, which would require synchronization.
Data related dependencies, however, must still be considered in order to ensure correct operation.
Since the declarative style connected to the functional paradigm distances itself from
the traditional imperative paradigm and its connection to states, input and output opearions
pose a hurdle which is often addressed in a manner, which is not purely functional. As such
functional interdependencies may be specified trivially, while the details how these are to be
met remain opaque and as a choice to the specificc implementaiton.
Last, we give an example of pure functional programming. We point out, that the next code
snippet is presented in Haskel, not in C ++ syntax. The ”hello world” program in the functional
programming paradigm: the factorial calculation
fac :: Integer → Integer
fac 0 = 1
fac n | n>0 = n ∗ fac (n−1)