9 ms·

Reconsidering the way I explain programming (2020)

59 points by swalladge 5y ago

pmoriarty 5y ago
One of the best ways is to teach them the basics of Logo. to square forward 100 right 90 forward 100 right 90 forward 100 right 90 forward 100 end is a square.[1][2] Then you can do: forward 100 square forward 100 square etc... Any child can get this. I did when I was 10 years old, with a bunch of other pre-teens. Got it right away and absolutely loved drawing various geometrical patterns. Of course, Logo is based on Lisp, so you can go pretty deep with it. [1] - Draw it for them as you explain it, or just show it directly on the computer using Logo and turtle graphics. [2] - Pardon if my program has any bugs.. I'm doing this from memory.. haven't touched Logo in decades...
- siraben 5y ago
  That code looks exactly like the LOGO-like language aimed towards children. I wrote during a hackathon[0]. But for compactness I forgo the newlines, so the language looks like this: △ n = [ ↻ 30, ↑ n, ↻ 120, ↑ n, ↻ 120, ↑ n, right ] When programming routines in Haskell: square :: Float -> Turtle () square n = do penDown moveForward n rotateTurtle 90 moveForward n rotateTurtle 90 moveForward n rotateTurtle 90 moveForward n rotateTurtle 90 penUp Recursion is forbidden and all loops are bounded. [0] https://github.com/siraben/vpl/blob/4b5d39cbf8d16a988218e62f9cca5110ab794c4c/src/VPLEval.hs#L102 https://github.com/siraben/vpl/blob/4b5d39cbf8d16a988218e62f...
France_is_bacon 5y ago
I 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-posing-vector-220328.jpg 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.
joe_the_user 5y ago
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 5y ago
  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.
  - renox 5y ago
    Yes: show how it's implemented then a few example of how it's used and the concept will usually be 'really' understood.
  - machiaweliczny 5y ago
amw-zero 5y ago
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 set of possible sequences of states. Nothing more. https://lamport.azurewebsites.net/tla/book-02-08-08.pdf https://lamport.azurewebsites.net/tla/book-02-08-08.pdf
- ithkuil 5y ago
  "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.
  - amw-zero 5y ago
    Sure but the purpose of software is to build a program that works correctly. We're not building sunsets.
    - ithkuil 5y ago
      I didn't say sunset, I said the process of experiencing a sunset. Building an AI that can reach that level of complexity is certainly an engineering problem and under the hood it can be modeled by state transition somewhere deep in the mechanism, but you won't get there and implement a human-level intelligence if you deliberately avoid higher level abstractions.
- mym1990 5y ago
  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)!
bordercases 5y ago
He's advocating for what amounts for tutoring, or 1-and-1 work.
neatze 5y ago
My favorite programming explanation video; https://youtu.be/Ct-lOOUqmyY https://youtu.be/Ct-lOOUqmyY
cryptonector 5y ago
> Now I think I can explain tail call optimization via an escalator analogy. Oh, that's nice!
w1nter 5y ago
Author 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.
- vbsteven 5y ago
  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.
- notenoughhorses 5y ago
  I thought your point was clear. As someone who is more of a “learner” than a teacher currently, I appreciate the thought of letting me, the learner, explain my current mental model and then a teacher helping troubleshoot that. Listening to this also helps pinpoint where I’m stuck, specifically. Often, a TA or professor will launch into their favorite explanation without first understanding my question.
vbsteven 5y ago
This 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.
Peritract 5y ago
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."
xorvoid 5y ago
This article demonstrates the key idea that I learned about teaching: the best teachers form-fit their teaching to the students specifically. It’s your first job as a teacher to (1) listen and understand where your students mindset is, and then (2) teach from that mindset. Using their vocabulary, their analogies, their interests, etc is super key. I was a Graduate Student Instructor in college and I LOVED this because to me it was like a puzzle: (1) try to figure out where a student took a wrong turn when learning a complex topic, (2) take them back to the wrong turn and walk with them down the “right turn” until they finally have that lightbulb moment. The key to all of that was speaking/explaining in their language, not mine.
tedyoung 5y ago
Some basics of how people learn that I've found is: * What do they know now (or think they understand)? You can only build knowledge on existing knowledge, so first find out what foundations exist (this connects to the author's "listener's worldview" idea). * Tutoring (1-on-1) will almost always be better than teaching (1-to-many) because you can (if you try) better understand what's being understood and what's not. * Learning is construction of desired knowledge, so learners have to "do" something and be provided quick feedback to build the desired concept (which is why learning on your own with little feedback is subject to learning the "undesirable" thing, even though it might have "worked" for you). I did a talk on this topic (Human Learning) that you can find on YouTube (JitterTed.TV).
rmprescott 5y ago
>Now I think I can explain tail call optimization via an escalator analogy. Circular, "Penrose Stairs" (https://en.wikipedia.org/wiki/Penrose_stairs https://en.wikipedia.org/wiki/Penrose_stairs) might be a better extension to the student's staircase model.

59 points by swalladge 5y ago

One of the best ways is to teach them the basics of Logo. to square forward 100 right 90 forward 100 right 90 forward 100 right 90 forward 100 end is a square.[1][2] Then you can do: forward 100 square forward 100 square etc... Any child can get this. I did when I was 10 years old, with a bunch of other pre-teens. Got it right away and absolutely loved drawing various geometrical patterns. Of course, Logo is based on Lisp, so you can go pretty deep with it. [1] - Draw it for them as you explain it, or just show it directly on the computer using Logo and turtle graphics. [2] - Pardon if my program has any bugs.. I'm doing this from memory.. haven't touched Logo in decades...

siraben 5y ago
That code looks exactly like the LOGO-like language aimed towards children. I wrote during a hackathon[0]. But for compactness I forgo the newlines, so the language looks like this: △ n = [ ↻ 30, ↑ n, ↻ 120, ↑ n, ↻ 120, ↑ n, right ] When programming routines in Haskell: square :: Float -> Turtle () square n = do penDown moveForward n rotateTurtle 90 moveForward n rotateTurtle 90 moveForward n rotateTurtle 90 moveForward n rotateTurtle 90 penUp Recursion is forbidden and all loops are bounded. [0] https://github.com/siraben/vpl/blob/4b5d39cbf8d16a988218e62f9cca5110ab794c4c/src/VPLEval.hs#L102 https://github.com/siraben/vpl/blob/4b5d39cbf8d16a988218e62f...

France_is_bacon 5y ago

I 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-posing-vector-220328.jpg 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.

joe_the_user 5y ago

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 5y ago
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.
- renox 5y ago
  Yes: show how it's implemented then a few example of how it's used and the concept will usually be 'really' understood.
- machiaweliczny 5y ago

amw-zero 5y ago

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 set of possible sequences of states. Nothing more. https://lamport.azurewebsites.net/tla/book-02-08-08.pdf https://lamport.azurewebsites.net/tla/book-02-08-08.pdf

ithkuil 5y ago
"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.
- amw-zero 5y ago
  Sure but the purpose of software is to build a program that works correctly. We're not building sunsets.
  - ithkuil 5y ago
    I didn't say sunset, I said the process of experiencing a sunset. Building an AI that can reach that level of complexity is certainly an engineering problem and under the hood it can be modeled by state transition somewhere deep in the mechanism, but you won't get there and implement a human-level intelligence if you deliberately avoid higher level abstractions.
mym1990 5y ago
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)!

bordercases 5y ago

He's advocating for what amounts for tutoring, or 1-and-1 work.

neatze 5y ago

My favorite programming explanation video; https://youtu.be/Ct-lOOUqmyY https://youtu.be/Ct-lOOUqmyY

cryptonector 5y ago

> Now I think I can explain tail call optimization via an escalator analogy. Oh, that's nice!

w1nter 5y ago

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

vbsteven 5y ago
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.
notenoughhorses 5y ago
I thought your point was clear. As someone who is more of a “learner” than a teacher currently, I appreciate the thought of letting me, the learner, explain my current mental model and then a teacher helping troubleshoot that. Listening to this also helps pinpoint where I’m stuck, specifically. Often, a TA or professor will launch into their favorite explanation without first understanding my question.

vbsteven 5y ago

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

Peritract 5y ago

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

xorvoid 5y ago

This article demonstrates the key idea that I learned about teaching: the best teachers form-fit their teaching to the students specifically. It’s your first job as a teacher to (1) listen and understand where your students mindset is, and then (2) teach from that mindset. Using their vocabulary, their analogies, their interests, etc is super key. I was a Graduate Student Instructor in college and I LOVED this because to me it was like a puzzle: (1) try to figure out where a student took a wrong turn when learning a complex topic, (2) take them back to the wrong turn and walk with them down the “right turn” until they finally have that lightbulb moment. The key to all of that was speaking/explaining in their language, not mine.

tedyoung 5y ago

Some basics of how people learn that I've found is: * What do they know now (or think they understand)? You can only build knowledge on existing knowledge, so first find out what foundations exist (this connects to the author's "listener's worldview" idea). * Tutoring (1-on-1) will almost always be better than teaching (1-to-many) because you can (if you try) better understand what's being understood and what's not. * Learning is construction of desired knowledge, so learners have to "do" something and be provided quick feedback to build the desired concept (which is why learning on your own with little feedback is subject to learning the "undesirable" thing, even though it might have "worked" for you). I did a talk on this topic (Human Learning) that you can find on YouTube (JitterTed.TV).

rmprescott 5y ago

>Now I think I can explain tail call optimization via an escalator analogy. Circular, "Penrose Stairs" (https://en.wikipedia.org/wiki/Penrose_stairs https://en.wikipedia.org/wiki/Penrose_stairs) might be a better extension to the student's staircase model.