[Edu-sig] Visual Programming in Python?

[dblank at brynmawr.edu]

[I've rearranged and selected some of Kirby's comments to facilitate my
comments. The full post is below.]

Kirby said:

> Just thinking out loud here.  One of our Shuttleworth Summit attenders
> was going back to Cape Town with Imagine Logo, a somewhat expensive
> commercial Logo aimed at the kid market (I guess that's redundant:
> Logo is by definition aimed at kids, no?).

I'd like to first point out that Logo is not used by just kids for just
playing around. We use NetLogo in a few of the college courses that I
teach to do serious playing around. NetLogo is great, and has some things
that I wish Python had. NetLogo is not a visual programming environment,
but has a drag-n-drop work area for adding inputs (buttons, sliders) and
outputs (graphs). A very nice tool indeed.

> But this brings up an interesting point:  should we try to assemble
> Pythonic tools that go into graphical hand-holding down to such a
> level, e.g. for very young children?
>
> Alan Kay strongly believes a young child shouldn't have to type to
> experience programming, i.e. some kind of drag and drop or other
> non-typing interface should facilitate programming.
>
> I have no problem with that if (a) we accept that typing will become
> important later and (b) don't insist that core Python has any
> responsibility to pander to non-typers.
>
> I do agree with Arthur that Python shouldn't pander.  It was
> originally designed as a kind of teaching language, user friendly for
> newbies, but not newbie children, rather newbie adults with a
> professional need to program for some reason (e.g. telescopy experts,
> biologists, chemists or whathaveyou).  That's the heritage and I don't
> see any reason to pretend otherwise.  Python was never premised on
> being "kid friendly" in the way Squeak was.

I am not interested in any pandering, but I am interested in lowering the
bar so that non-programmers can explore areas that have been outside of
their capabilities. The problem, as I see it, is that it is hard for me to
span Logo to Python. It is not that the students I want to entice can't
type, but they don't have any experience in traditional programming. These
are students from pyschology, economics, biology, english, archaeology,
etc.

I've described Python as a Pedagogically Scalable Framework (e.g., as the
students gain in experience, Python has new abilities waiting for them).
So, rather than require students to create a class to write Hello World,
students can first just print it, then learn about functions, then about
classes---building on what they already know as they go.

Adding a graphical, visual programming tool to the toolbox could help
extend the reach of Python to all kinds of non-traditional would-be
programmers.

> I keep coming back to the notion that heterogeny is a good thing.

Yes, of course. But I also see the advantage of having Python have a broad
scope. I don't think anyone thinks that homogeneity is good, and yet Java
has emerged as the single language for which one can take the AP computer
science test. That surely has done more harm than good in CS.

> One exercise we did at this Shuttleworth Summit was stand on a line
> according to how much we agreed with the statement:  if we *could*
> implement a 10 year long curriculum around one language only, we
> should, at least for testing purposes, i.e. to see how well it worked.

I would probably agree with a slightly different statement: if we could
implement a 10 year long focus on a single language for use in CS1 and AP
testing, should we, to see how well it worked? There is no reason not to
(and many reason we should) introduce other languages in the curriculum,
but why not come together on a better intro language? I think it is
happening, and Python is it.

In any event, I am leaning towards the notion that having a visualization
tool for seeing and creating Python's flow, objects, events, and
interactions would be worth the effort. But only if it was a 1-to-1 match,
with round-trip conversions.

-Doug

>> Very good point.  The way I see it would be that this would be a
>> tool to teach beginners about control statements and program
>> flow *for relatively simple programs*. Something like a "guess
>> the number" or your the word substitution program (mad lib?)
>> that you talked about previously.  The idea is to have something
>> complementary to other tools (like turtle graphics, etc.).
>> At least, that's _my_ take on it :-)
>>
>> André
>
> Yes, that's a reasonable interpretation.  But from my point of view
> it'd be overkill.  A few diagrams of the traditional flowchart type
> should get the point across, then move into nongraphical coding.
>
> But this brings up an interesting point:  should we try to assemble
> Pythonic tools that go into graphical hand-holding down to such a
> level, e.g. for very young children?
>
> Alan Kay strongly believes a young child shouldn't have to type to
> experience programming, i.e. some kind of drag and drop or other
> non-typing interface should facilitate programming.
>
> I have no problem with that if (a) we accept that typing will become
> important later and (b) don't insist that core Python has any
> responsibility to pander to non-typers.
>
> I do agree with Arthur that Python shouldn't pander.  It was
> originally designed as a kind of teaching language, user friendly for
> newbies, but not newbie children, rather newbie adults with a
> professional need to program for some reason (e.g. telescopy experts,
> biologists, chemists or whathaveyou).  That's the heritage and I don't
> see any reason to pretend otherwise.  Python was never premised on
> being "kid friendly" in the way Squeak was.
>
> So if other environments e.g. Squeak or Lego Mindstorms, already have
> ways to accomplish this "almost no typing goal" is there any reason to
> commit the resources of the Python community in this direction?  In
> other words, is there any reason to try pushing "snake language" into
> this ecological niche, and in what sense would it even be ostensibly
> Python any more, if we did?  If it's just the implementation language,
> then it'd be somewhat hidden -- so then why not use something faster?
>
> I keep coming back to the notion that heterogeny is a good thing.
>
> One exercise we did at this Shuttleworth Summit was stand on a line
> according to how much we agreed with the statement:  if we *could*
> implement a 10 year long curriculum around one language only, we
> should, at least for testing purposes, i.e. to see how well it worked.
>
> I stood fairly far at the other end as I recall (disagreeing with the
> statement):  it's a curriculum *goal* to not get mired in one and only
> one language.  We *want* diversity and making Python do the whole
> thing would be a bad idea in principle.
>
> But that's NOT to say we shouldn't have turtles, robots or other
> kid-friendly stuff in Python.  It's more to say that it's being
> implemented in Python is not the chief advantageous feature (as if we
> expect kids that age to dig into the source code).  The pedagogical
> advantages should be around the quality of the lessons and
> experiences, regardless of the implementation language, no?
>
> That being said, if one turtle or robot environment is free and open
> source, while another is closed source, proprietary, and possibly
> expensive, that *is* a feature to advertise as advantageous.  However,
> Pythonic products needn't be free or open source, we already know.
> Pythonic is not synonymous with FOSS, even if the language itself is
> FOSS.
>
> Just thinking out loud here.  One of our Shuttleworth Summit attenders
> was going back to Cape Town with Imagine Logo, a somewhat expensive
> commercial Logo aimed at the kid market (I guess that's redundant:
> Logo is by definition aimed at kids, no?).
>
> If we're to support the tentative Shuttleworth approach of using Logo
> with the youngest kids (then Squeak, then Python), we'd need something
> free and open source, and probably cross platform.  There's no budget
> for expensive software in this picture.
>
> We need to start assembling candidate packages that'd run in a Tux Lab
> on Edubuntu I guess.  What Logos?  Squeak already works.  Do we need
> to include wx in that distro?  Is it included already?  How about
> VPython (required for Pygeo, among other packages).
>
> I'll have to poke around more when I get back to Portland, where Derek
> has it installed in his test bed.
>
> Kirby
> in London
>
> PS:  hope OK I'm replying to the list; your previous came to me only
> but doesn't appear confidential in any way.
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>