> Now I think I can explain tail call optimization via an escalator analogy.
Oh, that's nice!
Reconsidering the way I explain programming (2020)
21–30 of 49 posts
Re: Reconsidering the way I explain programming (2020)
#22Earlier quoted context omitted.
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.
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...
I believe he's more concerned about issues where tail-calls aren't possible or attractive.
Re: Reconsidering the way I explain programming (2020)
#23Earlier 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.
Indeed. Recursion requires that a procedure calls (or recurses over) itself.
Re: Reconsidering the way I explain programming (2020)
#24For 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…
Einstein said “Everything should be made as simple as possible, but no simpler.” Ultimately, we find out that simplicity, whether in process or explanation, is sometimes actually the hardest thing to achieve. Through many struggles in doing things wrong or inefficiently we find that simplicity eventually(if we are lucky)!
A favorite quote.
Re: Reconsidering the way I explain programming (2020)
#25Author here. After reading the comments I’m afraid my article didn’t communicate the main point clearly. The mental models suggested here are sweet, but:
It’s not about how to explain recursion or programming, it’s about explaining abstract and complex concepts via adopting to the listener’s worldview and letting them experiment to evolve that view.
Re: Reconsidering the way I explain programming (2020)
#26The 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 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.
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).
Re: Reconsidering the way I explain programming (2020)
#27I think the best way to explain a new concept is by analogy. Take something solid that everyone knows about and then explain it that way. It's not 100% effective, but it is probably 80% effective that people will understand the broad underlying concept, then be able to fill in the dots on the remaining explanation. That's because they have a framework on which to hang the sheetrock, the electrical sockets, put on the roof, etc. (see how I did that?)
That's pretty much what happens when we are 4 or 5 years old and learning. You don't teach a child 1+1=2, oh no. You take one rock, then a second rock, and ask them how many. The rock is one. "1" is not 1, and "1" + "1" is not "2", because the young children don't understand it that way. Then you put the number 1 next to each rock and add them, and eventually they understand. But it is very concrete. As adults, we don't need the actual rocks, but we do need a known structure to compare things and assign the "rock" we know to the number "1".
This applies to rote memory as well as understanding concepts. As an example how concreteness helps rote memory, let's take the following list of 11 words: dog, cantaloupe, priest, hill, tornado, ocean, yellow, urn, fox, moon, mushroom.
Most people (not all) will not be able to memorize these abstract words/ideas, even if familiar with them all. But if you match them with something more concrete, they will.
So instead of looking at the abstract words, just match each word with something more concrete in your imagination. So see in your mind's eye this story, and the words you hve to memorize are in italics: A huge 20 foot German Shepard (dog), has a cantaloupe in his mouth and spits it out super hard and fast and it goes through the air like a cannonball and hits a priest who is standing on a big hill, and the priest rolls down to the bottom of a hill where a big tornado comes by at that instant and scoops him up and travels a little while to a big ocean that is bright yellow. Floating on the water is a huge 10 foot tall black and white striped urn and all of a sudden, a very sexy cartoon fox (https://cdn4.vectorstock.com/i/1000x1000/03/28/fox-sexy-posi...) comes out of the top and then shoots straight up out of the atmosphere at supersonic speed and goes up and lands on the moon, where the fox creates a big mushroom cloud when she lands.
If you imagine this story in great detail, you will have little problems memorizing those words and be able to say them all in order with ease. Even backwards order is easy. And this is almost always with 100% accuracy.
So it is the same thing when trying to teach someone an abstract idea for the first time, the exact same. Use concrete examples. Like the stairs in this guy's example, that was great that he finally understands about using analogies.
Re: Reconsidering the way I explain programming (2020)
#28This is similar to what I do but in my head the escalator goes down instead of up.
When editing (mostly C-like languages) I can "see" the execution thread pass through the code like a step-through debugger. At a function call I can mentally "step into" the function and the function is visualized to the right of the current function with its first line on the same height as the call site. Doing this for recursing functions means a visualization that progresses downwards and to the right.
I guess my mental model evolved this way after years of step-through debugging.
Mental models for code and other things are a fascinating topic. I also have a very specific calendar/timeline model that is not a straight line at all. A full year "view" arranges months in a 2D layout where some months progress "up", others "down" and they are connected in weird ways. For example 31/01 and 01/02 are adjacent, but 30/11 and 01/12 are not. 31/12 is the last box of the year and is adjacent to 01/01 repeating the pattern for the new year.
Re: Reconsidering the way I explain programming (2020)
#29The 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…
> learning LISP at MIT back when they taught
Oof, shade thrown.
Re: Reconsidering the way I explain programming (2020)
#30Author here. After reading the comments I’m afraid my article didn’t communicate the main point clearly. The mental models suggested here are sweet, but: It’s not about how to explain recursion or programming, it’s about explaining abstract and complex concepts via adopting to the listener’s worldview and letting them experiment to evolve that view.
I enjoyed the article and it was very clear to me. Thank you for writing it.
Singling out details and sidetracking the comment thread about this one detail is just a thing that HN tends to do frequently. Usually the first few comments determine the tone/topic of the thread instead of the article itself. Which is not always bad.