[joe_the_user]

The simplest analogy to programming is a recipe.

    Add X, 
    Add Y, 
    Do Z till Z is in Q state. 

So while/for loop imo are really simple to get. Function calls are a bit harder but not much.

Accomplishing tasks with recursion? That's utterly counter-intuitive imo. A given person can learn it but feels like a trick. Maybe a cool trick they're cool for having learned and maybe a weird trick someone is pushing on them.

Recursive solutions to programming problems can be great once you get the whole idea but recursion is not an easy way to start people programming. It might not be a bad way - if you're a highly committed 17 teen year old hot learn new things and willing to put in serious effort. learning LISP at MIT back when they taught is something would have like to have done. IE, Hard isn't necessarily bad. But don't expect people who want to put in minimal effort, who are terrified by just showing up to learning programming, to learn this hard way. And especially don't expect them to appreciate that you decided to teach this way.

A lot of programming geeks are in denial about the inherent conceptual difficulty of functional programming (which isn't even to say fp is bad, it has many virtues but easy for novices will never be one).

Edit: To put it in the author's terms, there's hierarchy of modalities and procedural processes are on the bottom and thus everyone can get them. Maybe 1-1 tutoring can different.

[Olreich]

I find the easiest way to get past the abstraction of recursion is to describe what a function actually is, rather than the handwavey definitions we usually steal from math. A function is a stack and a list of instructions. When you call a function, you add things to the stack, and when you return from the function, you throw those things away.

Stack of papers, flight of stairs, layers of onions, circle of life, etc. they all just harken back to what it actually is without having to define it directly.

[joe_the_user]

A function is a stack and a list of instructions.

If we're using an 80x86 processor, the function concept is more or less implemented by several facilities - you have a sequence of instructions somewhere in memory, you have a stack area (shared by everything in a given address-space, using a stack pointer in the cpu), you a call instruction that pushes the current instruction pointer to the stack as well as pushing flags and similar stuff to the stack and you have the return instruction, which does the opposite, restore instruction pointer and whatever else was pushed in the call.

Which is to say that on a raw, low level, functions don't "exist" in the fashion a programmer imagine at a higher level. That's not saying the concept is wrong but is saying that the people don't easily see functions as the natural building blocks of everything might be wrong either.

[renox]

Yes: show how it's implemented then a few example of how it's used and the concept will usually be 'really' understood.

[machiaweliczny]

I would just exlain that funcion call adds intructions inside it to recipe/execution list. I think kids probably can get it easily.

[vincent-manis]

Well, the Brookline Schools experiment with LOGO (some 40 or so years ago) demonstrated that people can learn and understand recursion. The big deal is to show the distinction between the text of the procedure and the process of evaluating it (known in those days as the `Little Man' model). When I used to teach with that, we'd actually have students acting out the role of the Little Man (`I need f(2), can someone do that for me? I'll wait for the answer').

[kazinator]

People who don't understand recursion have probably never seen a recursive definition in math, or performed an inductive proof. That would be the problem to fix first. Bringing programming into it is just heaping on confusion.

There are recursive structures in nature. Some people might respond to the neatness of recursively generated graphics. Pointing out recursion in language could be useful. Introduce a program for recursively generating random sentences and such.

[ummwhat]

I'd argue everything about how we think is already deeply recursive. Your brain has some sort of function for parsing what it is being told. Whenever a new context/setting comes up (such as "yesterday", "in Vladivostok", "she said"), the story within the new context is understood and parsed with the same brain function as the outer context.

Similarly when we look at a picture on a wall, we interpret the scene within using the same machinery as we interpret the real world, while also being aware that the scene is "on the stack" relative to real things like the wall. There is nothing about a picture within a picture that breaks our comprehension of what we are looking at.

I think {you know {what I'm talking about}}.

It is strange that recursion seems hard and loops seem easy to most brains.

[lupire]

That's a stack, not recursion. Recursion is self-reference.

[ummwhat]

The same brain function is processing every layer of the stack. Its the call stack of a recursive function.

[sdedovic]

I find recursion can be just as simple to explain.

Start with a basket of tomatoes and a bowl. If there are no tomatoes in the basket, you’re done. Otherwise: Take one tomato. Dice it. Put the output in the bowl. Recur.

[allturtles]

Have you actually explained it to people that way and had them get it? I think most people would just understand what you described as an iterative process, and understand recur as being no different than repeat.

[zozbot234]

Iteration (repetition) is a special case of recursion where the recursive action is always the final step in the process; it's a kind of recursion that dispenses with the need to track a stack of process activations. So it's quite possible to teach both in the same context.

[mimixco]

Indeed. Recursion requires that a procedure calls (or recurses over) itself.

[mimixco]

https://en.wikipedia.org/wiki/Recursion

https://www.lexico.com/definition/recurse

[zug_zug]

I'm meh on that example (hard to say it's not a while loop), but I agree that humans already understand and execute recursion in their day-to-day life, so it is a communication thing.

How about this example as an example of recursion: Looking up a word in a dictionary (a real-life binary search).

[lmm]

"Do X then do Y" style programming is natural for some people - mainly those who first learned programming that way. Mathematical expression style is more natural for other people, and recursion is very natural in that context.

[AnimalMuppet]

The question is, for people who haven't learned programming at all, which way is more natural? (And it may depend on how mathematical they are, and/or on some aspects of personality...)

[lupire]

17? 10 year olds handle it easily.

Every shampoo bottle has recursive instructions:

Wash, rinse, repeat.

Also: Eat, work, sleep, then do it all again tomorrow.

Who are your ancestors? Your parents and all their ancestors.

[Akronymus]

Those are loops rather than recursion though.

[Cheezmeister]

> learning LISP at MIT back when they taught

Oof, shade thrown.

[rdaystrom]

I try to avoid recursion, I don't want to blow out the stack.

Personally I think it should not be used for implementation, I consider it to be a security risk. It's ok for high-level pseudocode.

[siraben]

This isn't true if your language does tail-call optimization[0].

> I consider it to be a security risk.

Again, non-issue if your language handles recursion properly (and in some languages like Haskell, "blowing the stack" is not a thing that happens).

[0] https://en.wikipedia.org/wiki/Tail_call#Implementation_metho...

[nights192]

I believe he's more concerned about issues where tail-calls aren't possible or attractive.

[macintux]

It depends on the language. Many good languages are designed to handle recursion safely.

For some, it’s practically the only way to loop.

[waynesonfire]

Looks like you learned something new. You now also have a guage to measure the sophistication of a programming language. Ask if it supports tail call optimization and move on if the answer is no.