Brian Harvey has written on the closely related
matters of what it takes to systematically teach
the concepts of (a) programming by composing functions;
(b) recursion (a very special case of composing functions).
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.2744
My own intuition is that it shouldn't be surprising
if some find functional programming easier to
learn than procedural nor if learning procedural progamming
first makes it harder for some to learn functional:
As Harvey points out, procedural programming is "built up"
from the concept of taking single steps, each of which
changes the environment -- then combining those with
conditionals and loops. On the other hand, functional programming
is built up out of the concept of functions that can be
composed by linking their inputs and outputs plus the
essentially inductive concept of self-application.
There is little or no overlap in those concepts (until
you get to fairly deep CS). Knowing steps, conditionals,
and loops doesn't much help prepare one to know composition
and then recursion. It stands to reason that that's true
the other way, too: knowing function composition and recursion
doesn't help learn sequential concepts.
It's possible to get quite comfortable with function
composition and inductive definitions without learning
programming at all. For example, Halmos' "Naive Set Theory"
might go a long way in communicating these concepts (and
not a line of code in site). So some people will surely
find it easier to learn functional styles first.
On the other hand, if you've learned sequential programming,
the functional languages present two major (related) obstacles:
1) A programmer who shows up to the first day of class and
says "Ok, what's the syntax for a for loop? How do I assign
to a variable," is going to have to spend the first several
hours learning to not look for these things.
2) The notation of functional languages is remarkably
confusing unless you already know the concepts of
composition and recursive definition (and, even then,
the notations tend to be a bit cryptic). So, a
programmer with an imperative background coming with
the question "is assignment written x = y or x := y
or what?" is going to find himself looking at indecipherable
wall paper rather than self-revealing code.
(But, again: everything below the citation given is
just my intuition and understanding of what people
like Harvey have reported
