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 Resnickhttp://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 CUSEChttp://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
I don't know why programming is so hard, but it's a fascinating question. I blog on it regularly. I did blog on the Bret Victor video, too: Bret Victor's "Inventing on Principle," and the trade-off between usability and learninghttp://computinged.wordpress.com/2012/02/21/bret-victors-inventing-on-principle-and-the-trade-off-between-usability-and-learning/
Cheers, Mark
________________________________ From: squeakland-bounces@squeakland.org [squeakland-bounces@squeakland.org] on behalf of Steve Thomas [sthomas1@gosargon.com] Sent: Wednesday, February 29, 2012 4:35 AM To: squeakland; iaep Subject: [squeakland] Why Is programming an unnatural activity?
So I am sharing my blog post Why Is programming an unnatural activity?<UrlBlockedError.aspx>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/s2...]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 Resnickhttp://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 Principlehttp://vimeo.com/36579366 from CUSEChttp://vimeo.com/cusec on Vimeohttp://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 Resnickhttp://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
On Wed, Feb 29, 2012 at 10:35 AM, Steve Thomas sthomas1@gosargon.comwrote:
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:
- Parallelism Bugs
- Intentionality Bugs
- 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 Resnickhttp://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:
- Problem Decomposition Bugs
- Synchronization Bugs
- 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:
- 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
squeakland mailing list squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
Is it not that concise description or definition of any issue is hard.
Most stuff we think or say is quite general and has all sorts of context and preconsieved notion. Once we have to work out the details we run into problems and that is where the hard comes from.
Karl
On Wed, Feb 29, 2012 at 7:36 PM, karl ramberg karlramberg@gmail.com wrote:
Is it not that concise description or definition of any issue is hard.
Most stuff we think or say is quite general and has all sorts of context and preconsieved notion. Once we have to work out the details we run into problems and that is where the hard comes from.
Karl,
Can you explain in more detail what you mean? If I understand you correctly, I would say its not that the concise description or definition is hard, but getting there is and so is getting a full understanding and the implications of those descriptions and definitions.
I have read many a concise definition, that I found hard to understand, because the road the expert took to get there and all that they forgot is hidden and I have not yet traveled and learned from the road they traveled.
Stephen
On Wed, Feb 29, 2012 at 7:36 PM, karl ramberg wrote:
Is it not that concise description or definition of any issue is hard.
Most stuff we think or say is quite general and has all sorts of context and preconsieved notion. Once we have to work out the details we run into problems and that is where the hard comes from.
That makes sense to me. In a similar way, it is hard for parliaments and appeals courts to draft new laws, and, I imagine it is hard to write diagnostic manuals (for physicians).
Yet such things are applied by people: they can fall back on the discretion and good intentions of the doctor, official or judge that applies them. Machines have no such intentions or discretion, which probably makes programming even harder.
Have fun! David
squeakland@lists.squeakfoundation.org