"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