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

11–20 of 49 posts

Re: Reconsidering the way I explain programming (2020)

#11

Post by lmm »

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…

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

Re: Reconsidering the way I explain programming (2020)

#12

Post by macintux »

rdaystrom wrote: post #10
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 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.

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

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

Re: Reconsidering the way I explain programming (2020)

#13

Post by allturtles »

sdedovic wrote: post #9
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 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.

Re: Reconsidering the way I explain programming (2020)

#14

Post by AnimalMuppet »

lmm wrote: post #11
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…

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

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

Re: Reconsidering the way I explain programming (2020)

#15

Post by AnimalMuppet »

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.

Re: Reconsidering the way I explain programming (2020)

#17

Post by siraben »

rdaystrom wrote: post #10
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 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...

Re: Reconsidering the way I explain programming (2020)

#18

Post by siraben »

pmoriarty wrote: post #2

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…

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/4b5d39cbf8d16a988218e62f...

Re: Reconsidering the way I explain programming (2020)

#19

Post by waynesonfire »

rdaystrom wrote: post #10
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 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.

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.

Re: Reconsidering the way I explain programming (2020)

#20

Post by vincent-manis »

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…

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