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

41–49 of 49 posts

Re: Reconsidering the way I explain programming (2020)

#41

Post by Akronymus »

lupire wrote: post #38
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.

Those are loops rather than recursion though.

Re: Reconsidering the way I explain programming (2020)

#42

Post by xorvoid »

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.

Re: Reconsidering the way I explain programming (2020)

#43

Post by notenoughhorses »

w1nter wrote: post #25

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.

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.

Re: Reconsidering the way I explain programming (2020)

#44

Post by joe_the_user »

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

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.

Re: Reconsidering the way I explain programming (2020)

#45

Post by tedyoung »

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

Re: Reconsidering the way I explain programming (2020)

#46

Post by mimixco »

mimixco wrote: post #23
allturtles wrote: post #13

Earlier quoted context omitted.

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.

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

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

Re: Reconsidering the way I explain programming (2020)

#48

Post by ummwhat »

lupire wrote: post #39
ummwhat wrote: post #31

Earlier quoted context omitted.

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.

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

Re: Reconsidering the way I explain programming (2020)

#49

Post by ithkuil »

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

Earlier quoted context omitted.

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

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.
Post reply on HN