"So if, for example, you "get" variables-and-assignments easily, that makes it more likely that you will "get" Java 'for' loops, and that makes it more likely that you will "get" how to work with arrays.
So what makes it easier for someone to "get" variables-and-assignments?" My suggestion is that what underlies those 'gets' is the notion of machine state, and the fact that program code affects machine state, and that state affects what program statements do. Put most simply, variable values change as execution proceeds, and you have to track those variable values to see what a program will do. That's pretty obvious to us, but I suspect its rarely taught explicitly. Its obvious to some students - those in the top hump of the bi-modal distribution - and not obvious to the lower hump. Those in the lower hump think you can decide what code will do by simply considering the code, as text, alone. In the case of OO, state is localised from machine global to object-specific. Students who are not happy with global state find the idea of class/object very difficult. I think the cognitive basis for this is the existence of 3 mental spaces - program text, machine state and IO space. A novice has to construct frames to structure these, and establish a blend. I use mental space, frame and blend in the sense of Fauconnier and Turner. Yes, this is my PhD. This is a long way from the OP of the intuitiveness of imperative languages. I suspect this is a cover for the adolescent debate of 'my programming language is better than yours'. -----Original Message----- From: Richard O'Keefe [mailto:[email protected]] Sent: Fri 27/11/2009 00:26 To: Alan Blackwell Cc: Ppig-Discuss-List Subject: Re: "Intuitiveness" of programming languages/paradigms On Nov 27, 2009, at 12:19 AM, Alan Blackwell wrote: > > So to summarise this whole discussion, based on text of your > previous message, it seems that you would like to know what > aspect of computer programming is, or ever could be "automatic, > without requiring conscious thought ... or rational processes" > > Is that right? Sort of. People presumably don't take CS1 papers unless they think they might do well, yet CS1 papers notoriously have a very high failure rate. Clearly programming _isn't_ intuitive for most people, but people who are _now_ programmers often feel strongly that it is. Why? Is there something we can use to reduce the CS1 failure rate? Anthony Robins http://www.cs.otago.ac.nz/department/staff.php?name=Anthony%20Robins recently noticed http://www.cs.otago.ac.nz/staffpriv/anthony/publications/pdfs/RobinsLEM.pdf that the characteristic bimodal distribution of outcomes in CS1 can be explained by a very simple statistical model. (Roughly speaking: a series of topics where failure at any point makes later failure more likely, success makes later success more likely.) So if, for example, you "get" variables-and-assignments easily, that makes it more likely that you will "get" Java 'for' loops, and that makes it more likely that you will "get" how to work with arrays. So what makes it easier for someone to "get" variables-and-assignments? I've mentioned trying to teach surveying students a bit about Visual Basic, and I originally thought "this won't be too bad, because they ALREADY know about boxes that can hold numbers, and can hold different numbers at different times. In fact they already know about giving a name to a box, this is something Excel lets you do, and you can use a name in a formula. Since they already know formulas, named boxes, and changing what's in a box, all I really need to get across is comments, loops, and user-defined functions." Wrong. I still think that spreadsheets *ought* to make programming more "intuitive", but I'm not seeing much evidence of it. While Excel lets you bind a name to a cell, this is not something students have ever actually done. There IS some transfer from the idea of "cell coordinates edit" to "memory element address address" so I think they're "getting" some of that. > > The result found more often than any other is that the need to > use recursion as a control strategy is the greatest single > obstacle to the practical use of most popular declarative > languages. The most popular declarative language is SQL. Perhaps the fact that it doesn't use recursion may be a factor in its success? Haskell experts advocate a higher-level style where most of your code is free of explicit loops, not completely unlike using LINQ. Is the "intuitiveness" of recursion something we can CHANGE by providing the right experiences? > As far as I remember, Shaaron Ainsworth and > Judith Good both made some progress on that in their respective > PhDs. I've just spent the last 40 minutes searching, with no success. Do you know of links to those theses? >
