Do Python and Java lead students to construct different mental models of memory?

Question

How are novices' mental models of variable storage affected by programming language choices? Most Intro to CS teachers (I think) do not delve with breadth and depth into details of how variable names are tied to data and datatype. As a result, some students create pieces of their own mental model of how the computer is storing these variable names, data, and data type.

What mental models of memory storage in general (and for sequences in particular) are typical in students who learn Python first vs. students who learn another language first- one that treats arrays more like C does?

Background

Several single-university studies (e.g. Jayal et al. 2015) have found that a post-secondary sequence that starts out with Python and then transitions to Java performs as well as a sequence that starts in Java. Another question asks how to optimize that transition.

Python has particular elements that do not correspond well to Java, however. Negative indices (with which a=[1, 2, 4, 6] means that a[-1] is 6) and slices (with which a[1:3] is [2, 4]) are commonly found in code students stumble upon on the Internet, making it somewhat useful to mention these language features when teaching about lists and strings.

Python's native types don't include a type in which pointer arithmetic can be exploited for speed, though the numpy library offers an array. I suspect that when students learn about Java arrays, they probably build a mental model that fairly closely matches how arrays are stored in memory in C. Python does not actually store lists in a sequence of equally sized memory blocks; [3, 'a', 5.2] is a perfectly valid list.

Does the mixed-type sequence or slicing or negative indexing in Python change a student's initial mental model for lists, arrays, and other sequences?

Answer 1

I am not aware that cognitive modeling of memory structures in early programming education has been directly studied, so anything that I say here is entirely speculative. However, I suspect that the models themselves would somewhat depend on teacher presentation, and would otherwise be relatively stable.

Take negative indexing as an example. A reasonable initial cognitive model for a list would be some sort of cycle. If it is later explained as an array with indexing performed with a modular operation, then we have moved our conception to some sort of line. When we even later explain about memory references and data size, then we can finish the picture as an array (line) of fixed size memory references, each pointing to a different object in the heap.

There are only so many simple physical shapes that we can use to represent these ideas. Which actual conceptualization a student takes will depend on their maturity in the subject matter and on how the data structure is presented by the instructor. I don't see any reason to believe that the initial choice of language would have any substantive, lasting impact on these cognitive models as the student matures in their understanding.

Answer 2

I think that this is an interesting question, and one the textbooks often ignore or treat as unimportant. I've noticed it because I end up teaching Python, Java and C++ and have seen how my student's mental models lead to misunderstandings in their code.

Here are the three things that seem the hardest for my students to understand:

• In Python, where everything is a reference, variables act differently depending on their mutability. If you assign a list to a different list variable, the behavior is different that if you assign an int to a variable.
• In Java, which has both "shoebox" variables for its primitive types and implicit references for everything else, students struggle to juggle two different object models as well; instead of mutable:immutable, they have value (primitive) types and reference types.
• C++: where everything is a value type, students must deal with the cost of implicit copies.

Most often students deal with these differences via memorization. I think actually understanding how the data is stored makes those differences a little easier to understand and to remember.

Answer 3

I'm pretty sure that a general answer isn't possible here and it depends too much on at least (a) what the student has seen before, and (b) how the prof and other available materials describe things. In strong OOP languages (or with a strong OOP style in a weaker language), I can give students a mental model of computation that doesn't depend on a map to a machine. There is no post office boxes metaphor or equal size boxes, etc. The student can go quite a long while with this model.

In particular, all data can be owned by objects and each object has a dictionary (informal concept) that maps variable names to values. The dictionary may be editable (variables) or not (constants). An array can be defined as a function from an index set [1..n] to some set of values. The function may be modifiable, or not. etc. A variable isn't a box, but a mutable reference to a value. A constant isn't a box (or even a value) but an immutable reference to a value.

My reason for doing this is that when they depend on a machine memory model and when they are presented with a problem they have to (1) map the high level concept in Ruby/Python/Java into the machine model, (2) think about how it works there and then (3) map it back to the code level. Avoiding the maps altogether seems to be an order of magnitude simpler. Just give them a single, high level model in which they can think consistently without errors of interpretation.

But yes, many teachers were taught with a C-like model and so solve most problems in a C-like way, so they teach their students to do that as well.

To me, a somewhat more interesting question (for your java <-> python example) is, does learning to program in a language with fewer rules but more dependence on style and testing for correctness (python) first help or hinder later programming in a language with lots of enforced rules that even make some legal problems illegal (since the type checker isn't omniscient).

OR, does learning to get along with the type police (java) first, help or hinder later learning in a free world, where certain types of correctness are suddenly on the back of the programmer.

Python programmer like to rail against the java checker. But they can also fall into holes that the java compiler would shunt them around. I like types and the checks they provide, but you may not.

And of course, it matters more for some students than others.

Finally, your model is unlikely to be a very close match with reality anyway. How many levels of cache? It is a low level artificial construct. I prefer a high level artificial construct. Of course I really had to know those things, just after the Chicxulub incident when I was writing FORTRAN. But at least the dinosaurs were gone.