> For everyone who was interviewing for a programming job, we had to take a 
> test that involved debugging simplistic state machines.

I did something similar:

I observed that some patterns of rational strategies were employed by novices 
when responding to a programming question at a very early stage of learning to 
program. Each rationale was recognisable and similar to the mechanisms actually 
used in program execution although not precisely addressing the correct answer. 
For example, the mechanism of assigning the value of a variable from left to 
right is very similar to assigning it from right to left, but only the second 
is the correct model of Java execution.

I designed a test that apparently examined a student's knowledge of assignment 
and sequence before a first course in programming but in fact it was designed 
to capture their reasoning strategies. An experiment found two distinct 
populations of students: one could build and consistently apply a mental model 
of program execution; the other appeared either unable to build a model or to 
apply one consistently. The first group performed very much better in their 
end-of-course examination than the second in terms of success or failure. The 
test does not very accurately predict levels of performance, but by combining 
the result of six replications of the experiment, five in UK and one in 
Australia, I show that consistency does have a strong effect on success in 
early learning to program but background programming experience, on the other 
hand, has little or no effect. 

Our papers and test materials can be downloaded from the link below: 
http://www.cs.mdx.ac.uk/research/PhDArea/saeed/ 
<http://www.cs.mdx.ac.uk/research/PhDArea/saeed/> 

 

Regards,

Saeed Dehnadi

        -----Original Message----- 
        From: John Daughtry [mailto:j...@daughtryhome.com] 
        Sent: Fri 27/11/2009 14:07 
        To: Walter Milner 
        Cc: Ppig-Discuss-List 
        Subject: Re: "Intuitiveness" of programming languages/paradigms
        
        

        That is an interesting approach Walter.

        This reminded me of an interview I had back in 2006 with ThoughtWorks. 
For everyone who was interviewing for a programming job, we had to take a test 
that involved debugging simplistic state machines. I have no idea what that 
test was named, or where it came from, but it was a really neat test. Has 
anyone heard of such a test? The way it was constructed leads me to believe 
that there was some thought going into exactly what it was testing. And, my 
guess is that whoever constructed it had some experience with creating 
psychological instruments and knew exactly what they were going for. It seemed 
to me that it was geared towards measuring someone's ability to think through 
states. It also presumed no prior knowledge of state machines, although having 
such knowledge would probably help. 

        John Daughtry
        
---------------------------------------------------------------------------------
        Associate Research Engineer, Applied Research Laboratory
        Penn State University




        On Fri, Nov 27, 2009 at 3:48 AM, Walter Milner <w.w.mil...@bham.ac.uk> 
wrote:
        

                "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:o...@cs.otago.ac.nz]
                
                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?
                >
                
                
                
                


Reply via email to