Fog Creek Software
Discussion Board

The Trouble with Pointers

[I hope this looks okay, or that I can edit it...]

My company works with ontologies - a play on the philosophical term ontology, referring to inventories of entities in the world and their relationships and characteristics.  One of the motifs I see pervading this work is confusion between an entity, and its name.

Entities include all sorts of things - birds, desks, emotions, stock tips, rates, enzymes, people.  Take people, for example.  People have names (typically).  Names such as Bob.  What can you say about Bob?

<li> Bob has three letters.
<li> Bob goes fishing in his free time.

Syntactically, both sentences make sense.  Semantically, the <i>referent</i> of "Bob" is different.  In one place, "Bob" refers to the word "Bob".  In the other, "Bob" refers to - (drum roll) - Bob.  Let me repeat that.

"Bob" refers to Bob.

Look at that sentence.  I claim that if it doesn't feel quite right to you, you might be one of those elite Joel mentions, who can program with pointers!  Let's try this sentence:

"Bob" refers to the person named "Bob".

That should feel a little better.  A bit tautological, though.  It has something to do with the meaning of "refers to".  "X refers to Y" is (in English) supposed to mean that X is something called a name, Y is some entity, and the writer is moreover letting you know that the name X ["Bob"] can now be used as a handle, or reference, to the entity Y [the person named "Bob"].

The trouble is, Y is expressed in English, too.  Even if you change the language, it's expressed in that language.  At the very least, it's some sequence of squiggles on paper (or your CRT or whatever).  Y is itself another name, or handle, or reference.  <i>How do you know what </i>Y<i> means??</i>  Where's the magic line connecting the phrase on the paper to that guy sitting on the riverbank?  Ultimately, the writer is relying on you to have enough previous knowledge of the language to construct that magic line.  The only way to be surer about the connection is to embed Bob in the paper.

Luckily, the whole Goldberg system of using squiggles to refer to real (or even imaginary) things miraculously works.  Virtually any person automatically links words or glyphs with concepts, typically within two years after birth.  We have proof of this happening for millennia.  It's probably instinctive.  The downside is that it's probably <i>so</i> instinctive that most of us forget we're doing it, to the point that a sentence like

c* refers to the value stored at the memory location stored in c.

gets many people hopelessly stymied.  Programming in general involves several layers of abstraction, of squiggles referring to other squiggles, which are transformed into yet more squiggles at the behest of previously transformed squiggles inscribed long ago.  And then we throw pointers on top.  No wonder people get mixed up!

In short, pointers deal with a very deep, deep level of human cognition.  This is why I think it's so hard for most people.  (It might explain a good deal of math angst, too, for that matter.)

Paul Brinkley
Thursday, October 18, 2001

[Uh-huh.  HTML's no good here, I see.  Oh well.  Better luck next time...]

Paul Brinkley
Thursday, October 18, 2001


Anon Lover
Saturday, October 20, 2001

Why don't people have hard times with street addresses, or conceiving the dark idea of giving each person a bar code?

Is the teaching at fault?  I've looked at some pretty mean computer books, especially from QUE, and I can see how a below-average teacher can be pretty bad.  All that needs to be done is not use K&R when teaching C...

Saturday, October 20, 2001

You say people can deal with street addresses better than with pointers.  I wonder if that's true.  Both are references to locations where something may be found.  That's a plus.

One of the "features" of pointers is that they may themselves be stored in a location, with its own pointer.  Street addresses may also be stored in mailing lists.  Now, many mailing lists tend to be used by people trained to work with mailing lists, but a lot are also used by volunteer efforts, people planning parties, or people organizing their rolodexes.  Not a big deal.

Another feature of pointers is that you can do arithmetic with them.  Get a pointer to an array whose length you know, process the array member at that pointer, increment the pointer, do it again, and so on, walking through the array.  Can you do the same thing with a street address?  You can try, but it's very risky.  The next number over might be a business or a home (type mismatch), or may be non-existent (SEGV), or may actually be two houses over because there's a 104 1/2 in between (???).

So IMO, they're not the same.  Given that, it might be one way to attempt to teach pointers, even so, to aid understanding.  We just have to be careful not to draw the analogy too far.  :-)

Paul Brinkley
Monday, October 22, 2001

I've been working on a project where we're creating visual pointers to variables in an application that is to be used by non-programmers. So, over the last few weeks, I've been trying to come up with a good metaphor for pointers.

The best I've come up with so far is the 'Shortcuts' in Windows. File icons with the little arrow in the lower left of the icon indicate to users that this isn't the real file but a pointer to the real file (although the term pointer isn't used).

At first I thought this was a great solution, since most users would be familar with this metaphor, but recently I've wondered if typical Windows users know what a short cut is or what a file icon with a little arrow means.

Has anyone seen any usability experiments involving shortcuts?

Michael Bean
Monday, October 22, 2001

<recently I've wondered if typical Windows users know what a short cut is or what a file icon with a little arrow means.>

I haven't seen any, although I'd be surprised if Microsoft doesn't have one somewhere.  Not that they'd tell you about it. :)

My -guess- is that the majority of present day-to-day Windows users have no idea what the difference is between a program and a shortcut to a program.  Hell, a lot of them haven't quite worked out the whole concept of "folders" yet.

When I was little, my dad used to play a game with me called Treasure Hunt.  He would hide something somewhere and then leave a series of clues.  Each clue told where the next clue was, and the last clue told where the treasure was.  He gave me the first clue.

So, he hides the treasure in the cast iron skillet under the stove and gives me the clue "The blue glove in the closet." Inside the glove is a clue that says "Page 168 of Winnie-the-Pooh."  Pooh's clue is "Cast iron skillet under the stove."

I've used this as an analogy in the past with some success.  A pointer is a "clue" that tells either where the treasure is (single indirection) or where the next clue is (multiple indirection).

Chris Dunford
Friday, October 26, 2001

I remember my pointer revelation.  It was some time ago, when programmers actually had mentors.  They didn’t call them mentors at the time.  They called them bosses who had a major interest that you completed your programs, that they worked, that they could be maintained, and most of all that you became a more productive programmer.

I wish I could remember the routine I was working on.  I coded all day, many lines of code.  My boss walked by and asked what I was working on.  After looking it over he said, “You know you can do the same thing with 10 lines of code.”  Then he showed me.  Well, that was the day I “got” pointers.  We didn’t call them “pointers” then.  We called them “indirect addresses” or the address that contained the address.

Terry Kearns
Sunday, October 28, 2001

*  Recent Topics

*  Fog Creek Home