“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).
- Parallelism Bugs
- Intentionality Bugs
- Egocentrism 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".
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."
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
"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."
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.
- 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)
- agency decomposition - dividing the functional pieces among different agents (who does it)
"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,
- " 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."