What statements and approaches should I avoid when learning functional programming?

Question

I have 6 years of programming experience, mostly following the object oriented paradigm, and I'm interested in learning functional programming. My main goal is to become a functional paradigm programmer and not a programmer who is using a functional language but still writes in imperative style.

When I'm practising in functional programming I still follow an object oriented way of thinking, like loops, mutable variables and so on. I picked F# as a basic functional language and because it's very tightly integrated with other .Net languages, like C#. F# allows usual object oriented statements, therefore you can use F# syntax but not actually produce functional code.

What statements and approaches should I avoid when learning functional programming?

Answer 1

Functional Programming is more than just a list of statements to avoid. It's a (often) radical shift in mindset. For example, there are no destructive state changes allowed in functional programming. If I say that A = 5, I have not set up A as a kind of box containing a 5. I've made A exactly the same as 5, forever. There's a very very good book, co-written by the one and only Jon Skeet called Real World Functional Programming.

As far as learning purely functional programming is concerned though, I'd actually recommend Haskell over F#. Granted you'll probably get more done in terms of production code with F# or Ocaml but Haskell will bend your mind into the proper shape in order to grok functional programming. The process may take some time, however.

I recommend Learn You a Haskell if you want a guide to that. The C#/F# book option is less painful though. C# and F# let you solid, workable magic as a functional programmer. Haskell is black sorcery by comparison.

Answer 2

Learning functional programming is not about applying what you know from imperative and object-oriented programming and leveraging that to learn functional programming. In your question you are asking what to avoid, when I believe you should be thinking is: To learn functional programming I realize I should totally set aside what I know about imperative programming; where should I start.

As some starting advice see How to make the transition to functional programming?

So don't convert imperative code to functional code. If an algorithm is amiable to functional programming then use functional programming. If an algorithm is amiable to imperative programming then use imperative programming.

To answer your question more specifically

• Instead of selection statements use pattern matching.
• Instead of iteration statements use recursion.
• Instead of objects use discriminated unions.
• Instead of .NET collections, use F# types such as F# list (which are different from .NET list), tuples, etc. Note: objects are based on classes which are typically heap based and preserve state while F# types are based on structures which are typically stack based, are optimized for use with F#, and typically immutable.

In the object-oriented world objects are king, in the functional world functions are king.

Answer 3

Probably the most important thing to avoid is using constructs that change state.

Many people who start learning functional programming try to "emulate" imperative thinking in a functional language. This results in poor programs that make them feel that functional languages are cumbersome and ineffective. So it's important to get rid of imperative thinking. Don't think about the steps the program should do, think about expressions (functions), what they mean, and how to combine them to get the desired result.

Also, don't be too concerned about the effectiveness of your program at the beginning. Imperative programmers often feel that creating new instances of data structures each time they want to "change" something must make the program slow and ineffective. Functional languages are well optimized for that.

As stated in another answer, F#, OCaml, Scala and many other functional languages allow state-changing constructs, side effects and imperative sequences of statements. On the other hand, Haskell doesn't permit that and so you have no choice but to learn how to do it in a purely functional way. (I've seen many people describing it as "rewiring one's brain".)