What is the difference between procedural programming and functional programming?

Question

I've read the Wikipedia articles for both procedural programming and functional programming, but I'm still slightly confused. Could someone boil it down to the core?

Answer 1

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast with the procedural programming style that emphasizes changes in state.

Answer 2

A functional language (ideally) allows you to write a mathematical function, i.e. a function that takes n arguments and returns a value. If the program is executed, this function is evaluated.

A procedural language, on the other hand, performs a series of sequential steps, where the functional program would be nested. There's a way of transforming sequential logic into functional logic called continuation passing style.

As a consequence, a purely functional program always yields the same value for an input, and the order of evaluation is not well-defined; which means that uncertain values like user input or random values are hard to model in purely functional languages.

Answer 3

To expand on Konrad's comment:

As a consequence, a purely functional program always yields the same value for an input, and the order of evaluation is not well-defined;

Because of this, functional code is generally easier to parallelize. Since there are (generally) no side effects of the functions, and they (generally) just act on their arguments, a lot of concurrency issues go away.

Functional programming is also used when you need to be capable of proving your code is correct. This is much harder to do with procedural programming (not easy with functional, but still easier).

Disclaimer: I haven't used functional programming in years, and only recently started looking at it again, so I might not be completely correct here. :)

Answer 4

I believe that procedural/functional/objective programming are about how to approach a problem.

The first style would plan everything in to steps, and solves the problem by implementing one step (a procedure) at a time. On the other hand, functional programming would emphasize the divide-and-conquer approach, where the problem is divided into sub-problem, then each sub-problem is solved (creating a function to solve that sub problem) and the results are combined to create the answer for the whole problem. Lastly, Objective programming would mimic the real world by create a mini-world inside the computer with many objects, each of which has a (somewhat) unique characteristics, and interacts with others. From those interactions the result would emerge.

Each style of programming has its own advantages and weaknesses. Hence, doing something such as "pure programming" (i.e. purely procedural - no one does this, by the way, which is kind of weird - or purely functional or purely objective) is very difficult, if not impossible, except some elementary problems specially designed to demonstrate the advantage of a programming style (hence, we call those who like pureness "weenie" :D).

Then, from those styles, we have programming languages that is designed to optimized for some each style. For example, Assembly is all about procedural. Okay, most early languages are procedural, not only Asm, like C, Pascal, (and Fortran, I heard). Then, we have all famous Java in objective school (Actually, Java and C# is also in a class called "money-oriented," but that is subject for another discussion). Also objective is Smalltalk. In functional school, we would have "nearly functional" (some considered them to be impure) Lisp family and ML family and many "purely functional" Haskell, Erlang, etc. By the way, there are many general languages such as Perl, Python, Ruby.

Hope I have answered your question (and you are still awake).

Answer 5

To expand on Konrad's comment:

and the order of evaluation is not well-defined

Some functional languages have what is called Lazy Evaluation. Which means a function is not executed until the value is needed. Until that time the function itself is what is passed around.

Procedural languages are step 1 step 2 step 3... if in step 2 you say add 2 + 2, it does it right then. In lazy evaluation you would say add 2 + 2, but if the result is never used, it never does the addition.

Answer 6

"Functional programming is like describing your problem to a mathematician. Imperative programming is like giving instructions to an idiot."

Answer 7

Procedural languages tend to keep track of state (using variables) and tend to execute as a sequence of steps. Purely functional languages don't keep track of state, use immutable values, and tend to execute as a series of dependencies. In many cases the status of the call stack will hold the information that would be equivalent to that which would be stored in state variables in procedural code.

Recursion is a classic example of functional style programming.

Answer 8

Basically the two styles, are like Yin and Yang. One is organized, while the other chaotic. There are situations when Functional programming is the obvious choice, and other situations were Procedural programming is the better choice. This is why there is at least two languages that are coming up with a new version, of their languages to better embrace both programming styles. ( Perl 6 and D 2.0 )

Procedural:

• The output of a routine does not always have a direct correlation with the input.
• Everything is done in a specific order.
• Execution of a routine may have side effects.
• Tends to emphasize implementing solutions in a linear fashion.

Perl 6

sub factorial ( int $n ){

  my $result = 1;

  loop ( ; $n > 0; $n-- ){

    $result *= $n;

  }

  return $result;
}

D 1.0 & D 2.0

int factorial( int n ){

  int result = 1;

  for( ; n>0; n-- ){
    result *= n;
  }

  return result;
}

Functional:

• Often recursive.
• Always returns the same output for a given input.
• Order of evaluation is usually undefined.
• Must be stateless. i.e. No operation can have side effects.
• Good fit for parallel execution
• Tends to emphasize a divide and conquer approach.
• May have the feature of Lazy Evaluation.

Haskell

( copied from Wikipedia );

fac :: Integer -> Integer

fac 0 = 1
fac n | n > 0 = n * fac (n-1)

or in one line:

fac n = if n > 0 then n * fac (n-1) else 1

Perl 6

sub factorial ( int $n ){
   return 1 unless $n > 0;

   return $n * factorial( $n-1 );
}

D 2.0

pure int factorial( invariant int n ){
  if( n >= 0 ){
    return 1;
  }else{
    return n * factorial( n-1 );
  }
}

( in D 1.0 just remove the pure keyword. )

Answer 9

One thing I hadn't seen really emphasized here is that modern functional languages such as Haskell really more on first class functions for flow control than explicit recursion. You don't need to define factorial recursively in Haskell, as was done above. I think something like

fac n = foldr (*) 1 [1..n]

is a perfectly idiomatic construction, and much closer in spirit to using a loop than to using explicit recursion.

Answer 10

@Creighton:

In Haskell there is a library function called product:

prouduct list = foldr 1 (*) list

or simply:

product = foldr 1 (*)

so the "idiomatic" factorial

fac n = foldr 1 (*)  [1..n]

would simply be

fac n = product [1..n]

Answer 11

Procedural programming divides sequences of statements and conditional constructs into separate blocks called procedures that are parameterized over arguments that are (non-functional) values.

Functional programming is the same except that functions are first-class values, so they can be passed as arguments to other functions and returned as results from function calls.

Note that functional programming is a generalization of procedural programming in this interpretation. However, a minority interpret "functional programming" to mean side-effect-free which is quite different but irrelevant for all major functional languages except Haskell.

Cheers, Jon Harrop.

Answer 12

If you have a chance, I would recommand getting a copy of Lisp/Scheme, and doing some projects in it. Most of the ideas that have lately become bandwagons were expressed in Lisp decades ago: functional programming, continuations (as closures), garbage collection, even XML.

So that would be a good way to get a head start on all these current ideas, and a few more besides, like symbolic computation.

You should know what functional programming is good for, and what it isn't good for. It isn't good for everything. Some problems are best expressed in terms of side-effects, where the same question gives differet answers depending on when it is asked.