How does functional programming influence your coding style?

Question

The most of programmers nowadays use OOPS concepts for software development.

But some of them have exposure to functional programming too.

How does functional programming influence your coding style?

Answer 1

I find it a lot easier to write multi threaded code now.

I tend to have less class level variables than before.

I also tend to have interfaces that are functionally independent ... again that has a huge gain when it comes to multi threading as it can greatly reduce the amount of object locking required provided your threads are also functionally independant.

I also tend to have nightmares about closing braces chasing me.

Answer 2

Two things come to my mind originating from functional programming that I'm adopting:

• Changing void methods that alter class variables to methods that return values
• Make classes immutable instead of having classes with setters (JavaBeans antipattern)

Answer 3

Having written a decent chunk of Haskell means it's a lot easier for me to use Linq to SQL in my C# code.

I now lean strongly towards writing code that takes a result and returns a result, rather than modifying a variable as a side-effect.

I've written big chunks of both procedural and functional code, that makes it easier for me to factor my code into smaller chunks that are more one style or the other. When I only knew procedural/oop programming I had fewer tools in my mental toolbox.

Reading library sources in Haskell has taught me how to better boil my code down to separate abstractions from the actual task.

I've gained a lot from writing Haskell!

Answer 4

Event handlers that are closures;

button.OnClick += (sender, args) => MessageBox.Show("we captured " + someCapturedVariable);

Answer 5

Main use has been passing functions into higher-order functions like filter and map (Where and Select in .Net) This is really the biggest impact, allowing you to write things like set operations just the once, then things that act on or modify sets.

So things like

var SquareOfEvenIntegers = MyListOfInts
    .Where(i=>even(i))
    .Select(i=>i*i);

instead of

List<int> SquareOfEvenIntegers = new List<int>()
foreach(int i in MyListOfInts)
{
    if (even(i))
    {
        SquareOfEvenIntegers.Add(i*i);            
    }
}

Answer 6

I find that Python 3.x's move to iterators comes very natural to me, because it reminds me of Haskell's lazy evaluation.

Really, whether using Python 2.x or Python 3.x, list comprehensions, map, itertools, operator and (to a slightly lesser extend) functools, are my friends!

Answer 7

In some ways, I've found it striking how much I had been unconsciously using functional style programming, without recognising it for what it was.

For example, in Java I make heavy use of constructs in Commons Collections such as Transformer and Predicate, which are essentially closures, but implemented as Java interfaces. You then use the provided utility functions to transform and filter elements in a collection. This goes against the "standard" imperative way of doing this sort of thing in Java.

These, of course, are vanilla functional map and filter operations, but I had been instinctively using them without realising what it was. That suggests to me that functional style is to a large degree intuitive even if you're not told about it.

Answer 8

It doesn't.

Answer 9

Since functional programming is orthogonal to OOP it has really opened my eyes to how I structure my classes.

• I tend to have more meaningfully interfaces that resemble concepts.
• My code is better decoupled and I have more smaller meaningfully classes. It's rare that I create a class just to implement a pattern.
• I create fewer setters instead I call different member functions that compute the value I want and pass it to a single setter.
• Before functional programming I would never think of passing a function as a parameter as a solution while trying to solve a problem. Now this solution just pops into my head and really helps with DRY.
• My code contains more expressions instead of statement.
• If a solution allows it I lean towards lazy evaluation.

Answer 10

Functional programming and OO aren't disjoint concepts. One shortcoming in functional languages that I see is their lack of ADT expressiveness. The closest thing I've seen to functional programming in an OO language is Eiffel. By convention functions are referentially transparent, it would be ideal if this was enforced.

Answer 11

I wrote a bit about this in

How does functional programming affect the structure of your code?

Some is F#-specific, but there are a lot of general observations there.