Before you get too excited about functional pipes, let's make sure that we understand the pros and cons of using functional pipes.

From a readability perspective, functional pipes can possibly make the code easier to read and easier to follow. This is because the logic has to be linear. On the contrary, some people may find it less intuitive and harder to read because the direction of computation is reversed as compared to nested function calls.

Functional pipes require single-argument functions, for which they can be easily composed with other functions. When it comes to functions that require multiple arguments, the general solution is to create curried functions – higher-order functions that fix an argument. Previously, we defined a take function that takes the first few elements from a collection:

take(n::Int) = xs -> xs[1:min(n,end)]

The take function is a curried function made out of the getindex function (with a convenient syntax of using square brackets). The getindex function takes two arguments: a collection and a range. Because the number of arguments has been reduced to 1, it can now participate in the functional pipe.

On the flip side, we cannot utilize multiple dispatch for single-argument functions. This could be a huge disadvantage when you are handling logic that requires consideration of multiple arguments.

Nevertheless, functional pipes can be a useful pattern under certain circumstances. Any data-processing task that fits into a linear process style could be a good fit.