<p>My earlier answer focused on overall program structure, not assignment and mutable state explicitly. The originator was focused otherwise, on assignment. </p>

<p>One of the difficulties for beginners, I think, is that taking a Turing Machine view, or a program stack view, or a mail-box cubby hole view is that it isn't natural for students. Without criticizing that view, let me give a different one that I think is stronger. I don't think of a variable as a "box" into which I can put a value, changing the value later (when allowed). Instead, I think of a variable as just a reference to a value. Using the originators notation, I see</p>

<pre><code>x:=3;
</code></pre>

<p>and think that x references a value, 3.</p>

<pre><code>x:=4;
</code></pre>

<p>so x references a different variable (not that 3 "becomes" 4) and</p>

<pre><code>x:=x+1;
</code></pre>

<p>is just compute a new value using x and then let x refer to the new value;</p>

<p>This, of course is the same reference model we use in other languages (OOP, functional) for things. A variable is just a name (not a box) the name can refer to different values at different times/contexts (Buffy is me here, Buffy is you there). Different names can refer to the same object at the same time (Angel is me and also Buffy is me). </p>

<p>Assignment does nothing more than reassign a name. </p>

<p>Note that I recommend this mental model for <em>beginners</em>, and believe it has substance even for advanced programmers (e.g. me). However, at some point you do want to show the map to machine states, but that is a different issue. If I do that too early, then I ask the students to carry around two different models of computation, one based on logic and another, different one, based on machines. I prefer to keep it simple for the beginner and so try to focus on just the logical (higher level) model. But it takes some work to have a consistent model.  </p>

<p>As a general principle, I don't believe that every beginner must recapitulate the entire history of computing in the first course. Said another way, there are lots of things that I know, but it would be counterproductive to tell students. Their path needn't be my path. </p>

<p>Finally, my comments in the earlier answer about separating concerns still holds. A virtual world can free the student from also needing to learn the issues and side effects, etc. of primitive data. Assignment can involve "interesting values" as it does in other computing models. </p>

<hr>

<p>It just occurred to me that a discussion of <a href="https://en.wikipedia.org/wiki/Haddocks&#39;_Eyes" rel="nofollow noreferrer">Haddock's Eyes</a> can be valuable for making the distinction between a name and the thing to which the name applies (also aliasing, ...). x isn't 3, x is a name that refers to 3. 3 itself is a number. (or if you want to delve deeper  - a symbol representing a number...)</p>

CC BY-SA 3.0
2017-07-13T20:22:25.200Z
Lambda expression = anonymous function. e.g. (x)->{System.out.println("hello " + x);}  This one is an example of something called a Consumer in Java 8. It could be an instance of Consumer<String> or Consumer<Integer> or ... Lots of things need not be specified.
Buffy
CC BY-SA 3.0
2017-08-11T10:54:45.387Z
The problem with the box idea is that an assignement x=y  doesn't move the object to the other box, but makes a copy.  So the analogy is limited. Except if you're talking about unique_ptr in C++ :-)
Michel Billaud
CC BY-SA 3.0
2017-06-29T16:52:29.483Z
2017-06-30T15:23:48.813Z
2017-06-30T15:23:48.813Z
Buffy
<p>This is a topic very close to my heart.  I think that the skeptical attitude you've alluded to simply comes from the fact that most people were taught imperative programming first (and some were never exposed to any other paradigms at all).  Turing's Machine was easier to conceive of as a physical, mechanical device than Church's $\lambda$, and it is presumably by this historical accident that mutability rules the day almost everywhere.  </p>

<p>I am not even remotely convinced that imperative programming is more obvious or intuitive than functional programming.  In my experience, setting values is a consistent cognitive trap for students, and one that I have to treat with great care.  My very first unit for AP is modeled rather loosely after <a href="http://www.intuitor.com/student/Q1_Comp_Sci_Objectives.php" rel="noreferrer">Tom Rogers' phenomenal opening AP unit</a>, <strong><em>Java Ain't Algebra</em></strong>, which takes exactly this issue head on.  </p>

<p>In my (by now heavily modified) version of Roger's mini-unit, I make explicit that values can change, spend time tracing them, show why <code>x = 4 + 7</code> is not the same as <code>x - 4 = 7</code>, and spend a lot of time making clear that the programmer's</p>

<p><code>=</code> </p>

<p>is only barely related to the mathematical</p>

<p>$=$.  </p>

<p>We also begin to explore the runtime stack.</p>

<p>Teachers often miss that this even needs to be covered because, once they are thoroughly inculcated in imperative programming, it can become hard to even see why this is hard in the first place.  The variable <code>x</code> was <code>4</code>, but now it is <code>5</code>.  What could be simpler?  </p>

<p>But of course, students exposure to variables prior to CS comes from algebra.  And in algebra, when we say that $x + 3 = 7$, we mean that $x = 4$, and it cannot suddenly become $5$.  We can <em>solve for values</em>, but we cannot alter them.  </p>

<p>Here's the takeaway: <strong>if we, as teachers, don't make explicit how very different it is to be able to change values</strong>, a certain percentage of students don't ever fully pick up this idea.  They'll get hazy bits and pieces of the idea, but have trouble operating, and ultimately fall behind.</p>

<p>In my experience, they don't appear to get noticeably lost until far later in the year, but by then, it is <em>very hard</em> to get them back on track.  (When I take on a new tutee in the months leading up to the AP test, this is one of the first areas I check if they seem generally lost.)  I have also come to believe that this is one of the key ideas that most CS teachers miss, and is responsible for a substantial portion of computer science's very bimodal results with students.</p>

<p>There is a real cognitive load to considering not the value of <code>x</code>, but the value of <code>x</code> <em>right now</em>, and having to both track that value and figure out when to change it.</p>

<p>In spite of what this all sounds like, I'm not suggesting that functional programming is necessarily easier; it has its own cognitive load, since suddenly we are contemplating many, many simultaneous <code>x</code>'s taking place during recursive calls.  It's almost as if learning to talk to something as alien as a computer is always going to be a bit tricky :)</p>

CC BY-SA 3.0
2017-06-03T11:44:28.100Z
What I mean is that there's an awful lot you can get through without recursion, and you can also do a lot of recursive work through higher-order procedures that "hide" the recursion (as you seem to know). So it's a matter of how your curriculum is designed.
Shriram Krishnamurthi
CC BY-SA 3.0
2017-06-03T11:45:15.760Z
And yes, there are surely traps in FP too. What's a great pity is that the CS Ed literature has done so startlingly little to identify what they might be, caught up in hysteria about the "paradigm" itself to not investigate it in any real detail. But that doesn't mean it's not a "panacea" (unnecessarily grand term, but I'm just borrowing it from you) for _the problems described about imperative programming_; I think it is. It just moves some of the problems elsewhere.
Shriram Krishnamurthi
CC BY-SA 3.0
2017-06-03T14:55:08.967Z
This next September will only be my second year teaching Scheme, so this is an area in which my thinking is very much evolving. Since you are both more experienced in this area, and have clearly thought about it a great deal, I am very curious about what you would think about [this question](https://cseducators.stackexchange.com/questions/106/scheme-vs-haskell-for-introducing-functional-programming), which I have been wrestling with.
Ben I.
CC BY-SA 3.0
2017-08-12T16:19:09.070Z
Actually, computers have nothing to do with Turing machines, that are abstract machines to reason about computability. TM can be implemented https://www.youtube.com/watch?v=cYw2ewoO6c4 but nobody will ever use them as the basis for practical calculations. When Turing worked on computers at Manchester, they were based on the registers, alu, memory etc model. When programming such devices, most of the operations are moving data from one place to another (thus the concept of variables holding data) and adding, subtracting etc. And it fitted with what you wanted to do with computers at the time.
Michel Billaud
CC BY-SA 3.0
2017-06-03T00:23:34.330Z
Functional programming doesn't imply recursion. The [Bootstrap curricula](http://www.bootstrapworld.org/) all use functional programming with only very limited recursion, and get students through a ton of material, all without the problems you rightly identify with imperative programming!
Shriram Krishnamurthi
CC BY-SA 3.0
2017-06-03T01:50:00.420Z
I'm not sure what you mean by "functional programming doesn't imply recursion" - while there may be many things you can learn as a beginner in a functional paradigm before you get to recursion, at some point, you still have to be able to work your way through a list.
Ben I.
CC BY-SA 3.0
2017-06-03T01:58:46.380Z
I was also being a bit flippant in my description of functional programming - my point wasn't specifically about recursion, but rather that it has its own cognitive traps, so it is not some easy panacea for the problems I described about imperative programming
Ben I.
CC BY-SA 3.0
2017-06-02T01:39:32.003Z
2017-06-02T18:17:16.447Z
2017-06-02T18:17:16.447Z
Ben I.
<p>The difference may be partially related to whether or not the student has a mental model of the machine (as in simple, possibly physically mechanical, computing hardware), rather than more abstract symbology (algebra).</p>

<p>Changing the bits on a Turing machine tape, or the wheels on a Babbage engine, or the display of a pocket calculator, or the position of the beads on an abacus, as one carries out a sequence of steps, clearly shows how and when state changes, and the visible difference at different steps (program counter values) in the algorithm or program.</p>

<p>Algebraic notation hides the turning of the gears, or the ticking of the (computer's) clock, and thus hides imperative state changes to variable values.</p>

<p>Possibly for this reason, I've seen simplified assembly language (CARDIAC cardboard computer, with 10 instructions and 10 memory locations) taught near the beginning of introductory CS for non-majors courses, before delving into higher level programming language constructs (Lisp/Scheme, et.al.)</p>

CC BY-SA 4.0
2019-04-05T10:08:43.470Z
In my quest for discovering what really makes mutations so hard I'm leaning towards these exact ideas. It's the *hiding of the gears* that plays a major role. It probably came to be to "simplify" the material to have the student not deal with "too low" level registers and instructions, but I suspect that a low level intro would make things much clearer. Might be that or might be some nice interface that makes the execution visible. But it's important to picture the *execution*, not the code, which is what instead I see getting quite a lot of attention.
user9137
CC BY-SA 3.0
2017-06-03T02:29:12.943Z
2017-06-03T02:51:50.890Z
2017-06-03T02:51:50.890Z
hotpaw2
<p>I think that both the question and the answers to date conflate two things that can be separated: imperative programming and programming with primitive data. These are not the same thing and thinking of them as one leads to some of the difficulties. Programs don't all have to be C-like programs from 1980. </p>

<p>Using modern languages (java, python, ruby, scala...) the instructor can, instead, create a virtual world in which students have their first programming experiences. So, rather than first introducing strings ("hello world") and ints (with their operations - and the limitations of those operations) students can program with "things of interest." While my own preference is to have them learn OOP principles early on, that isn't necessarily implied by having a virtual world. </p>

<p>In the Karel series of books (<em>Karel the Robot</em>, Richard Pattis) and its successors in Java, Python, and Ruby the students first introduction is with a few primitive actions (move, turnLeft, ...) and one kind of primitive "value" (beeper). The world is very rich - provably a Turing Machine. </p>

<p>Using such a world, this one or one of your own devising, you can present the computing model you prefer to students with very little distracting detail (maxInt...). You can then teach program logic and structure separate from that detail. </p>

<p>Once the students have a basic grasp of the "fundamentals" (i.e. not int and string) you can introduce those concepts incrementally. But it is amazing how much you can teach without explicit counting. </p>

<p>One feature of the Karel books that may be a plus or a minus is that, while they give a good foundation in computation, they are not intended to have enough material for a complete course, either at secondary or university level. One person I know is working to build a complete course around Karel J Robot, but I think that is a bit optimistic. But they are good for an introduction, at least: a short course or the first third-half of a regular course. </p>

CC BY-SA 3.0
2017-06-29T12:35:07.110Z
This is a point I had not considered, which is strange when I remember that I myself started off in Logo before graduating to BASIC. Thanks for bringing this up. This is an important point.
Ben I.
CC BY-SA 3.0
2017-06-29T15:51:11.610Z
Uh? I don't mention primitive data types anywhere in my question, and I don't see what this has to do with imperative programming. I guess your point is to teach imperative programming without introducing explicit mutable state, only external actions? That's an interesting idea, but it's rather hard to extract from the irrelevant digression into data types. And your answer doesn't actually say anything about whether this makes it easier to learn assignments.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-06-29T12:01:41.950Z
2017-06-29T12:01:41.950Z
Buffy
<p>In my experience, people who have programmed before, whether they're professional or not, almost always consider imperative programming to be obvious. They're usually skeptical that a concept such as variable assignment could be difficult to learn.</p>

<p>On the other hand, in my limited experience (teaching Programming 101, and with people learning to write simple scripts), students who are beginning to learn about programming do find the concept difficult. Given a program like</p>

<pre><code>x := 2;
print(x);
if some_condition() then x := 3;
</code></pre>

<p>many students struggle with the concept that <code>print(x)</code> will not print 3 even if <code>some_condition()</code> is true. Writing assignment using <code>=</code> may make the difficulty more widespread.</p>

<p>Is difficulty with imperative programming correlated with certain backgrounds? For example, do students with a strong mathematical background struggle more because they have some prior concept of equality? Do students with more computer time struggle less because they're more used to the concept of a state change (even if they can't formulate it in these terms of course)?</p>

CC BY-SA 3.0
2017-07-10T17:49:21.890Z
You are correct that part of the problem is in the notation resembling normal maths. There is nothing wrong with this maths (except that things are much much harder to prove in imperative programs, unless constrained to me functional), it is just different. 1+1 = 1 (Boolean algebra).
ctrl-alt-delor
CC BY-SA 3.0
2018-03-07T19:56:59.693Z
There's two big concepts here that are not fully "common sense". The concept of a variable, and order of operations. These are "operations or steps" not "truths", these are "variables" not "unknown constants".
Gorchestopher H
<imperative-programming><programming-paradigms>
What makes imperative programming easier or harder to learn?
# What makes imperative programming easier or harder to learn?

(Asked by: username_0 on 2017-06-01)

In my experience, people who have programmed before, whether they're professional or not, almost always consider imperative programming to be obvious. They're usually skeptical that a concept such as variable assignment could be difficult to learn.
On the other hand, in my limited experience (teaching Programming 101, and with people learning to write simple scripts), students who are beginning to learn about programming do find the concept difficult. Given a program like
x := 2;
print(x);
if some_condition() then x := 3;

many students struggle with the concept that print(x) will not print 3 even if some_condition() is true. Writing assignment using = may make the difficulty more widespread.
Is difficulty with imperative programming correlated with certain backgrounds? For example, do students with a strong mathematical background struggle more because they have some prior concept of equality? Do students with more computer time struggle less because they're more used to the concept of a state change (even if they can't formulate it in these terms of course)?

**Tags:** imperative-programming, programming-paradigms

> **Comments:**
> **username_1**: You are correct that part of the problem is in the notation resembling normal maths. There is nothing wrong with this maths (except that things are much much harder to prove in imperative programs, unless constrained to me functional), it is just different. 1+1 = 1 (Boolean algebra).  
> **username_2**: There's two big concepts here that are not fully "common sense". The concept of a variable, and order of operations. These are "operations or steps" not "truths", these are "variables" not "unknown constants".  

---

## 4 answers

### Answer by username_5 on 2017-06-02. Score: 15 | Accepted answer

This is a topic very close to my heart. I think that the skeptical attitude you've alluded to simply comes from the fact that most people were taught imperative programming first (and some were never exposed to any other paradigms at all). Turing's Machine was easier to conceive of as a physical, mechanical device than Church's $\lambda$, and it is presumably by this historical accident that mutability rules the day almost everywhere.

I am not even remotely convinced that imperative programming is more obvious or intuitive than functional programming. In my experience, setting values is a consistent cognitive trap for students, and one that I have to treat with great care. My very first unit for AP is modeled rather loosely after [Tom Rogers' phenomenal opening AP unit](http://www.intuitor.com/student/Q1_Comp_Sci_Objectives.php), ***Java Ain't Algebra***, which takes exactly this issue head on.

In my (by now heavily modified) version of Roger's mini-unit, I make explicit that values can change, spend time tracing them, show why `x = 4 + 7` is not the same as `x - 4 = 7`, and spend a lot of time making clear that the programmer's

`=`

is only barely related to the mathematical

$=$.

We also begin to explore the runtime stack.

Teachers often miss that this even needs to be covered because, once they are thoroughly inculcated in imperative programming, it can become hard to even see why this is hard in the first place. The variable `x` was `4`, but now it is `5`. What could be simpler?

But of course, students exposure to variables prior to CS comes from algebra. And in algebra, when we say that $x + 3 = 7$, we mean that $x = 4$, and it cannot suddenly become $5$. We can *solve for values*, but we cannot alter them.

Here's the takeaway: **if we, as teachers, don't make explicit how very different it is to be able to change values**, a certain percentage of students don't ever fully pick up this idea. They'll get hazy bits and pieces of the idea, but have trouble operating, and ultimately fall behind.

In my experience, they don't appear to get noticeably lost until far later in the year, but by then, it is *very hard* to get them back on track. (When I take on a new tutee in the months leading up to the AP test, this is one of the first areas I check if they seem generally lost.) I have also come to believe that this is one of the key ideas that most CS teachers miss, and is responsible for a substantial portion of computer science's very bimodal results with students.

There is a real cognitive load to considering not the value of `x`, but the value of `x` *right now*, and having to both track that value and figure out when to change it.

In spite of what this all sounds like, I'm not suggesting that functional programming is necessarily easier; it has its own cognitive load, since suddenly we are contemplating many, many simultaneous `x`'s taking place during recursive calls. It's almost as if learning to talk to something as alien as a computer is always going to be a bit tricky :)

> **Comments:**
> **username_6**: Functional programming doesn't imply recursion. The [Bootstrap curricula](http://www.bootstrapworld.org/) all use functional programming with only very limited recursion, and get students through a ton of material, all without the problems you rightly identify with imperative programming!  
> **username_5**: I'm not sure what you mean by "functional programming doesn't imply recursion" - while there may be many things you can learn as a beginner in a functional paradigm before you get to recursion, at some point, you still have to be able to work your way through a list.  
> **username_5**: I was also being a bit flippant in my description of functional programming - my point wasn't specifically about recursion, but rather that it has its own cognitive traps, so it is not some easy panacea for the problems I described about imperative programming  
> **username_6**: What I mean is that there's an awful lot you can get through without recursion, and you can also do a lot of recursive work through higher-order procedures that "hide" the recursion (as you seem to know). So it's a matter of how your curriculum is designed.  
> **username_6**: And yes, there are surely traps in FP too. What's a great pity is that the CS Ed literature has done so startlingly little to identify what they might be, caught up in hysteria about the "paradigm" itself to not investigate it in any real detail. But that doesn't mean it's not a "panacea" (unnecessarily grand term, but I'm just borrowing it from you) for _the problems described about imperative programming_; I think it is. It just moves some of the problems elsewhere.  
> **username_5**: This next September will only be my second year teaching Scheme, so this is an area in which my thinking is very much evolving. Since you are both more experienced in this area, and have clearly thought about it a great deal, I am very curious about what you would think about [this question](https://cseducators.stackexchange.com/questions/106/scheme-vs-haskell-for-introducing-functional-programming), which I have been wrestling with.  
> **username_4**: Actually, computers have nothing to do with Turing machines, that are abstract machines to reason about computability. TM can be implemented https://www.youtube.com/watch?v=cYw2ewoO6c4 but nobody will ever use them as the basis for practical calculations. When Turing worked on computers at Manchester, they were based on the registers, alu, memory etc model. When programming such devices, most of the operations are moving data from one place to another (thus the concept of variables holding data) and adding, subtracting etc. And it fitted with what you wanted to do with computers at the time.  

---

### Answer by username_7 on 2017-06-03. Score: 6

The difference may be partially related to whether or not the student has a mental model of the machine (as in simple, possibly physically mechanical, computing hardware), rather than more abstract symbology (algebra).

Changing the bits on a Turing machine tape, or the wheels on a Babbage engine, or the display of a pocket calculator, or the position of the beads on an abacus, as one carries out a sequence of steps, clearly shows how and when state changes, and the visible difference at different steps (program counter values) in the algorithm or program.

Algebraic notation hides the turning of the gears, or the ticking of the (computer's) clock, and thus hides imperative state changes to variable values.

Possibly for this reason, I've seen simplified assembly language (CARDIAC cardboard computer, with 10 instructions and 10 memory locations) taught near the beginning of introductory CS for non-majors courses, before delving into higher level programming language constructs (Lisp/Scheme, et.al.)

> **Comments:**
> **username_8**: In my quest for discovering what really makes mutations so hard I'm leaning towards these exact ideas. It's the *hiding of the gears* that plays a major role. It probably came to be to "simplify" the material to have the student not deal with "too low" level registers and instructions, but I suspect that a low level intro would make things much clearer. Might be that or might be some nice interface that makes the execution visible. But it's important to picture the *execution*, not the code, which is what instead I see getting quite a lot of attention.  

---

### Answer by username_3 on 2017-06-29. Score: 2

I think that both the question and the answers to date conflate two things that can be separated: imperative programming and programming with primitive data. These are not the same thing and thinking of them as one leads to some of the difficulties. Programs don't all have to be C-like programs from 1980.

Using modern languages (java, python, ruby, scala...) the instructor can, instead, create a virtual world in which students have their first programming experiences. So, rather than first introducing strings ("hello world") and ints (with their operations - and the limitations of those operations) students can program with "things of interest." While my own preference is to have them learn OOP principles early on, that isn't necessarily implied by having a virtual world.

In the Karel series of books (*Karel the Robot*, Richard Pattis) and its successors in Java, Python, and Ruby the students first introduction is with a few primitive actions (move, turnLeft, ...) and one kind of primitive "value" (beeper). The world is very rich - provably a Turing Machine.

Using such a world, this one or one of your own devising, you can present the computing model you prefer to students with very little distracting detail (maxInt...). You can then teach program logic and structure separate from that detail.

Once the students have a basic grasp of the "fundamentals" (i.e. not int and string) you can introduce those concepts incrementally. But it is amazing how much you can teach without explicit counting.

One feature of the Karel books that may be a plus or a minus is that, while they give a good foundation in computation, they are not intended to have enough material for a complete course, either at secondary or university level. One person I know is working to build a complete course around Karel J Robot, but I think that is a bit optimistic. But they are good for an introduction, at least: a short course or the first third-half of a regular course.

> **Comments:**
> **username_5**: This is a point I had not considered, which is strange when I remember that I myself started off in Logo before graduating to BASIC. Thanks for bringing this up. This is an important point.  
> **username_0**: Uh? I don't mention primitive data types anywhere in my question, and I don't see what this has to do with imperative programming. I guess your point is to teach imperative programming without introducing explicit mutable state, only external actions? That's an interesting idea, but it's rather hard to extract from the irrelevant digression into data types. And your answer doesn't actually say anything about whether this makes it easier to learn assignments.  

---

### Answer by username_3 on 2017-06-29. Score: 1

My earlier answer focused on overall program structure, not assignment and mutable state explicitly. The originator was focused otherwise, on assignment. 
One of the difficulties for beginners, I think, is that taking a Turing Machine view, or a program stack view, or a mail-box cubby hole view is that it isn't natural for students. Without criticizing that view, let me give a different one that I think is stronger. I don't think of a variable as a "box" into which I can put a value, changing the value later (when allowed). Instead, I think of a variable as just a reference to a value. Using the originators notation, I see
x:=3;

and think that x references a value, 3.
x:=4;

so x references a different variable (not that 3 "becomes" 4) and
x:=x+1;

is just compute a new value using x and then let x refer to the new value;
This, of course is the same reference model we use in other languages (OOP, functional) for things. A variable is just a name (not a box) the name can refer to different values at different times/contexts (username_3 is me here, username_3 is you there). Different names can refer to the same object at the same time (Angel is me and also username_3 is me). 
Assignment does nothing more than reassign a name. 
Note that I recommend this mental model for beginners, and believe it has substance even for advanced programmers (e.g. me). However, at some point you do want to show the map to machine states, but that is a different issue. If I do that too early, then I ask the students to carry around two different models of computation, one based on logic and another, different one, based on machines. I prefer to keep it simple for the beginner and so try to focus on just the logical (higher level) model. But it takes some work to have a consistent model.  
As a general principle, I don't believe that every beginner must recapitulate the entire history of computing in the first course. Said another way, there are lots of things that I know, but it would be counterproductive to tell students. Their path needn't be my path. 
Finally, my comments in the earlier answer about separating concerns still holds. A virtual world can free the student from also needing to learn the issues and side effects, etc. of primitive data. Assignment can involve "interesting values" as it does in other computing models. 

It just occurred to me that a discussion of Haddock's Eyes can be valuable for making the distinction between a name and the thing to which the name applies (also aliasing, ...). x isn't 3, x is a name that refers to 3. 3 itself is a number. (or if you want to delve deeper  - a symbol representing a number...)

> **Comments:**
> **username_3**: Lambda expression = anonymous function. e.g. (x)->{System.out.println("hello " + x);}  This one is an example of something called a Consumer in Java 8. It could be an instance of Consumer<String> or Consumer<Integer> or ... Lots of things need not be specified.  
> **username_4**: The problem with the box idea is that an assignement x=y  doesn't move the object to the other box, but makes a copy.  So the analogy is limited. Except if you're talking about unique_ptr in C++ :-)  

---

