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