Re: pointers?

Bernd Paysan wrote:

Colin MacIntyre wrote:


After studying Forth for about a month now, I'm starting to look at other
languages to see what's up. I read somewhere that at one point MIT's
computer science dept. had a 70% dropout rate because people couldn't get
a handle on "pointers", citing it was too abstract a concept.


Ah, the problem is the other way round. A pointer is a too tangible concept
to be understood by typical computer scientists. I mean, here we all know
what a pointer is: It is the address of the data (the number on the address
bus to the memory). There's absolutely nothing abstract in pointers.

Algol-like languages abstract from the real things that go on inside
computers. You have (somewhat) abstract data types like structures and
arrays. Take the C array: if you write

int array[5];

you'll get an array of five integers, and you can access some element with
e.g.

array[3]

(both left and right hand of an assignment). But what's really happening is
that array is a pointer to a memory space with 5 integers space before the
next variable starts. So if you say

printf("%x\n", array)

you won't get the 5 numbers printed, but the address of the array. Since at
that point, computer scientists at MIT obviously have no idea what the real
hardware does to perform things like array[3], this number is a concept
that doesn't fit into their world. The pointer operations are also cast
into strange words like "dereference" where you mean "fetch" and such. This
is, because the tutors are trying to make the pointer look as if it was an
abstract concept like a structure or an array. But it isn't. It's a
down-to-the-bits concept.

Yep. To the assembly language programmers who were the first generation adopters of C, this mental mapping was very tight.

If MIT taught students first how a computer works, and then how to use a
more abstract language later, 70% would get it. And the 30% that would fail
probably are those that pass now ;-).

Back in the kilobyte and punch card era MIT did it that way (I was there). But what Prof. Donovan called "mathematics envy" gained dominance when terminals and megabytes became cheap enough to teach more than a few students LISP.


My own learning-to-program history had C (K&R) in before Leo's SF. I thought
I somewhat got it, but had a very icky feeling about pointers. It was also
quite obvious that this is a language close to the hardware, which made me
feel uncomfortable. Then I read SF. My impression was that this was a very
simple language, and that it contained absolutely *nothing* which is
especially "close to the hardware" as the pointers in C. Until I realized
that C's "complicated" pointers are really the things you pass to @ and !
in Forth. And then I read K&R again, finding out that C is indeed quite
simple (apart from hiding that fact), and contains nothing more than Forth;
rather less in fact.

Depends a bit on the machine you're using. Forth's model maps better to machines with simple addressing and fixed length words. C's model handles variable length words and complex addressing schemes better. So in the beginning, Forth gained the most traction on machines like the IBM 1130 and the Data General Nova. All of the early C implementations were on machines with more complicated addressing schemes.

On a GE 600/Honeywell 6000 series mainframe it really wasn't a good idea to try to do address arithmetic with ordinary integer addition: you really needed to use the EPP instruction. This was especially important in the later versions of this architecture, with bit offsets in the the part of the word representing the most significant bits of an integer (!). Natural in C (where pointers and integers are different things), unnatural in Forth (where they are the same).

The downside of this is that once you have understood that thing, you can
write C and C++ programs at ease with features none of you coworkers will
ever understand. I've written a C++ program which uses pointers to virtual
functions (yes, they exist). None of my coworker had known that they exist,
nor had they the slightest idea what the program would do with them.

It's "deja vu all over again". In the US we had a crazy educational theory called the "New Math" that was supposed to improve students' understanding by starting them out with abstract "fundamentals". It was a disaster, producing a generation of students who often found division impossible without a calculator. The problem is that only in mathematicians' fantasies does understanding of math procede from the abstract to the concrete: in real life mathematical understanding involves learning from concrete behavior and then modeling it with abstractions.

Unfortunately, mathematics envy still rules computer science.

--
---
John Doty, Noqsi Aerospace, Ltd.
---
His diagnosis of the hostility ... reflects the willful blindness of the invader who assures himself that the natives are only made unfriendly by some other provocation than his own. -Barbara W. Tuchman
.

Relevant Pages

  • Re: Operator overloading in C
    ... All development of C as an independent language has ... making any changes or improvements to the standard ... The lack of a counted string data structure, ... Pointers can't be used for arg1 or arg2. ...
    (comp.std.c)
  • Re: compilation of ms crypto api program
    ... >> People tend to do radically stupid things with pointers in any case. ... > you were going to use a string array with 255 elemenst, ... > compile time error. ... can be completely eliminated by using an appropriate language. ...
    (sci.crypt)
  • Re: pointers?
    ... There's absolutely nothing abstract in pointers. ... Take the C array: if you write ... more abstract language later, 70% would get it. ... quite obvious that this is a language close to the hardware, ...
    (comp.lang.forth)
  • Re: first-class types
    ... definition must still use pointers at some point internally, ... Copying a very large array would be ... The language can leave this to the programmer to decide, ... How did the world of serious programming get by before pointers ?... ...
    (comp.arch)
  • Re: Best Ref-counting algorithms?
    ... The programming language is designed so that most data ... a:=0 #now the array magically disappears and a is an int ... It doesn't work well however when the language allows *explicit* pointers: ... because explicit pointers aren't used so much, and when they are they are ...
    (comp.compilers)