[racket] review my tutorial?

On Aug 2, 2013, at 2:01 PM, grant centauri wrote:

> Matthias, thank you so much for your response.  Coming to Racket has been exactly what I needed to take an interest in programming and education and find a path that works!  I will definitely follow through with learning the 2htdp/universe teachpack (which was on my list anyways), and hopefully I can help make a bridge between Minecraft and Racket so there's a simple and familiar 3d building environment to work with.
> 
> I am actually interested in trying to introduce programming ideas to children as young as 5 or 6.  Much of the mathematics taught to children at this age in the Montessori school I work at is embedded into physical materials.  I'm trying (with my purely amateur understanding) to come up with activities that can start teaching the fundamental thinking skills that HtDP seems to be aiming at.  Minecraft seemed like a good replacement for actual real-world building blocks.  I was hoping some examination of building structures via recursion, and building more complex things out of simpler programs would be helpful to teach children who don't already have a familiarity with algebra.


Some issues: 

-- [1] As you embark on this adventure, keep in mind that there are individual experiences ("when I was five, I did differential equations", "I taught my son recursive programming when he was 9, and by the time he was 12, he won the universe championship in copying code") and there are school-wide, system-wide experiences ("we were able to use drracket to teach even our American Football players what a function is but 3 our of 28 still didn't get it." -- this one's real). If you are only interested in the former (with your children or a small group of children in a smallish school), you can experiment a lot and that'll be that. If you are interested in systemic change, things are different. 

-- [2] We have tried to teach algebra via programming, but in general, this is difficult to deploy in schools. 

-- [3] One of the goals we have is to ensure that kids learn concepts/skills that transfer to other areas, especially algebra and other mathematics and sciences. 

-- [4] if you really wish to enable algebra with programming, stay away from imperative versions of LOGO and other APIs. There is evidence from the 1970s that Paperts' claims of skill transfer are vastly exaggerated, especially when it comes to scale. Imperative means you write down x = x + 1 in some form or other. It is guaranteed to confuse kids who still need to learn algebra, in parallel or in a sequence. 

-- [5] When you write that you want to teach recursion, realize that recursion is based on algebra. The central point of programming in Racket's teaching languages happens to be the central concept of algebra: 

		** function ** 

These notions are 99% equivalent. [Approximately 37 people in the world -- constructive logicians -- will be able to explain the remaining 1%.] This NOT true when you use imperative quasi-functions as in LOGO. Function definitions are ubiquitous: 

 	f(x) = 20 * x + 100 

        distance-from-left(time) = 20 * time + 100 

Mechanically, recursion is trivial: allow the name of the function to occur on both sides of the '=' sign. In traditional math education, recursion hardly ever shows up except for differential equations [ f = d/dx (f) ] and most mathematicians use special names for things such as d/dx, which we call 'function'. 

-- [6] Recursion is useful in two cases for programming:

---- [a] when the data that you process is finite but arbitrarily large (files, lists, trees, forest). The only systematic way to describe it uses self-references and therefore you want to design functions that are self-referential in the same way so that they match. We call this 'design recipe' and it is part of our skill transfer idea (see [3]). 

---- [b] when the problem calls for divvying up into small problems and stitching together their solutions to the overall solution. That is a very different kind of recursion. We call it generative recursion. 

Traditional teaching approaches don't understand [a] vs [b] and make all recursion look difficult.  As Daniel said, "recursion is hard" -- he clearly comes from that school. 

Our 'design recipe' conquers [a] in a straightforward way and we have high school students program recursively in no time. Once you are not afraid of [a], [b] follows more easily. 

There is a third use of recursion in purely mathematical-algebraic-functional programming: [c] repetition. 

-- [7] Still you want to teach functional programming because it teaches algebra and you want to avoid recursion for young kids (middle and below) if if they seem to get it. The world/universe approach is key to solving this puzzle. It moves repetition from the program to the user's muscle. You want a functional program that reacts to every key stroke? No problem. You want to react to every mouse event? No problem. The key is that the functions you write deal with ONE and ONLY ONE key or mouse event at a time so that the young programmers doesn't have to think about repetition and yet has a fun experience. 

Try bootstrap yourself. Try HtDP/2e. You'll see how close to math you are and you will soon see how the design recipe is about skill transfer. -- Matthias