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
____________________
Racket Users list:
http://lists.racket-lang.org/users
