---------- Forwarded message ----------
From:
Eli Frey <eli.lee.frey@gmail.com>
Date: Wed, Mar 20, 2013 at 4:56 PM
Subject: Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning
To: OWP <
owpmailact@gmail.com>
I have not read Bacchus' paper, so i might be off the mark here.
Functional code is just as simple (if not more so) to puzzle apart and understand as imperative code. You might find that instead of "stepping through the process" of code, you end up "walking the call graph" more often. FPers tend to break their problem into ever smaller parts before re-assembling them back together, often building their own vocabulary as they go. Not to say this is not done in imperative languages, but it is not so heavily encouraged and embraced. One result of this is that you can easily understand a piece of code in isolation, without considering it's place in some "process". It sounds as though you are not yet comfortable with this yet.
So yes, you might have to learn more vocabulary to understand a piece of functional code. This is not because the inner workings are obfuscated, but because there are so many more nodes in the call graph that are given names. You can still go and scrutinize each of those new pieces of vocabulary by themselves and understand them without asking for the author to come down from on high with his explanation.
Let's take iteration for example. In some imperative languages, people spend an awful lot of time writing iteration in terms of language primitives. You see a for loop. "What is this for loop doing?" you say to yourself. So you step through the loop imagining how it behaves as it goes and you say "Oh, this guy is walking through the array until he finds an element that matches this predicate." In a functional style, you would reuse some iterating function and give it functions to use as it is iterating. The method of iteration is still there, it has just nested into the call graph and if you've never seen that function name before you've got to go look at it. Again I don't mean to suggest that this isn't happening in an imperative language, just not to the same degree.
As well there is a bit of a learning curve in seeing what a function "does" when there is no state or "doing" to observe in it. Once you get used to it, I believe you will find it quite nice though. You have probably heard FPers extolling the virtues of "declarative" code. When there is no state or "process" to describe, you end up describing what a thing is. I for one think this greatly increases readability.
Good Luck!
Eli