<p>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. </p>

<p>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. </p>

<p>My reason for doing this is that when they <em>depend on</em> 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, <em>high level</em> model in which they can think consistently without errors of interpretation. </p>

<p>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. </p>

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

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

<p>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. </p>

<p>And of course, it matters more for some students than others. </p>

<p>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 <em>really</em> had to know those things, just after the Chicxulub incident when I was writing FORTRAN. But at least the dinosaurs were gone. </p>

CC BY-SA 4.0
2021-05-02T01:26:52.680Z
It is interesting your idea that it is a problem when students have to map to a low level idea then back to a different high level idea to get to an answer or solution. But... if they do this a few times, it becomes a concept and they understand the whole route and can take it in one step. But if they never have to make the trip, then they never will understand. Do we want people who don't understand to be programming? Seems reckless.
Scott Rowe
CC BY-SA 3.0
2017-07-03T00:51:55.947Z
I think your instinct to give students a "high level model" for how data are stored in memory is in line with my assertion that most teachers of entry CS do not teach low-level ideas with much breadth or depth. I am saying that students nevertheless construct a model for howe a computer works, at some low level, and that their model has implications later on in their education.
Bennett Brown
CC BY-SA 3.0
2017-07-03T11:45:31.013Z
@BennettBrown, I'm wondering if you think that it is important for the students to have an accurate, or any particular, model. Is it important to you that beginners learn low-level ideas early on?
Buffy
CC BY-SA 3.0
2017-07-04T18:46:53.793Z
In a pure functional model the boxes model isn't very useful, I think. Trying to map everything to it mentally while programming is a waste of effort <opinion/>. A dictionary takes you pretty far. I note that the Oxford English Dictionary, when under development originally, was literally a set of cubby boxes for definitions submitted by contributors. "memory" is a mapping from names (tokens) to values. Just extend something like the OOP reference-to-object model universally. No one thinks of the OED as a set of cubbies anymore, I suspect. "names" reference "things". Compiler writers need more.
Buffy
CC BY-SA 3.0
2017-07-04T18:50:33.037Z
For the record @nocomprende I did, in fact, build such a thing once to teach with. It even used "magic slates" (plastic sheet over black waxy background) for volatile memory. I finally threw it out & don't likely even have a photo of it anymore. You took me back a bit with your note. I never taught 8th grade, though, so you can't blame me. =), nor personally, anyway.
Buffy
CC BY-SA 3.0
2017-07-04T18:59:31.347Z
@nocomprende. Like in The Matrix??? And are you stealing my jokes now ("just after Chicxulub") or are you older than dirt too, like myself? A pretty famous CS guy gave me the shirt to assure me that I am, anyway.
Buffy
CC BY-SA 3.0
2017-07-04T19:03:59.603Z
My archeological layer is a bit lower than yours, but I guess the mods will be on us for a conversation here. Be well. Or come to the Classroom chat.
Buffy
CC BY-SA 3.0
2017-07-02T23:53:37.080Z
2017-07-02T23:53:37.080Z
Buffy
<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-07-03T04:02:41.677Z
Students never just absrob new material. They always incorporate new ideas into models they already have constructed. Students do not abandon models they have already adopted, even if they are told the model is wrong. This is "constructivism." See National Research Council. (2000). "How People Learn". If negative indexing makes people start out by envisioning a circular/modulus structure, it is presumed to affect later learning.
Bennett Brown
CC BY-SA 3.0
2017-07-03T04:03:02.790Z
Thank you for speculating @BenI ! We do have some evidence to go on; mental models of intro CS students have been studied, including arrays and lists in particular. See Sodol et al. (2009). http://www.cs.cmu.edu/~lsudol/lsudol_p28.pdf
Bennett Brown
CC BY-SA 3.0
2017-07-03T13:38:13.903Z
@BennettBrown And yet, we all eventually come to conceive of arrays as lines. Your description of constructivism is overstated, or it would make this impossible. You actually brought up one of my very favorite books! See How People Learn, page 11, first full paragraph :)
Ben I.
CC BY-SA 3.0
2017-07-03T15:11:48.763Z
Upon reflection, I actually think that constructivism itself may not be quite right. We know that the brain utilizes prior patterns when it encodes new patterns, but constructivism is simply an observation that, even though the student engages in code-switching, this does not intrinsically mean that they have migrated to a *better* representation. They are able to re-encoding their flat representation into a pancake, a sphere, a tube, a dome, etc; they simply chose the wrong new representation. Thus, we must take care in presenting new patterns to try to maximize the utility of re-encodings.
Ben I.
CC BY-SA 3.0
2017-07-03T03:50:13.870Z
2017-07-03T03:50:13.870Z
Ben I.
<p>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. </p>

<p>Here are the three things that seem the hardest for my students to understand:</p>

<ul>
<li>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.</li>
<li>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.</li>
<li>C++: where everything is a value type, students must deal with the cost of implicit copies.</li>
</ul>

<p>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. </p>

CC BY-SA 4.0
2021-05-02T01:22:12.767Z
"Actually understanding" really seems like the way to go, no matter the difficulty or cost. Win or fail, but don't emerge with wrong ideas.
Scott Rowe
CC BY-SA 3.0
2017-07-13T20:43:31.470Z
2017-07-13T20:43:31.470Z
Stephen Gilbert
<p>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. </p>

<p>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?</p>

<p><strong>Background</strong></p>

<p>Several single-university studies (<a href="http://www.tandfonline.com/doi/full/10.11120/ital.2011.10010086" rel="noreferrer">e.g. Jayal et al. 2015</a>) 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. <a href="https://cseducators.stackexchange.com/questions/1030/transition-from-java-to-python">Another question</a> asks how to optimize that transition.</p>

<p>Python has particular elements that do not correspond well to Java, however. Negative indices (with which <code>a=[1, 2, 4, 6]</code> means that <code>a[-1]</code> is <code>6</code>) and slices (with which <code>a[1:3]</code> is <code>[2, 4]</code>) 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.</p>

<p>Python's native types don't include a type in which pointer arithmetic can be exploited for speed, though the <code>numpy</code> 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; <code>[3, 'a', 5.2]</code> is a perfectly valid list. </p>

<p>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?</p>

CC BY-SA 3.0
2018-01-14T23:08:07.873Z
I learned BASIC first (the one directly descended from FORTRAN, not later flavors like GWBASIC or VB). Later I learned Pascal, and I had to relearn memory, but my model was still wrong. Later I learned C on a VAX 11/780, for which C is structured assembly language, and developed yet another model that was closer to correct but still wrong. Finally I leaned assembly on 6502, x80, x86 and 68xxx processors, built some computer s by hand soldering the parts together, and then I understood memory.
pojo-guy
CC BY-SA 4.0
2019-05-31T15:56:22.663Z
"Python does not actually store lists in a sequence of equally sized memory blocks" or rather it does, but those fixed-sized memory blocks don't store the items directly, they merely store references to the objects representing the items.
Peter Green
CC BY-SA 4.0
2021-05-02T01:30:02.223Z
@heather Great was my dismay when 300 pages in to SICP they said that the idea of the evaluator we had been studying thus far could never work in practice and it had to be abandoned.  Simplify, but never teach something that can't work. After that I basically discarded any Lisp-like thing as pointless and idiotic, enticing as it might be.
Scott Rowe
CC BY-SA 3.0
2017-07-02T22:30:39.870Z
My guess is that it depends on how the instructor/text describes negative indexing. If students understand that it's just syntactic sugar, I wouldn't expect it to affect their model.
Ellen Spertus
CC BY-SA 3.0
2017-07-03T05:23:42.363Z
[this question](https://cseducators.stackexchange.com/questions/1030/transition-from-java-to-python) might be of interest to you
ItamarG3
CC BY-SA 3.0
2017-07-03T14:07:30.317Z
I don't know how in-depth the class is going into memory - but I can say I never really thought about it (I started with Python) until I started reading the gigantic "Learning Python" by Mark Lutz (and put words to ideas I'd figured out via messing around, like strings being "immutable"). Great was my dismay when on chapter 3 (like a hundred pages in) the book says, to paraphrase "now we get into python in-depth". But anyway, maybe that's just me.
auden
<java><python><variables>
Do Python and Java lead students to construct different mental models of memory?
# Do Python and Java lead students to construct different mental models of memory?

(Asked by: username_0 on 2017-07-02)

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](http://www.tandfonline.com/doi/full/10.11120/ital.2011.10010086)) 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](https://cseducators.stackexchange.com/questions/1030/transition-from-java-to-python) 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?

**Tags:** java, python, variables

> **Comments:**
> **username_4**: My guess is that it depends on how the instructor/text describes negative indexing. If students understand that it's just syntactic sugar, I wouldn't expect it to affect their model.  
> **username_5**: [this question](https://cseducators.stackexchange.com/questions/1030/transition-from-java-to-python) might be of interest to you  
> **username_6**: I don't know how in-depth the class is going into memory - but I can say I never really thought about it (I started with Python) until I started reading the gigantic "Learning Python" by Mark Lutz (and put words to ideas I'd figured out via messing around, like strings being "immutable"). Great was my dismay when on chapter 3 (like a hundred pages in) the book says, to paraphrase "now we get into python in-depth". But anyway, maybe that's just me.  
> **username_1**: I learned BASIC first (the one directly descended from FORTRAN, not later flavors like GWBASIC or VB). Later I learned Pascal, and I had to relearn memory, but my model was still wrong. Later I learned C on a VAX 11/780, for which C is structured assembly language, and developed yet another model that was closer to correct but still wrong. Finally I leaned assembly on 6502, x80, x86 and 68xxx processors, built some computer s by hand soldering the parts together, and then I understood memory.  
> **username_2**: "Python does not actually store lists in a sequence of equally sized memory blocks" or rather it does, but those fixed-sized memory blocks don't store the items directly, they merely store references to the objects representing the items.  
> **username_3**: @heather Great was my dismay when 300 pages in to SICP they said that the idea of the evaluator we had been studying thus far could never work in practice and it had to be abandoned.  Simplify, but never teach something that can't work. After that I basically discarded any Lisp-like thing as pointless and idiotic, enticing as it might be.  

---

## 3 answers

### Answer by username_8 on 2017-07-03. Score: 5

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.

> **Comments:**
> **username_0**: Students never just absrob new material. They always incorporate new ideas into models they already have constructed. Students do not abandon models they have already adopted, even if they are told the model is wrong. This is "constructivism." See National Research Council. (2000). "How People Learn". If negative indexing makes people start out by envisioning a circular/modulus structure, it is presumed to affect later learning.  
> **username_0**: Thank you for speculating @BenI ! We do have some evidence to go on; mental models of intro CS students have been studied, including arrays and lists in particular. See Sodol et al. (2009). http://www.cs.cmu.edu/~lsudol/lsudol_p28.pdf  
> **username_8**: @BennettBrown And yet, we all eventually come to conceive of arrays as lines. Your description of constructivism is overstated, or it would make this impossible. You actually brought up one of my very favorite books! See How People Learn, page 11, first full paragraph :)  
> **username_8**: Upon reflection, I actually think that constructivism itself may not be quite right. We know that the brain utilizes prior patterns when it encodes new patterns, but constructivism is simply an observation that, even though the student engages in code-switching, this does not intrinsically mean that they have migrated to a *better* representation. They are able to re-encoding their flat representation into a pancake, a sphere, a tube, a dome, etc; they simply chose the wrong new representation. Thus, we must take care in presenting new patterns to try to maximize the utility of re-encodings.  

---

### Answer by username_9 on 2017-07-13. Score: 5

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.

> **Comments:**
> **username_3**: "Actually understanding" really seems like the way to go, no matter the difficulty or cost. Win or fail, but don't emerge with wrong ideas.  

---

### Answer by username_7 on 2017-07-02. Score: 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.

> **Comments:**
> **username_0**: I think your instinct to give students a "high level model" for how data are stored in memory is in line with my assertion that most teachers of entry CS do not teach low-level ideas with much breadth or depth. I am saying that students nevertheless construct a model for howe a computer works, at some low level, and that their model has implications later on in their education.  
> **username_7**: @BennettBrown, I'm wondering if you think that it is important for the students to have an accurate, or any particular, model. Is it important to you that beginners learn low-level ideas early on?  
> **username_7**: In a pure functional model the boxes model isn't very useful, I think. Trying to map everything to it mentally while programming is a waste of effort <opinion/>. A dictionary takes you pretty far. I note that the Oxford English Dictionary, when under development originally, was literally a set of cubby boxes for definitions submitted by contributors. "memory" is a mapping from names (tokens) to values. Just extend something like the OOP reference-to-object model universally. No one thinks of the OED as a set of cubbies anymore, I suspect. "names" reference "things". Compiler writers need more.  
> **username_7**: For the record @nocomprende I did, in fact, build such a thing once to teach with. It even used "magic slates" (plastic sheet over black waxy background) for volatile memory. I finally threw it out & don't likely even have a photo of it anymore. You took me back a bit with your note. I never taught 8th grade, though, so you can't blame me. =), nor personally, anyway.  
> **username_7**: @nocomprende. Like in The Matrix??? And are you stealing my jokes now ("just after Chicxulub") or are you older than dirt too, like myself? A pretty famous CS guy gave me the shirt to assure me that I am, anyway.  
> **username_7**: My archeological layer is a bit lower than yours, but I guess the mods will be on us for a conversation here. Be well. Or come to the Classroom chat.  
> **username_3**: It is interesting your idea that it is a problem when students have to map to a low level idea then back to a different high level idea to get to an answer or solution. But... if they do this a few times, it becomes a concept and they understand the whole route and can take it in one step. But if they never have to make the trip, then they never will understand. Do we want people who don't understand to be programming? Seems reckless.  

---

