Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reconsidering the way I explain programming (2020)

blog.frantic.im

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Reconsidering the way I explain programming (2020)

#31

Post by ummwhat »

joe_the_user wrote: post #3

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. Recurs…

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.

Re: Reconsidering the way I explain programming (2020)

#32

Post by kazinator »

joe_the_user wrote: post #3

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. Recurs…

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.

Re: Reconsidering the way I explain programming (2020)

#33

Post by renox »

Olreich wrote: post #5
joe_the_user wrote: post #3

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. Recurs…

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.…

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

Re: Reconsidering the way I explain programming (2020)

#34

Post by zozbot234 »

allturtles wrote: post #13
sdedovic wrote: post #9

Earlier quoted context omitted.

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.

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.

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.

Re: Reconsidering the way I explain programming (2020)

#35

Post by Planktonne »

I find that a lot of developers assume that a failed explanation is due to a lack of precision, and so they try and teach with long, detailed, overly-precise explanations.

Precise explanations are fantastic for people who already understand the concept: they let them go a level deeper and explore the underlying truth. However, they're intimidating and unhelpful for people who have yet to grasp the concept.

For concepts, analogy works best - 'code is like a...' along with minimal examples of ideas in accessible situations for your audience. Alice and Bob, etc.

Teaching code is about finding the right metaphor for your students - whether that's recipes or language or robots or something else - not bashing at them with "All told, a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor."

Re: Reconsidering the way I explain programming (2020)

#36

Post by machiaweliczny »

Olreich wrote: post #5
joe_the_user wrote: post #3

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. Recurs…

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.…

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

Re: Reconsidering the way I explain programming (2020)

#37

Post by amw-zero »

AnimalMuppet wrote: post #15
amw-zero wrote: post #4

For me, there’s no better explanation possible than the description of software behavior in Specifying Systems by Leslie Lamport: > Formally, we define a behavior to be a sequence of states, where a state is an assignment of values to variables. We specify a system by specifying a set of possible behaviors—the ones representing a correct execution of the system. Programming is creating an executable description of a…

I am reminded of a quote by Mark Twain: "Humor can be dissected, as a frog, but the thing dies in the process, and the innards are of interest only to the purely scientific mind." The Lamport quote does the same thing, but to software. The thing died in the process.

I feel the opposite. By understanding what software is at its core, I can both appreciate it more, and build it better.

Re: Reconsidering the way I explain programming (2020)

#38

Post by lupire »

joe_the_user wrote: post #3

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. Recurs…

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.

Re: Reconsidering the way I explain programming (2020)

#39

Post by lupire »

ummwhat wrote: post #31
joe_the_user wrote: post #3

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. Recurs…

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…

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

Re: Reconsidering the way I explain programming (2020)

#40

Post by amw-zero »

ithkuil wrote: post #7
amw-zero wrote: post #4

For me, there’s no better explanation possible than the description of software behavior in Specifying Systems by Leslie Lamport: > Formally, we define a behavior to be a sequence of states, where a state is an assignment of values to variables. We specify a system by specifying a set of possible behaviors—the ones representing a correct execution of the system. Programming is creating an executable description of a…

"the experience of a beautiful sinset is just the firing of a million of neurons in a specific pattern, nothing more." There are emergent properties of programming, the craft, that you need to master if you want to navigate the next levels of complexity. Just reasoning about sequences of state transition is going to be I'll suited for many occasions, even if technically that's all you need to model everything.

Sure but the purpose of software is to build a program that works correctly. We're not building sunsets.
Post reply on HN