IMHO: no.

The concept of a loop (i.e. doing something over and over as long as a condition is true) is (again IMHO) a much simpler concept than recursion.

The university I worked at tried moving functional programming into the first semester. Let's just say, that didn't work out at all. The imperative programming style is apparently much easier for students to grasp.

Edit: The more I think about it, it seems to me that a loop is clearer because the initial state, upon which you iterate on, is much more obvious. Where with recursion, I primarily see the step, but not where exactly I started from -- if that makes any sense..

Well, how to calculate sum from 1 to 5000 ?

Instead of looping from 1 to 5000, you compute (1 + 5000) * 5000 / 2

This is what "understand problem first" actually means

But now you can run into problems with integer overflow. It can be solved:

    sum(n) = is_even(n) ? n/2 * (n+1) : (n+1)/2 * n

because of one n and n+1 will always be even. But it show that unfortunately things are often not as straightforward as they first appear.

It's a very clear infinite recursion at best, and a buggy definition for odd `n` if that's fixed. I wouldn't imagine making either error if just looping...

But that can't be tail call optimized, so you should write something like

    sum(n, acc=0) = n == 0 ? acc : sum(n-1, acc+1)

To me that negates much of the 'declarative' character of a functional style. I don't feel it's really clearer than the imperative for-loop

    acc = 0
    for i = 1 to n
        acc += 1

I can see why I never got very far with functional programming, it's much too clever for me. I don't see how this example has any sort of limit test in it at all much less stops at or rather defines an extent of 5,000. oh well imperative peasant life can be a drudge but it gets my corn sown one kernal at a time.

I would argue

  sum(0) = 0
  when n != 0: sum(n) = n + sum(n-1) 

is kind of clearer. But quite often it is not that easy to give an recursive solution for an iterative problem. When you want to change every even number in an array/list from n to n+1 you can somehow do it recursively, but it is mor obvious to iterate over the elements (which in many functional languages can be expressed by "apply" or some similar function).

I don’t think that’s much clearer at all. I realize that you’re citing a specific example, but if your approach is to understand the problem first, then you may as well use the closed-form solution of your problem:

sum(1,n) = n*(n+1)/2

Which some compilers will produce for you, even if you use loops.

Maybe if you chose a different example, like generating power sets or the Fibonacci sequence, your point would be better made?

No, it isn't clearer. Just different. Which one is clearer depends who is reading and the way they think.

do people really think this is clearer than looping.. my mind immediately goes to a loop here

some people think in "what" and some people think in "how".

some people think in both. they should write blogs and help the whats and the hows communicate.

Looping was more natural to me, but learning Elixir (I've been using Learn Functional Programming with Elixir) made it so much easier to grasp and more natural. It's a fun language to use to boot.

I think both are valid approach of understanding the problem. Recursion, on the other side, needs some basic math introduction.

If i ask you to add from 1 to 10 , is that how you add ? 1 + 10 + let_me_add_from2_9 ? So yeah, not at all natural.

You easily see it's (1+10)*10/2, so you'll get to 55 way faster this way. Way more natural.