# Change my way of thinking in preparation for functional programming

When switching to a functional style of programming after coming from procedural and OOP, what things do I need to know upfront about "this new way of thinking"?

How do you prepare yourself for diving in the FP world and get it first time around?

What are the basics to learn and set straight first?

-
Try it then post a question if you get stuck on something – Tom Squires Feb 29 '12 at 9:43
@Vladimir Volodin: That would be nice but it's not mandatory for every book. Can you recommend some good ones (preferably language agnostic)? – JohnDoDo Feb 29 '12 at 10:11
You don't have to dive. You can try lambda expression in an OOP language like c# to smooth the transition from OOP to FP. – TomCaps Feb 29 '12 at 14:55
I think you have it backwards. Try functional programming, and your way of thinking will change. – kevin cline Feb 29 '12 at 21:11

Get a copy of "Structure and interpretation of computer programs" and work yourself through the first chapter "Building abstractions with Procedures". Best introduction to functional programming I have ever had.

EDIT: If you want something more comparative, try "Seven languages in seven weeks" (disclaimer: this book is still on my TODO list).

-

You're going to need declarative thinking instead of the procedural "first do this, then do this, then do this..." way of solving problems. Understanding recursion might be good starting point, as it is a kind of sweet spot between procedural and declarative thinking.

-

FP is based on lamdba calculus. You need to know that. Its a good starting point. Functions are everything. There is no concept of state (although you can fake it at a higher level).

In OOP,

a=1 a=a+1

is accepted. Not so in FP. You just can't assign the variable an another value. If you want to learn FP for the long-term, learn Haskell. It's the most purest version of FP out there and its quite complicated too (I have just started learning it) but still worth learning it.

An Introduction to Functional Programming gives you a high level overview of what FP is all about.

Two caveats though

1. If you want to learn FP for jobs, then there aren't too much vacancies out there. Procedural and OOP still rules the job market. But FP can help you a lot in exploring new ways of solving a problem.
2. FP compilers aren't blazingly quick. Since FP is more concerned with solving the problem, you can't expect C speed. But still you can issue instructions to compiler(in Haskell) to speed up the execution process. The trade-off is you get a lot of time focusing on the program in hand rather than fire-fighting bugs.
-
"FP is based on lamdba calculus. You need to know that." No, you don't. Knowing the lambda calculus isn't necessary to understand functional programming more than knowing Turing machines (or assembly) is necessary to understand imperative programming. – sepp2k Feb 29 '12 at 10:53
@sepp2k To get good at FP with a long-term objective, I honestly believe learning lambda calculus is necessary. You can learn it without lambda calculus but learning it would make you better at FP. – Ubermensch Feb 29 '12 at 13:49
FP certianly does have state its just that that state is usually immutable, also not sure I agree with the statement about compilers being slow – jk. Feb 29 '12 at 16:07
@jk. Surely, they have state but not it in the OO way (States can be included in functions or as matching patterns and in more subtle ways). And an immutable state means you have just a single state. That's why a function should always return the same value. Regarding compilers, I don't think they can match C/C++ in terms of pure speed since the compiler takes care of the steps required in computing the result instead of us specifying the order. FP has its biggest advantage in reduced developer costs and parallel computing rather than pure CPU speed. – Ubermensch Mar 1 '12 at 4:10

I try my best to remember the following mantra:

Data in --> Transform Data --> Data out

or

TransformData(Data In)--> Data Out

-
It should be TransformData(DataIn)->DataOut – Ubermensch Feb 29 '12 at 14:38
:) as an matra "Data In, Transform Data, Data Out" is easier to say "TransformData, Open Bracket, Data In, Close Bracket, Data Out" I'm only kidding I agree with you. – Darknight Feb 29 '12 at 15:02
It's just a friendly comment mate. Thanks for the response. – Ubermensch Feb 29 '12 at 15:04
I know, I was just joking with you, no offence ment, in fact I think I'll update my matra. – Darknight Feb 29 '12 at 15:06
Man your skill-set is quite big. – Ubermensch Feb 29 '12 at 15:10

You have put the cart before the horse. You don't need to prepare. Just pick a language that looks interesting, find some documentation, and try it. If you get stuck, then stop and search for an answer. As you progress, your way of thinking will change.

-
Thanks for taking the time to respond and +1 – JohnDoDo Mar 2 '12 at 8:04