squeakland March 2012

squeakland@lists.squeakfoundation.org

16 participants
27 discussions

Why Is programming an unnatural activity?
by Steve Thomas 02 Mar '12

02 Mar '12

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/s…> 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=0CCkQtwI…>

4 4

Re: [squeakland] magic tank storybook translation
by Carlos Rabassa 02 Mar '12

02 Mar '12

Great unplanned international team work Pato! Thanks! Carlos On Mar 1, 2012, at 8:45 PM, Pato Acevedo wrote: > Hi: > > Here is the book with the translation into Spanish of Carlos. > > Pato > > > From: carnen(a)mac.com > > Date: Thu, 1 Mar 2012 16:49:23 -0200 > > To: squeakland(a)squeakland.org > > Subject: Re: [squeakland] magic tank storybook translation > > > > Tim, > > > > Great book! Congratulations Brady, Isabel and all! It´s almost 3 years since we last saw Isabel. > > > > I don´t have the time now to put the translation into the book but here are the words: > > > > > > Page 1/7 > > > > Había una vez un niño llamado Brady y una niña llamada Isabel. Les gustaba mucho conducir su tanque mágico. > > > > Page 2/7 > > > > Después de un tiempo, Brady e Isabel se aburrieron. > > > > Deseaban ir a la gran ciudad. > > > > Page 3/7 > > > > Pero antes de la ciudad, tenían que escalar una gran montaña. > > > > Page 4/7 > > > > ¡Qué sorpresa! ¡Su tanque también era un submarino! > > > > Page 5/7 > > > > Después de un rato, ¡vieron una gran ciudad submarina! > > > > Page 6/7 > > > > ¡Era Atlantis, la ciudad perdida! ¡Brady e Isabel hicieron historia! > > > > Page 7/7 > > > > Fin > > > > Carlos > > > > > > > > > > > On Mar 1, 2012, at 12:11 AM, Timothy Falconer wrote: > > > > > >> Hi everyone, > > >> > > >> http://squeakland.org/showcase/project.jsp?id=11786 > > >> > > >> Just posted an Etoys storybook that I attempted to translate from English into Portuguese, Spanish, German, and French with Google. > > >> Please let me know if Google's translations are off so I can correct them. Also, please comment if you like it so the authors may hear from the world. > > _______________________________________________ > > squeakland mailing list > > squeakland(a)squeakland.org > > http://lists.squeakland.org/mailman/listinfo/squeakland > <magicTank.008.pr>

1 0

Re: [squeakland] magic tank storybook translation
by Carlos Rabassa 01 Mar '12

01 Mar '12

Tim, Great book! Congratulations Brady, Isabel and all! It´s almost 3 years since we last saw Isabel. I don´t have the time now to put the translation into the book but here are the words: Page 1/7 Había una vez un niño llamado Brady y una niña llamada Isabel. Les gustaba mucho conducir su tanque mágico. Page 2/7 Después de un tiempo, Brady e Isabel se aburrieron. Deseaban ir a la gran ciudad. Page 3/7 Pero antes de la ciudad, tenían que escalar una gran montaña. Page 4/7 ¡Qué sorpresa! ¡Su tanque también era un submarino! Page 5/7 Después de un rato, ¡vieron una gran ciudad submarina! Page 6/7 ¡Era Atlantis, la ciudad perdida! ¡Brady e Isabel hicieron historia! Page 7/7 Fin Carlos > On Mar 1, 2012, at 12:11 AM, Timothy Falconer wrote: > >> Hi everyone, >> >> http://squeakland.org/showcase/project.jsp?id=11786 >> >> Just posted an Etoys storybook that I attempted to translate from English into Portuguese, Spanish, German, and French with Google. >> Please let me know if Google's translations are off so I can correct them. Also, please comment if you like it so the authors may hear from the world.

1 0

Re: [squeakland] Portuguese translation of magic tank
by Timothy Falconer 01 Mar '12

01 Mar '12

Thank you Luis! And thanks for the other nice comments by people. I've updated the Portuguese. Let me know if it's better now. http://squeakland.org/showcase/project.jsp?id=11786 Also, I was wondering, is it okay to simply copy the Portuguese to both the "Portuguese" and "Portuguese Brazil"? Having both is cumbersome from a translators point of view, just wondering if the two are often different. Take care, Tim On Feb 29, 2012, at 6:52 PM, Luis Valente wrote: > Hi, Timothy > As I promissed there you are the portuguese translation of the project "Magic Tank". > Good work. Cheers. > > #1 > > Era uma vez um rapazinho chamado Brady e uma menina de nome Isabel que adoravam conduzir o seu tanque mágico. > > #2 > > Após algum tempo, Brady e Isabel aborreceram-se. > > Queriam ir para a grande cidade. > > #3 > > Mas, antes de chegarem à grande cidade, tinham que subir uma grande montanha. > > #4 > > Uau, que surpresa! O seu tanque também era um submarino! > > #5 > > Algum tempo mais tarde, avistaram uma grande cidade subaquática! > > #6 > > Era a cidade perdida de Atlântida! Brady e Isabel fizeram história! > > > -- > All the best, > Luís Valente > www.valente.org.pt >

2 1

magic tank storybook translation
by Timothy Falconer 01 Mar '12

01 Mar '12

Hi everyone, http://squeakland.org/showcase/project.jsp?id=11786 Just posted an Etoys storybook that I attempted to translate from English into Portuguese, Spanish, German, and French with Google. Please let me know if Google's translations are off so I can correct them. Also, please comment if you like it so the authors may hear from the world. -- Apenas publicou um livro de histórias Etoys que eu tentei traduzir do Inglês para o Português, espanhol, alemão e francês com o Google. Por favor, deixe-me saber se as traduções do Google estão fora para que eu possa corrigi-los. Além disso, por favor, comente se você gostar dele de modo que os autores podem ouvir o mundo. -- Acaba de publicar un libro de cuentos Etoys que he tratado de traducir del Inglés al portugués, español, alemán y francés con Google. Por favor, hágamelo saber si las traducciones de Google están fuera para que pueda corregirlos. También, por favor comente si le gusta lo que los autores pueden saber de todo el mundo. -- So erzielte ein Etoys Märchenbuch, dass ich aus dem Englischen ins Portugiesisch, Spanisch, Deutsch und Französisch mit Google übersetzen versuchte. Bitte lassen Sie mich wissen, wenn die Google-Übersetzungen aus sind, damit ich sie korrigieren kann. Auch, bitte kommentieren, wenn Sie es so die Autoren aus der ganzen Welt hören mögen können. -- Juste un livre de contes posté Etoys que j'ai tenté de traduire de l'anglais vers le portugais, espagnol, allemand, et français avec Google. S'il vous plaît laissez-moi savoir si les traductions de Google sont éteints pour que je puisse les corriger. En outre, s'il vous plaît commentaire si vous le souhaitez afin que les auteurs peuvent entendre le monde.

2 1

Re: [squeakland] [IAEP] Why Is programming an unnatural activity?
by Steve Thomas 01 Mar '12

01 Mar '12

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

1 0

Re: [squeakland] [IAEP] Why Is programming an unnatural activity?
by Steve Thomas 01 Mar '12

01 Mar '12

On Wed, Feb 29, 2012 at 1:29 PM, Yamaplos . <yamaplos(a)gmail.com> wrote: > 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-ac… Thanks for the correction. 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. > I actually regret using the word "unnatural" and would now switch to "hard" (although I still agree it is "unnatural" or non-universal) > 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. > Well I would be careful in saying "some people can and others can't" and that some are "naturals." I agree and have no problem saying we are not all born or created equal as far as intelligence, size or looks are concerned (I got more than my fair share of good looks, ego and bad eyesight ;) Yet, I come from the point of view that if kids don't get it it's my fault, not the kids, perhaps not totally realistic, but it pushes me to do better and that really is all I have control over. Also, I would ask what is it about the way we teach programming and (I think perhaps more importantly) the languages (programming and the words we use and think with) and problems we use to teach, that allows certain kids to "get it" and others not? For example as shown by Etoys and Scratch, parallel programming is actually easier (unless perhaps if you start with the sequential view and get trapped in thinking in that paradigm and are asked to do concurrency with Pthreads) Another thing that comes to mind is that all my kids can sing, yet neither my wife nor I have would every be asked to sing (more likely we would be asked to stop). Perhaps they got a lucky draw, but I think more likely it is the music exposure we were fortunate enough to be able to give them and the great teachers and programs we found. I think we need different types of programs for teaching "programming" as well, to appeal to more kids and allow them opportunity to be as successful as they are capable of becoming. 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. > Thank you please share what you learn. 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. > Well you could spend time trying to figure out how to "beat socioeconomics" and as my Great Aunt Suslie used to say "I wish you lots of luck," or simply do what you can to leave the world a bit better wherever you are :) Stephen > > 2012/2/29, Steve Thomas <sthomas1(a)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/s… > > > > 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=0CCkQtwI… > > > > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

squeakland March 2012