[Edu-sig] Code to Joy in The Economist (June/July 2018)

[Eric Matthes]

I think the key here is to start with an accurate metaphor, that you can
build upon later. Consider this brief introduction to variables:

"A variable is like a label on a piece of data. That piece of data can be
simple, such as a number or a name, or it can be a more complex data
structure. Whenever you want to work with that data, you can just use the
name of the variable instead."

Compare that phrasing to this one:

"A variable is like a box, which you can put a piece of data in. That piece
of data can be simple, such as a number or a name, or it can be a more
complex data structure. Whenever you want to work with that data, you can
just use the name of the variable instead."

You can move right from either of these phrases into examples using
variables. But when you get to the point where you're focusing on
"debugging reference/ value mix ups", one of these introductions serves you
much better. The first allows you to jump right into clear explanations of
how to consider what's happening in your program. The second requires you
to go back on your original explanation, reintroduce the variable concept,
and then move forward.

I started teaching and writing using the "value in a box" model because
that's what I was taught. But I have recently switched my teaching and
writing over to use the "label on a piece of data" model, because it's more
accurate for Python.

Eric

On Sun, Jun 3, 2018 at 9:00 AM, Carl Karsten <carl at nextdayvideo.com> wrote:

> Not only does that not answer my question, it contradicts previous
> statements.
>
> >> >> You lost me here. What's wrong with bucket?
>
> >> That doesn't tell me how postit notes are different from buckets.
>
> and, I assure you, even if one (me) understands all that fish in
> bucket stuff, I still experience frustration debugging reference/value
> mix ups.
>
> So I totally disagree with "must teach them this" assertion.   Every
> minute spent on that displaces time that could be spent on something
> else, and I think you will saturate someones attention long before you
> run out of better things to teach.
>
>
> On Sun, Jun 3, 2018 at 11:29 AM, David Handy <david at handysoftware.com>
> wrote:
> > If you have two buckets, bucket A and bucket B, and you put a fish into
> bucket A, a fish does not magically appear in bucket B also.
> >
> >>>> bucket_a = []
> >>>> bucket_b = []
> >>>> bucket_a.append('fish')
> >>>> bucket_b
> > []
> >
> > But, if you have only one bucket with two labels on it, bucket A and
> bucket B, then when you use label A to put a fish into the bucket, and then
> use label B to look at the bucket, you will see that same fish.
> >
> >>>> bucket_a = []
> >>>> bucket_b = bucket_a
> >>>> bucket_a.append('fish')
> >>>> bucket_b
> > ['fish']
> >
> > This is a crucial conceptual understanding our students must gain or
> they will experience endless frustration trying to debug their programs,
> not understanding the behavior. Whether they use DreamWeaver or some other
> editor, this is relevant.
> >
> > David H
> >
> >
> > On Sunday, June 3, 2018 11:39am, "Carl Karsten" <carl at nextdayvideo.com>
> said:
> >
> >
> >
> >> That doesn't tell me how postit notes are different from buckets.
> >>
> >> I get the python side, I don't get how the analogies are different.
> >>
> >> I am also not sure the target audience comes to the conclusions about
> >> implementation you all seem worried about. Hmm, implementation may
> >> not be the right word, I think that's not abstract enough.
> >>
> >> If you are talking to a seasoned C programmer that understands what
> >> "int a" does, then sure, tell him how Python is different.
> >>
> >> If you are talking to someone who wants to use Dreamweaver to edit
> >> code, I am sceptical that spending time on this is a good idea.
> >>
> >> One of the biggest problems I have at Office Hours is spending so much
> >> time talking about tangents that we run out of time to finish the
> >> original topic. I somewhat expect that the tangents are equally
> >> helpful, so I am not too worried about it. But if you are working
> >> up a curriculum or lesson plan or whatever, I question what things
> >> should be included.
> >>
> >>
> >>
> >> On Sun, Jun 3, 2018 at 8:50 AM, Naomi Ceder <naomi.ceder at gmail.com>
> wrote:
> >> > As Kirby says, of course the data does go somewhere, and that
> "somewhere"
> >> > could be thought of as a container. But "creating" a variable name in
> Python
> >> > doesn't in itself create a container. A lot of beginners will assume
> that:
> >> > a = 1
> >> > a = b = c
> >> > will actually create three objects, (or containers, or buckets). This
> leads
> >> > to a flawed mental model of what Python actually does, with unexpected
> >> > results for mutable types.
> >> >
> >> > Cheers,
> >> > Naomi
> >> >
> >> > On Sun, 3 Jun 2018 at 13:56, Carl Karsten <carl at nextdayvideo.com>
> >> wrote:
> >> >>
> >> >> > But you are totally right, Kirby - we've got to get him off of this
> >> >> > notion of variables as containers. "Post-its, not buckets" is the
> >> way I put
> >> >> > it, but I rather like the luggage tag metaphor as well.
> >> >>
> >> >> You lost me here. What's wrong with bucket?
> >> >>
> >> >>
> >> >> On Sat, Jun 2, 2018 at 3:25 PM, Naomi Ceder <naomi.ceder at gmail.com>
> >> wrote:
> >> >> > It is a lovely article. Andrew Smith was at PyCon and I had dinner
> >> with
> >> >> > him
> >> >> > and Nicholas one evening and also sat down and chatted with Andrew
> >> on a
> >> >> > couple of other occasions.
> >> >> >
> >> >> > He's a smart guy and a likable one, and he is very taken with
> coding
> >> in
> >> >> > general, Python in particular, and especially the Python community,
> >> and
> >> >> > he
> >> >> > plans to keep going beyond just that article. I fully expect we'll
> >> see
> >> >> > and
> >> >> > hear more of Andrew Smith's adventures with Python over the coming
> >> year
> >> >> > or
> >> >> > two.
> >> >> >
> >> >> > But you are totally right, Kirby - we've got to get him off of this
> >> >> > notion
> >> >> > of variables as containers. "Post-its, not buckets" is the way I
> put
> >> it,
> >> >> > but
> >> >> > I rather like the luggage tag metaphor as well.
> >> >> >
> >> >> > And for those of us who are geeks "of a certain age" I can also
> >> >> > recommend
> >> >> > his book Moondust, which is the story of him tracking down and
> >> talking
> >> >> > to
> >> >> > all of the surviving Apollo astronauts in the early 2000's.
> >> >> >
> >> >> > Cheers,
> >> >> > Naomi
> >> >> >
> >> >> > On Sat, 2 Jun 2018 at 15:13, kirby urner
> >> <kirby.urner at gmail.com> wrote:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> One of my screen scraper friends (always reading) just forwarded
> >> this
> >> >> >> link:
> >> >> >>
> >> >> >> https://www.1843magazine.com/features/code-to-joy
> >> >> >>
> >> >> >> A highly literate middle aged writer tackles programming from
> >> zero and
> >> >> >> winds up in Python after a pilgrimmage through Javascript, and
> >> uses the
> >> >> >> Twitter API. He meditates on what learning to code might mean
> >> to a
> >> >> >> fully
> >> >> >> developed adult such as himself (connects to Andragogy **).
> >> >> >>
> >> >> >> Nicholas Tollervey, sometime edu-sig poster and Micro:bit
> >> avatar, is
> >> >> >> very
> >> >> >> much a hero in this story, living up to the ideal of a
> >> Pythonista as
> >> >> >>
> >> >> >> (A) not religiously dogmatic (re "language wars") yet
> >> >> >> (B) having enthusiasm for sharing Python (without too much
> >> >> >> proselytizing).
> >> >> >>
> >> >> >> Bravo on a stellar performance!
> >> >> >>
> >> >> >> Quincy Larson of freeCodeCamp fame is another champion of
> >> openness and
> >> >> >> accessibility (and good advice). I get his emails in my inbox
> >> with
> >> >> >> gratitude, though I don't follow all the links (helpfully
> >> labeled with
> >> >> >> estimated reading times, for my internal scheduler -- thanks for
> >> the
> >> >> >> meta-data!).
> >> >> >>
> >> >> >> In the interests of sparking some edu-sig type discussion (this
> >> could
> >> >> >> fork
> >> >> >> to a new thread), the author Andrew Smith writes:
> >> >> >>
> >> >> >> "Variables are best (if imperfectly) understood as the vessels
> >> within
> >> >> >> which pieces of data are contained, ready to be worked on. Of
> >> many
> >> >> >> possible
> >> >> >> data types, the most straightforward are numbers and strings,
> >> string
> >> >> >> being
> >> >> >> the name given to text."
> >> >> >>
> >> >> >> In my classes I readily acknowledge the "variable as container"
> >> >> >> metaphor
> >> >> >> is apt, and agree that Python objects take up memory and so
> >> object ==
> >> >> >> container (with id) is OK too.
> >> >> >>
> >> >> >> However, the name --> object mapping of a namespace is better
> >> imagined
> >> >> >> as
> >> >> >> "luggage tag -> suitcase" relationship. It's not like the
> >> Python name
> >> >> >> itself
> >> >> >> is the container on the heap.
> >> >> >>
> >> >> >> The object in memory is a possibly fat heavy suitcase, stuffed
> >> with
> >> >> >> stuff
> >> >> >> (e.g. an HttpResponse). However the name is more a label, like
> >> a
> >> >> >> luggage
> >> >> >> tag on a suitcase (and this is the point).
> >> >> >>
> >> >> >> Name : Object :: Luggage Tags :: Suitcase
> >> >> >>
> >> >> >> One suitcase (object) may have many names (connects to garbage
> >> >> >> collection
> >> >> >> discussion). However at any one moment, a name points to only
> >> one
> >> >> >> object
> >> >> >> (the same name in different modules, both running, still count
> >> as
> >> >> >> different
> >> >> >> names -- scope matters).
> >> >> >>
> >> >> >> So yeah, the object itself is a "container" but what it contains
> >> may be
> >> >> >> tags to other objects.
> >> >> >>
> >> >> >> Without this separation of "names" from "objects" there's an
> >> inevitable
> >> >> >> tendency to imagine copies, as how can we have two bowls or
> >> boxes with
> >> >> >> exactly the same content.
> >> >> >>
> >> >> >> We don't have a visual metaphor for "two suitcases containing
> >> exactly
> >> >> >> the
> >> >> >> same clothes at the same time".
> >> >> >>
> >> >> >> But we do understand "one suitcase having two or more luggage
> >> tags."
> >> >> >>
> >> >> >> Surely we have two copies, albeit clones of the same thing. Not
> >> so in
> >> >> >> Python though. Python is biased against making gratuitous
> >> copies of
> >> >> >> anything. Keep is spare! (sparse if possible). Don't clutter
> >> memory
> >> >> >> with
> >> >> >> excessive redundancy.
> >> >> >>
> >> >> >>
> >> >> >> Kirby
> >> >> >>
> >> >> >> **
> >> >> >> http://4dsolutions.net/presentations/pycon2013.pdf
> >> >> >>
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Edu-sig mailing list
> >> >> >> Edu-sig at python.org
> >> >> >> https://mail.python.org/mailman/listinfo/edu-sig
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Naomi Ceder
> >> >> >
> >> >> > @NaomiCeder • https://www.linkedin.com/in/naomiceder/
> >> >> > https://www.manning.com/books/the-quick-python-book-third-edition
> >> >> >
> >> >> > _______________________________________________
> >> >> > Edu-sig mailing list
> >> >> > Edu-sig at python.org
> >> >> > https://mail.python.org/mailman/listinfo/edu-sig
> >> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Naomi Ceder
> >> >
> >> > @NaomiCeder • https://www.linkedin.com/in/naomiceder/
> >> > https://www.manning.com/books/the-quick-python-book-third-edition
> >> _______________________________________________
> >> Edu-sig mailing list
> >> Edu-sig at python.org
> >> https://mail.python.org/mailman/listinfo/edu-sig
> >>
> >
> >
> >
> > _______________________________________________
> > Edu-sig mailing list
> > Edu-sig at python.org
> > https://mail.python.org/mailman/listinfo/edu-sig
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> https://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20180603/b7323a64/attachment-0001.html>