[IAEP] Why Is programming an unnatural activity?

[Steve Thomas]

On Wed, Feb 29, 2012 at 3:30 PM, Christopher Lindgren <
Chris.Lindgren at my.ndsu.edu> wrote:

> While some may have an affinity for programming languages, as they are,
> I'm not so sure that programming should be constructed upon a binary of
> natural/unnatural. This binary limits the potential for creating other
> identities around the scope of who and what a programmer should be, do,
> examine, and create.
>
Agreed and "hard" would have been a better word.

Literacy acquisition is far more complex than naturalness to the medium of
> any structured/unstructured language, and Miriam Posner just posted on some
> of those constructions that consequently produce such social
> stratification: http://miriamposner.com/blog/?p=1135
>
> I feel as though that this response may come across as being cross, but I
> just hope to challenge the construction of what constitutes a "natural"
> ability within any discipline, as I am currently dealing with such issues
> in Composition Studies/Critical Code Studies.
>
No offense taken or perceived "crossness"  in any of the emails in this
chain.

>
> Honestly, I would just like to see such social complexities taken more
> into account with projects such as OLPC/Sugar, etc., and I hope that said
> projects could be a catalyst for displaying and responding to the social
> nature of developing smarter computing cultures, rather than keeping both
> eyes too deep in the code.
>
Agreed.  That is the one areas where I believe the Scratch Web Site has
been really successful and we can learn a lot.  We really need a web site
for kids to share what they create, re-mix and interact.  That is a big
missing I hope to be able to help address some time this year (volunteer
programmers welcome!!!)

Thanks,
Stephen

>
>
>
> Chris Lindgren
> Graduate Instructor
> Department of English, Rm 217
> North Dakota State University
> Fargo, ND 58105
> www.clindgrencv.com
>
> Research Assistant
> Sugar Labs @ NDSU | fargoxo.wordpress.com
>
> ________________________________________
> From: iaep-bounces at lists.sugarlabs.org [iaep-bounces at lists.sugarlabs.org]
> on behalf of Yamaplos . [yamaplos at gmail.com]
> Sent: Wednesday, February 29, 2012 10:29 AM
> To: Steve Thomas
> Cc: iaep; squeakland
> Subject: Re: [IAEP] Why Is programming an unnatural activity?
>
> Steve,
>
> for some reason the link to your blog didn't work for me. JIC others
> needed it, here:
>
> http://mrstevesscience.blogspot.com/2012/02/why-is-programming-unnatural-activity.html
>
> Brilliant!
> I really appreciate you pointing out these great ideas to the rest of us.
>
> For many years I have struggled on trying to understand what makes it
> so that some people can and others can't. My conclusion is still that
> it is clearly a "gifting", part of the uniqueness every living being
> is created with. Some are "natural" programmers, others aren't. The
> latter being the majority by far, ergo, as a general thing
> "programming is unnatural", end of story.
> Ideologically this is very inconvenient, of course, since it is quite
> unfashionable, nay, *very* inappropriate, political incorrect to point
> at differences in potential from conception, but, no longer being
> constrained by ideology, I can afford to call it as it is.
>
> This still leaves me with trying to figure out who it  makes sense to
> invest in. And apparently more difficult, how best to "seed" that
> process, and overcome "blocks" (in some way what your authors call
> "bugs"), some of these set there by the kindness of the official
> one-size-fits-all education experts. Your notes and the authors you
> point out will help learn and understand how this all happens, thank
> you.
>
> Of course, even then we are left with trying to figure out how to beat
> socioeconomics, like this kid in a Nepal school I met, that will have
> extra struggles to go through to achieve his potential.
>
> 2012/2/29, Steve Thomas <sthomas1 at gosargon.com>:
> > So I am sharing my blog post Why Is programming an unnatural
> activity?Hoping
> > to get some feedback from the community.
> >
> > For my P2PU course I have been looking at "Novice" programmers.  And in
> one
> > of the papers we were asked to read Mark Guzdial asks:
> >
> > “Why?” Is programming an unnatural activity?
> >
> > Could programming be made easier in a different form?
> >
> > Could programming be taught in a different way that makes learning
> easier?
> >
> > Or maybe we just have no idea how to actually measure what students know
> > about programming.* (1).*
> >
> > My main problem with the Guzdial paper (this was more my problem than a
> > problem with the paper) is I felt it didn't provide enough details or
> > specifics on "Why it is so hard to learn to Program?"  I need specifics
> and
> > examples to get my head around things.  Roy Pea, was a great find and
> > perhaps not surprisingly (for me at least) the Resnick article was very
> > useful.
> >
> > Pea (et al) talked about three classes of bugs:
> >
> >    1. Parallelism Bugs
> >    2. Intentionality Bugs
> >    3. Egocentrism Bugs
> >
> > *Parrallelism Bugs*
> > The Parallelism Bugs, is basically an "assumption of different lines in a
> > program can be active or known by the computer at the same time or
> > in parallel".  For example, look at this code:
> >
> >
> > If (Size == 10)
> >     print "Hello"
> > For Size in range(10):
> >     print Size
> >
> > When High School students. in their second year of programming course,
> were
> > asked what they thought the program would print 8 out of 15 predicted
> > "Hello" would print after "10".
> >
> > *Intentionality Bugs*
> > The Intentionality Bugs, is the idea in the child's mind that "the
> program
> > has goals and knows or sees what will happen elsewhere in itself."
> >
> > *Egocentrism Bugs*
> > The Egocentrism Bugs, stem from the belief that there "is more of their
> > meaning for what they want to accomplish in the program than is actually
> > present in the code."  Funny, I see these kinds of bugs all the time in
> my
> > code and those of other experience programmers :)
> >
> > *The Super Bug*
> > He concludes that all these derive from the Super Bug:
> >
> > <
> http://4.bp.blogspot.com/-sQRGOhtVBbM/T03XIvqxgvI/AAAAAAAABBg/itlJA6dtKhU/s1600/SuperBug%0D.png
> >
> > The idea that there is a "hidden mind somewhere inside the programming
> > language that has intelligent and interpretive powers."  Not surprising
> > since most of kids experiences are with semi-intelligent beings (aka
> > Parents)
> >
> > MultiLogo: A Study of Children and Concurrent Programming - Mitchel
> > Resnick<http://llk.media.mit.edu/papers/MultiLogo.html>
> > Resnick, noted that:
> >
> > "This sequential paradigm does not match the way the real world works:
> > people and animals act in parallel, objects interact in parallel. As a
> > result, many real-world activities can not be modelled in a natural way
> > with sequential programming."
> >
> > Thus developed a concurrent or parrallel version of Logo (Multi-Logo), so
> > they kids had a language/environment that more closely matched their view
> > of the world.  Although he did not go "parrallel" enough, and in his
> > lessons learned asked "
> >
> > *SideNote*: I used to think and say that Concurrent Programming was
> really
> > really hard.  I had plenty of evidence to back this up and had heard and
> > read much smarter people than me saying the same thing.  Then I
> encountered
> > Etoys (and later Scratch) and started teaching these to kids.  And
> realized
> > that Concurrent Programming is actually easier (although you do have the
> > added complexity of syntonization issues) .  The problem was not the
> > topic/idea, it was the language we use to think about it.
> >
> > Resnick noted that "In general, students appropriated the idea of agents
> > sending messages to one another quite easily."  Too bad we don't teach
> more
> > Smalltalk.
> > He identified three types of bugs specific to concurrent programming:
> >
> >    1. Problem Decomposition Bugs
> >    2. Synchronization Bugs
> >    3. Object Oriented Bugs
> >
> > *Problem Decomposition Bugs*
> > "These bugs arise out of students' difficulties decomposing problems into
> > actions to be performed concurrently by multiple agents."  Here there are
> > two types of decomposition:
> >
> >    1. functional decomposition - dividing a problem in to simpler
> >    sub-problems (what needs to be done)
> >    2. agency decomposition - dividing the functional pieces among
> different
> >    agents (who does it)
> >
> >
> > *Synchronization Bugs*
> >
> > "These bugs arise out of students' difficulties coordinating and
> > orchestrating the activities of multiple agents."
> > These bugs he divides into two type: Unintended Sequentiality and
> > Unintended Concurrency. In these cases the student expected Sequetiality
> > and got Concurrence (or vice versa).
> >
> > It seems that in designing Multi-Logo to deal with synchronization he
> > provided two mechanisms: ask and demand.  Where when you "ask" an agent
> > something (ex: flash light -  for 20 seconds) the request is queued up to
> > be executed in the order received. When you "demand" the agent interrupts
> > what is going on to perform the request (or it might simply put it at the
> > head of the queue, I am not sure).  It is interesting, at least to me,
> that
> > Scratch, developed later by Resnick and his team,  got rid of the ask and
> > demand and went with a "broadcast" "wait" and "do for X seconds" to allow
> > for synchronization.  I believe this simplifies and avoids a number of
> > problems for novice programmers.
> >
> > *Object Oriented Bugs*
> > "These bugs arise out of students' confusion among different types of
> > "objects"  Multi-Logo has multiple types of objects: agents, turtle, and
> on
> > the Lego Interface box (think early NXT) ports and sensors.  Part of this
> > confusion may have been the overloading of "halt" which for an agent,
> > Another quote for Guzial:
> >
> >    - " our current programming languages do not allow people to program
> the
> >    way that they think about the tasks"
> >    - Section: "Making tools better by shifting to Visual Programming"
> >    - "having students build their own visualizations had significant
> impact
> >    on those students’ learning."
> >
> >
> > *Resnick's Lessons Learned*
> > "It is a good idea for students to "play agent"--that is, act out what
> each
> > agent is supposed to do. This activity requires a group of students, each
> > playing the role of a different agent."  I really like this approach with
> > novices and often warn students "Step away from the computer and no one
> > will get hurt".  Having them act out the program and program each other
> is
> > a good way to do this.
> > In designing Multi-Logo he realized he did not go far enough
> > in parallelism: "An alternate approach, of course, is to change the
> design
> > of MultiLogo to match students' preconceptions. For example, I could
> > redesign MultiLogo agents so that each agent could do several things at
> the
> > same time, in line with students' expectations of "excessive
> parallelism."
> >  He later did have agents that can do several things at the same time.
> > He also discussed the idea of design the environment match the students
> > pre-conceptions. Would be interesting to find out what problems it solves
> > (and those it doesn't) and what new problems it creates.
> >
> >
> > FInally, for a real treat* *at some possibilities for a new programming
> > environment see this:
> >
> > Bret Victor - Inventing on Principle <http://vimeo.com/36579366> from
> > CUSEC<http://vimeo.com/cusec>
> >  on Vimeo <http://vimeo.com/>.
> >
> > References:
> > NOTE: If you have limited time, I would recommend reading (2) then (5),
> > then for a real treat watch the Brett Victor talk (7)
> > (1) Why Is It So Hard to Learn to Program - Mark Guzdial
> > (2) Children's Mental Models of Recursive LOGO Programs - D. Midian
> Kurland
> > and Roy D. Pea
> > (1985)<
> http://www.stanford.edu/~roypea/RoyPDF%20folder/A27_Kurland_Pea_85.pdf>
> > (3) Language Independent Conceptual "Bugs" in Novice Programming - Roy D.
> > Pea (1986) <
> http://www.stanford.edu/~roypea/RoyPDF%20folder/A28_Pea_86.pdf>
> > (4) The Buggy Path to the Development of Programming Expertise - Roy D.
> Pea
> > and Elliot Soloway
> > (1987)<
> http://www.stanford.edu/~roypea/RoyPDF%20folder/A32_Pea_etal_87.pdf>
> > (5) MultiLogo: A Study of Children and Concurrent Programming - Mitchel
> > Resnick <http://llk.media.mit.edu/papers/MultiLogo.html> (1990)
> > (6) Programming Environments for Novices - Mark Guzdial
> > (2002)<http://coweb.cc.gatech.edu/guzdial/uploads/18/novice-envs.pdf>
> > (7) Brett Victor - Inventing on Principle
> > (2012)<
> http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCkQtwIwAA&url=http%3A%2F%2Fvimeo.com%2F36579366&ei=KsZNT67SJ4GCgwf1-Lm_Ag&usg=AFQjCNGHACfYpq0IFm1Krb2xBGWAF-_JLw&sig2=eGsjoGhKYkMHkr4HmZLCyw
> >
> >
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20120229/8dd1f8dc/attachment-0001.html>