[davedx]

> There are certain problems that lend themselves well to the functional style, mainly those where you are piping a piece of data through various functions and applying different transformations to it.

I don't quite understand this - how does this fit into the 'immutability' of fp? So functions can mutate data that goes into them, but they can't maintain internal state?

[jarek-foksa]

In FP functions shouldn't mutate data structures that were passed by reference on input, instead any input data should be copied before performing mutations on it to avoid changes to external state.

This is how e.g. Array.prototype.filter() works in JavaScript:

  var numbers = [1,2,3,4,5,6,7,8,9,10];

  var evenNumbers = numbers.filter( function(number) {
    return number % 2 === 0;
  });

[chousuke]

I would like to add that this it is perfectly possible to write purely functional programs that do mutation. You just need to be explicit about it.

Many purely functional data structures also have advanced implementations that need much less copying than "immutable" would at first make you think, since two values can share unchanged structure.

[Peaker]

It's not really considered "mutation" at all. They just return new values that are related in some way to the input values.

[Paradigma11]

In f# for example you can write: let result = list1 |> List.filter (fun e -> ...) |> List.map (fun e -> ...) |> .... no mutation, but you are piping the intermediate result to the next operation. In c# you could achieve a similar result by using the dot operator instead of the backpiping |> one.