Concept of variable

Question

For a beginner Is it right to use the concept of hotel room and passenger as an analogy to explain the concept of variable?

Answer 1

The use of an analogy is to provide a familiar jumping-off point to introduce something new. Since variables are unique features of computing systems, different from how anything else in the universe functions, we need some way to cross the gap. Let's look at how useful the analogy of hotel room and guest is, bearing in mind that most analogies do not survive contact with the students, for more than a few minutes.

The essential feature of this analogy is that you have a fixed thing, the room, which can have different contents: varying guests over time. Good. The very first thing out of a student's mouth (or keyboard) is likely to be: "can there be multiple guests in a room?" Hooray! Thinking! This was the objective.

Yes, you could use a One Dimensional Array (please do not call it a vector, which means something quite different to most students), or you could use a List. Quick explanation there...

Next idea: There is more than one room in most hotels! If you look at the building from outside, you see a two dimensional array of rooms, usually. The analogy hardly even needs for this idea to be broached, it just falls right out of the image. So, yes: a computer is basically a vast rectangle of boxes to put values in. Modern computers allow for different sized and shaped boxes, and even on-the-fly shapes like something conveyed with XML.

Hotel rooms have identifying information. In retreat centers, the rooms can have names, often the names of flowers or something. For computers -- which are essentially mathematical -- we just use numerical addresses. But names are so handy, so we layer those on top. We can define any old names for our any old arrangement of any sized boxes.

Now the analogy runs out of steam (or gasoline, or battery, or protons...) and we have introduced the subject in a way that students can visualize and therefore, hopefully let go of the nuts in the Southeast Asian Monkey Trap and move on. Some one of them might "continue writing the figure '1' " and you have another Ramanujan on your hands, but it is unlikely.

In 8th grade, over 40 years ago, my math teacher wheeled a Teletype to the front of the room and proceeded to explain about computer memory and variables, and then we connected to the School System's computer (the Police Department had one too, it was pretty exciting) and we created simple programs and stored them on paper tape. The essential facts about computers have not changed, because they can't.

The other answers made good points about naming and paper forms, so those should be mentioned also. But computers, variables, programs... are not like anything else, and that is why we have them, otherwise we would just have the other things instead. Because computers are so singular and incredible, we need to explain how they actually work, not paper over that. A construction worker who could only pick out wallpaper would not be much use when it came to building walls, putting in wiring and plumbing and so on.

And because those who do not learn from the history of computer system development are doomed to wander in the wilderness for 40 years. Other people have made a lot of the mistakes for you! Learn why they made those mistakes. Most likely, it is because they took some fixed idea they had too far, and couldn't make themselves agree with other people about stupid things like big-endian vs little-endian, which should never have been a thing. If you pick up the analogy by the pointy end, you can get fatally bitten by it.

Answer 2

Why complicate matters with contrived analogies like hotel rooms and guests?

It is much more straightforward to take the analogy of a simple paper "form" (which absolutely everyone in contact with the Western world has used and understands), and understand that there are spaces or "boxes" on the form which are referred to by names. The person completing the form enters data into those boxes. Additionally, there exists Tippex, and the data in any given box can usually be overwritten - with computers moreso than with paper, overwriting is common. The content of a box - the thing written into it (or the absence of any entry) - is generically called the "value".

The boxes in this paper analogy are the equivalent of computer variables. The declaration of a variable is the equivalent to defining a new box - that is, allocating space on the form and providing that space with an associated name.

This analogy of a paper bureaucracy fully extends to all other computer concepts.

A function call, for example, is the summoning of another form from the shelf. We transfer certain "input" values from the existing form to this new form. We then perform a set of calculations,.or other administrative operations (like gathering other stored data, searching filing cabinets, etc.), and finally we arrive at a set of "return" values which are transferred back to the existing form, and the "new" form is then thrown in the bin.

I often think a serious deficit in modern IT teaching and discourse, is that too few people are taught basic administrative principles and their equivalent implementations using paper.

Answer 3

You can also use @Steve paper form idea for a second use, namely the importance of naming. I have often given students a paper form with boxes of different lengths, labeled A, B, C, etc. I then explain that their ability to fill in the form correctly (with information about themselves) will account for 50% of their final grade. Of course, they immediately ask "What goes in each box?"

Instead of answering directly, I show them a sample form already filled in. I use values that look like first/last name, but use names which could easily be either a first name or last name (e.g. Thomas/Kelly). Between the names there is a short box containing a single letter A. Middle initial, right! The idea is to demonstrate that even given data values, one is never certain what that value is. The name must convey to the reader what the value is. At the end, I show a form with appropriate labels for each box. For the short box, the label is "Grade I hope to get".

This can be augmented by taking a short piece of code (I like to use quadratic equation), and obfuscate with names that look like Dr Seuss made up words. I ask them to explain what the code does. It is difficult when the variable names have no meaning in connection to the problem. I explain that their own code will become equally unfathomable unless they choose good names. Furthermore, asking the instructor for help solving a problem will be difficult if the instructor can not read/understand their code.

public class Seuss { // with apologies to Dr Seuss and John Lennon

  public static double snuvs(String s) { return Double.parseDouble(s); }

  public static void main(String[] jlbboo) {

    int lorax=0, quimney=2;
    double beft, obsk, kweet, zong, lerkim, skirtz;

    beft   = -snuvs(jlbboo[1]);
    kweet  =  snuvs(jlbboo[quimney]);
    obsk   =  snuvs(jlbboo[lorax]);
    zong   =  obsk * quimney;
    lerkim =  beft * beft;
    skirtz =  lerkim - zong * kweet / 0.5;
    beft  /=  zong;

    if (skirtz < lorax)
      System.out.println("Imagine the two numbers\nIt's easy if you try");
    else if (skirtz == lorax)
      System.out.println(beft);
    else {
      skirtz = Math.pow(skirtz, 1.0/quimney)/zong;
      System.out.println((beft+skirtz) + "," + (beft - skirtz));
    }
  }
}

Answer 4

Using labels as a metaphor over boxes has merit and has been examined.

This post looks at it from an early learner standpoint: https://www.felienne.com/archives/6063

There is a good post on this here that is more technical. https://hellokangning.github.io/post/variables-are-labels-not-boxes/

When looking at the strength of the metaphors to their "real life" examples:

• labels apply to one thing, boxes can contain many things
• if you have a named box, you already applied a label to a box that may contain a thing
• a thing can have many labels applied (aliasing) whereas a thing can only be in a single box
• applying a new label does not remove an old label, putting something in a new box should take it out if the old box (it doesn't here though)

Answer 5

I think it is a mistake to do this since it ties the "concept" of a variable, which is a language dependent item to an implementation on a certain kind of hardware. Yes, variables are often implemented in such a way, but the concept is independent of any implementation.

A computer language creates a self-referential and self-consistent virtual world. It is better that we use metaphors from such a world than from implementations. Also, if students eventually study OO languages or even pointers, they will often get confused by these sorts of descriptions. See the caveat at the end, however.

A better metaphor, in my view, is that a variable is a relationship between a "name" and a "value". The name might be simple (x) or complex (a[i]), but it is still just a name and it "represents" the value. It doesn't "hold" the value, but represents it.

Let me try to explain the reason I find this metaphor superior. First, students, in their real lives, understand "names" as representations of things.

At a given point in time/space a given name can only "represent" or "stand for" a single thing, though that "thing" might be complex. Buffy is my name here and it represents me. Other places and times Buffy represents other things (dare I say vampire slayers?). So, a variable isn't fixed for all time but can refer to different things at different times. Scopes in programs are a kind of place. The same name can refer to different things in different places. People already understand these things.

Also note that "I", the real world thing, am not "Buffy". "Buffy" is not "me", but something that refers to me.

In an OO language, a reference variable is also just a name that refers to an object. It isn't the object, but a reference. If students already think of names as references then this is much easier to grasp.

In a language like C, a pointer variable can also be described this way. Take a declaration like:

int *ip

The ip and *ip are just different names for different things. ip refers to one thing and *ip to something else. In fact ip is, itself, a reference to the other thing.

Summary:

• Names are simple or constructed.

• Names refer to things.

• A name can refer to one thing at a time, but it can be changed at another time

• A name can refer to one thing in a give place (at a time) but can reference a different thing (simultaneously) in a different place.

This is exactly, I think, how names behave in the real world. It is also how variables behave when implemented on current kinds of hardware.

---

Caveat. If you are teaching implementations, specifically, such as in a compiler course, the hotel room idea is fairly valid, though most hotel rooms can hold more than one thing at a time. So, even there, the metaphor has unfortunate possible misleading consequences.

Answer 6

I don't think you can say any analogy is "right" or "wrong" across the board. Whether an analogy makes sense or not depends on the context of both the teacher and the student, and I don't think we can tell you whether any particular analogy is "right" for your context.

I personally avoid analogies when I'm talking about using and creating variables. I explain that a variable is a name that holds a value. I don't think that an analogy would make that more clear, at least for my context.

That being said, one of the most effective resources I've seen for explaining Java variables are these two articles:

• Cup Size -- a story about variables
• Pass-by-Value Please (Cup Size continued)

These articles use an analogy of variables being coffee cups with names written on them. In this analogy, Object references are remote controls that you put inside a cup, and it's one of my go-to references when explaining that Java is pass-by-value.

Answer 7

I have to teach basic computer skills, applications and using online platforms in advance of programming this year.

Since I will do some Spreadsheet work, I plan to initially use a cell to demonstrate an example of a variable...

• It has a (cell) reference (which can be changed to something with semantic meaning)
• It has a value (including Null/None/"nothing"
• this value has a "type" or "class"
• There can be sub-classes (number is parent to int and decimal etc) and different langs define these differently
• Another cell can reference that variable by it's reference
• As @TooManyCooks indicates, it is possible to demonstrate aliasing with a named cell (something I had not thought of)

We can reference a cell with a formula in it- this formula may represent a function which "takes in" something (perhaps) and "returns" something... We can link sheets, so a variable can refer to something that "lives" in another tab, or file, or image or web address... thus variables refer to other "things" or "objects" which can be... anything (in theory).

These ideas relate to what @Steve and @Buffy have already identified.

I've been thinking that some concepts of functional programming are present in Spreadsheets, and some OOP concepts are present in Database... since I have to teach both in advance of programming this year, perhaps these concepts can be conveyed in advance.

Another useful tool may be the visualizer as this will let you "see" it in action using a range of languages.

Again you can see the variable has a type, reference, value etc.

Hope that this might prove useful or prompt other ideas in addition to all of the fine suggestions already provided.