On Wed, Feb 29, 2012 at 3:30 PM, Christopher Lindgren < [email protected]> 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: [email protected] [[email protected]] > on behalf of Yamaplos . [[email protected]] > 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 <[email protected]>: > > 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!) > [email protected] > http://lists.sugarlabs.org/listinfo/iaep > >
_______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
