Live data from Hacker News

Reconsidering the way I explain programming (2020)

blog.frantic.im

1–10 of 49 posts

Re: Reconsidering the way I explain programming (2020)

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

Re: Reconsidering the way I explain programming (2020)

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

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.

Re: Reconsidering the way I explain programming (2020)

#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 set of possible sequences of states. Nothing more.

https://lamport.azurewebsites.net/tla/book-02-08-08.pdf

Re: Reconsidering the way I explain programming (2020)

#5

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. they all just harken back to what it actually is without having to define it directly.

Re: Reconsidering the way I explain programming (2020)

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

Re: Reconsidering the way I explain programming (2020)

#8
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…

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

Re: Reconsidering the way I explain programming (2020)

#9

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.

Re: Reconsidering the way I explain programming (2020)

#10

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.

Post reply on HN