Re: Ice breakers

[David Given <dg@...>]

On 08/11/12 18:04, Tim Mensch wrote:
[...]
> People new to programming have a hard time thinking in abstractions.
> Period. Talking about a=a+1 creating a "new value" and assigning a
> reference to "a" rather than adding one to "a" is a level of abstraction
> that I would almost guarantee make a beginner's eyes glaze over.

[Oooh, lots of replies. I seem to have struck a nerve! I should point
out now that I'm not picking you out in particular, Tim, you just happen
to have had the first reply I saw. The background is that I have a
nephew who's going to be nearing the age of learning to program soon, so
I've been thinking about this a lot. Although I should point out, in
terms of full disclosure, that I'm actually going to start him out on
LOGO...)


Obviously I wouldn't explain it like that. I'd start out drawing --- on
paper, mind --- names, arrows and boxes.

Boxes contain values. Arrows point from names to boxes. The *only*
things you can do are to create new boxes and change arrows to point at
different things.

From here a whole bunch of otherwise complicated things become trivial.
Function parameters are new names pointing at the things you call the
function with. Two names can point at the same box without confusion.
Names can point at nothing, if you like. A table is a box containing
names, each of which points at another box. A name in a box can point to
the box the name is inside, if you like! Boxes which aren't pointed to
by anything fall off the diagram.

This particular abstraction is simplified --- expression evaluation is
glossed over, and Lua tables actually map values to values, not names to
values --- but it's simplified in such a way as to be expandable later.
This is an abstraction that can be used by a novice programmer all the
way up to a seasoned professional. Everyone draws boxes and arrows. At
no point do we have to sit the student down and explain that everything
we've been teaching them was wrong.

What's particularly valuable is that this abstraction leads inexorably
towards the absolutely single most important concept any computer
programmer will ever need to learn, which is data structures.

> The
> more concrete you can make a concept, the easier it is to grasp.

Yup. Which is why we have a model which can be drawn on paper. If I'm
asked, 'what does this do?', the first answer is *always* going to be to
hand over a pencil and to say 'draw it'.

The main thing I don't like about teaching
pass-by-reference/pass-by-value is that it's a distinction that is both
*technical* (in that in order to understand the distinction you
basically have to already have enough knowledge to understand the
distinction --- which means it's very hard to explain coherently to
someone who doesn't already know what it is) and also
*indistinguishable* (in that I cannot look at a piece of code and tell
at a glance which it is). This means it's pretty hard for a novice to grasp.

(I suffered through a lot of this in maths courses. I still remember the
horrible frustrated muddled feeling of simply being unable to see a
distinction that the teachers were pointing out. I don't want to inflict
that on anyone!)

Using the abstraction described above, parameters are always passed the
same way --- by arrow --- and the need to learn this distinction simply
vanishes.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "Of course, on a sufficiently small planet, 40 km/hr is, in fact,
│ sufficient to punt the elastic spherical cow into low orbit." ---
│ Brooks Moses on r.a.sf.c

Attachment: signature.asc
Description: OpenPGP digital signature