What's the position of pointers

[Richard Tobin]

What exactly does "intrinsically more portable" mean?

[/QUOTE]

For example, it isn't restricted to machines that operate on binary
power word lengths.

Presumably you don't mean that. Nothing stops C having word lengths
that are not binary powers, such as 36. But in any case:

C can run on machines with any internal representation. The system
just has to make the user-visible behaviour meet the standard. A
decimal machine can run C provided that, for example, unsigned
arithmetic is performed mod 2^n.

-- Richard

 

[CBFalconer]

Presumably you don't mean that. Nothing stops C having word lengths
that are not binary powers, such as 36. But in any case:

C can run on machines with any internal representation. The system
just has to make the user-visible behaviour meet the standard. A
decimal machine can run C provided that, for example, unsigned
arithmetic is performed mod 2^n.

Yes, sloppy wording by me. I was actually referring to the *_MAX
values in <limits.h>. Each active bit in such a representation has
to represent a binary power for positive values, so the aggregate
can express 0 through 2**n-1. The point is that C can't be used in
a decimal or trinary machine. Admittedly there aren't many such
lying around these days.

Please don't remove attributions for material you quote. I fixed
this.

 

[Richard Tobin]

C can run on machines with any internal representation. The system
just has to make the user-visible behaviour meet the standard. A
decimal machine can run C provided that, for example, unsigned
arithmetic is performed mod 2^n.

[/QUOTE]

Yes, sloppy wording by me. I was actually referring to the *_MAX
values in <limits.h>. Each active bit in such a representation has
to represent a binary power for positive values, so the aggregate
can express 0 through 2**n-1. The point is that C can't be used in
a decimal or trinary machine.

C can be used on those machines. The implementation just can't use
the native arithmetic unmodified in all cases.

-- Richard

 

[Chris Dollin]

You do not recommend an entirely different language to someone to learn
something as core and basic is pointer usage. The basics ARE simple and
any teacher worth his salt can get it across with a debugger and an OHP
in 2 or 3 minutes.

Or without a debugger. One might want a debugger to show how your
local implementation does things; one doesn't need one to explain
what they /mean/. (This is especially useful when it means one isn't
having to explain a debugger at the same time as a programming
language.)

 

[Richard]

Or without a debugger. One might want a debugger to show how your
local implementation does things; one doesn't need one to explain

Normally one is only interested in ones local implementation. But one
can learn what a pointer is and how dereferencing works etc etc on ones
local implementation before moving on to "platform independence".

what they /mean/. (This is especially useful when it means one isn't
having to explain a debugger at the same time as a programming
language.)

I'm not quite sure from what angle you are coming there. A debugger is a
tool that shows values of pointer and the memory to which they point (in
the real world system I have used). If you are teaching a language then
using one is, in my small world, part and parcel of that learning
experience primarily (as I have repeated many times here) I think using
printf in code to "experiment and debug" is amateurish at the very best
for reasons well documented. Yes, yes, it does have its uses if and when
a debugger is not available.

I can see this thread being hijacked by the ISO righteous brothers so I
will kill it now.

But I know from experience that teaching pointers (in any language) is
trivial if you use the right tools and examples and dont try to be too
clever too soon. It really is trivial and basic to any understanding of
programming, efficiency and underlying processing.

 

[Chris Dollin]

Normally one is only interested in ones local implementation.

No, /mornally/ one isn't interested in one's local implementation;
one is interested in teaching or understanding the language & code
one is writing.

But one
can learn what a pointer is and how dereferencing works etc etc on ones
local implementation before moving on to "platform independence".

Oh, yes. We just don't have to deal with the vagaries of the local
implementation while doing so. I don't understand your apparent
obsession with /starting/ with implementation-specific details
when

It Is Not Necessary And It Is Distracting.

I'm not quite sure from what angle you are coming there.

I'm coming from the angle of not having to teach several things
at once.

A debugger is a
tool that shows values of pointer and the memory to which they point (in
the real world system I have used).

No doubt.

If you are teaching a language then
using one is, in my small world, part and parcel of that learning
experience primarily (as I have repeated many times here)

Yes, you have repeated this. As a teaching technique I think it
is ... significantly sub-optimal. (In something like Pop or Lisp
or Smalltalk, where the debugger is Just More Code, and one often
works by write-a-bit run-a-bit, I'd be more relaxed.)

I can see this thread being hijacked by the ISO righteous brothers

Hallelujah! Fear you my so-called singing the ISO chorus!

so I will kill it now.
Optimist.

But I know from experience that teaching pointers (in any language) is
trivial if you use the right tools and examples and dont try to be too
clever too soon. It really is trivial and basic to any understanding of
programming, efficiency and underlying processing.

Yes, it's perfectly straightforward.

 

[Richard]

No, /mornally/ one isn't interested in one's local implementation;
one is interested in teaching or understanding the language & code
one is writing.

You are being purposely difficult. In the context of TEACHING. i.e it is
on THAT implementation that one is using tools to demonstrate the
theory. I have done a lot of it. And successfully (according to 3rd
party adjudication).

Oh, yes. We just don't have to deal with the vagaries of the local
implementation while doing so. I don't understand your apparent
obsession with /starting/ with implementation-specific details
when

It Is Not Necessary And It Is Distracting.

What are you talking about? How can I NOT use implementation "specifics"
when I am demonstrating it ON an implementation. Are you seriously
suggesting that showing someone how pointers work in a debugger using
hex representations of a memory address is going to ruin them for ever?

I'm coming from the angle of not having to teach several things
at once.

You are erecting meaningless straw men to support your rather strict
approach to C. Showing a pointer in a debugger is hardly killing
them. Did you never hear of learn by doing? Holy cow. The benefits of
them seeing and using these things on a real machine in a real
development tool totally obliterates any "added complexity". I hae sat
in lectures on languages with no hands on and I fall asleep in no
time. Maybe you are differnet. Most people are not. most people like the
practical approach. a 2 hour lecture on semiconductors is easily
improved on by an hour in a lab with an oscilloscope.

No doubt.

You're becoming a bit of a prig and a bore. You deny that using a
debugger to demonstrate pointers is useful? Really?

Yes, you have repeated this. As a teaching technique I think it
is ... significantly sub-optimal. (In something like Pop or Lisp
or Smalltalk, where the debugger is Just More Code, and one often
works by write-a-bit run-a-bit, I'd be more relaxed.)


Hallelujah! Fear you my so-called singing the ISO chorus!


Optimist.

Indeed ...

Yes, it's perfectly straightforward.

Yet you deny that using hands on approach makes it even easier? Strange.

--

 

[Chris Dollin]

You are being purposely difficult.

No, it comes naturally.

In the context of TEACHING. i.e it is
on THAT implementation that one is using tools to demonstrate the
theory. I have done a lot of it. And successfully (according to 3rd
party adjudication).

I have never said that you haven't. What I'm saying is that I
don't think that's the best way to teach pointers, because it
introduces unnecessary details & tools.

What are you talking about?

Using a debugger in teaching pointers (for C; I make no claims
about their utility or otherwise in teaching assembly language).

How can I NOT use implementation "specifics"
when I am demonstrating it ON an implementation.

You can avoid mentioning the implementation-specific details of
how pointers and pointer operations are represented. I'm happy
to grant that you need an implementation-specific implementation
/of C/.

Are you seriously suggesting that showing someone how pointers
work in a debugger using hex representations of a memory address
is going to ruin them for ever?

Do you think I said anything closely resembling that? Because
I didn't. This is a strawman.

/My/ claim is that it /is not necessary/ to use a debugger to
teach about C pointers, and that they can be taught just as
effectively debugger-free [in general; there will be outliers
in both directions].

You are erecting meaningless straw men to support your rather strict
approach to C.

No, I'm adding an additional feature to the argument.

Showing a pointer in a debugger is hardly killing them.

And I never said otherwise. Whose strawman is this, then?

Did you never hear of learn by doing?

Never. The idea is completely strange to me. I have no idea
what you're talking about.

Holy cow.

I suppose it has some aspects of a religious argument.

The benefits of
them seeing and using these things on a real machine in a real
development tool totally obliterates any "added complexity". I hae sat
in lectures on languages with no hands on and I fall asleep in no
time.

Strawman. The conflation of "without a debugger" and "no hands-on"
is yours, not mine.

Maybe you are differnet. Most people are not. most people like the
practical approach.

Some do, some don't; that's a separate question of learning styles.

a 2 hour lecture on semiconductors is easily
improved on by an hour in a lab with an oscilloscope.

I suspect that depends on the topic at hand.

You're becoming a bit of a prig and a bore. You deny that using a
debugger to demonstrate pointers is useful? Really?

I'm claiming it is /unnecessary/ and that they (and the rest of C,
as it happens) can be taught /without/ resorting to using a
debugger. In general. If one doesn't want to clutter the student's
minds with implementation-specific details.

Yet you deny that using hands on approach makes it even easier?

No; see above.

Strange.

From whom demons flee.

PS "Never. The idea is completely strange to me. I have no idea
what you're talking about." is NOT SERIOUS. Just in case anyone
thought otherwise.

 

[Richard]

No, it comes naturally.


I have never said that you haven't. What I'm saying is that I
don't think that's the best way to teach pointers, because it
introduces unnecessary details & tools.

I know you have. And I say that the tools give an advantage which
totally overshadows any overhead to learn them.

Can I ask you how many people you have taught computer languages?
Without banging my own drum I have taught C, Assembler (68000 and x86),
and others and have a reasonable track record.

I *know* that in my style of teaching that pointers and similar are no
more difficult that the concept of a while loop for example when taught
using the tools to do the job.

Possibly you prefer to sit there at a chalk board and waffle on for
hours with diagrams and arrows? If that works for you then grand. It
never did for me or the people I had been asked to get up to speed.

But I know where this is heading. its the old "debuggers are evil"
mentality again and "hard to use". Well they are not and they are
not. they are trivial to use and add much to the development/learning
process.

 

[Kenny McCormack]

But I know where this is heading. its the old "debuggers are evil"
mentality again and "hard to use". Well they are not and they are
not. they are trivial to use and add much to the development/learning
process.

Richard, just for the fun of it, I am going to try to explain how the
other half thinks. I can say this, because I am one of them. This is
going to sound strange, but in the aspect, me and the CLC regs see the
world the same way. And, it is pretty clear that you see it the other
way.

We (myself & the CLC regs) learned computing the hard way - without
debuggers and without web pages detailing everything in language so
detailed and full that the average 4th grader can get it. It was tough
and mean and we liked it! We liked it precisely because most people
couldn't/wouldn't and never will get it. You had to *be* somebody to be
able to get computing - to get the idea of pointers and memory, without
the luxury of debuggers and web pages and stuff like that. That's the
way we grew up, and, as I've said, we liked it! And we can't really
imagine there being any fun in the way things are now.

You, on the other hand, are from the modern school. You think that,
given the tools (and the web pages) that are available now, anybody can
learn to program. And you're right. Most current programmers are what
we like to call "re-treads". People from some other discipline that
didn't work out, they pick up "Access In 30 Days" and boom! they're a
programmer. That's the way the world is now.

But we don't have to like it.

 

[Richard]

Richard, just for the fun of it, I am going to try to explain how the
other half thinks. I can say this, because I am one of them. This is
going to sound strange, but in the aspect, me and the CLC regs see the
world the same way. And, it is pretty clear that you see it the other
way.

We (myself & the CLC regs) learned computing the hard way - without
debuggers and without web pages detailing everything in language so
detailed and full that the average 4th grader can get it. It was
tough

Me too. Sorry. My first language was Z80 machine code entered through a
monitor on a Nascom.

and mean and we liked it! We liked it precisely because most people
couldn't/wouldn't and never will get it. You had to *be* somebody to
be

Me too. But my "likes" in hardcore computing are not the best for nOObs
and new programmers.

able to get computing - to get the idea of pointers and memory, without
the luxury of debuggers and web pages and stuff like that. That's the
way we grew up, and, as I've said, we liked it! And we can't really
imagine there being any fun in the way things are now.

I know. But there can be. Take gd for instance. Yes it does take some
learning. If you want to be a wimp you can use ddd for it ...

You, on the other hand, are from the modern school. You think that,
given the tools (and the web pages) that are available now, anybody can
learn to program. And you're right. Most current programmers are
what

Actually I do not. I just do not see the reason for doing it the hard
way when there is an easier way. The majority of the development should
be thinking and designing not tracking down horrible bugs.

we like to call "re-treads". People from some other discipline that
didn't work out, they pick up "Access In 30 Days" and boom! they're a
programmer. That's the way the world is now.

But we don't have to like it.

I understand fully.

But to recognise that these tools are good for others is paramount. What
I dont like from some of the clowns here is that these tools are not
beneficial to the majority or that they have no place. They are and they
do.

 

[jameskuyper]

Richard wrote:
....

Normally one is only interested in ones local implementation.

That has not been my experience. I've seldom had any need to know
anything about pointers that was specific to a particular
implementation while programming in C. Interfacing between C and
assembler, for instance, is a different matter - for that kind of work
you have to know the details. However, if you can use C exclusively in
your program, it generally insulates you from needing to know such
details.

Two decades ago I did have to learn about near and far pointers and
how they were implemented, because I was programming for DOS/Windows,
but I generally tried to write my code, even for those platforms, so
it avoided any explicit use of that extension. I haven't had to worry
about such issues for more than 15 years now.

... But one
can learn what a pointer is and how dereferencing works etc etc on ones
local implementation before moving on to "platform independence". ...

Yes, but it's easier to explain those things in a platform independent
fashion, without going into the complexities of platform-specific
issues. You can add in the platform-dependent aspects as and when
needed (in an introductory course, "when" is probably "never").

 

[jameskuyper]

You are being purposely difficult. ...

No, we just have a different perspective from you. To us, the C
language is a simple thing, to which the complexities of
implementation-specific details are a low-priority addition. To you,
the detailed characteristics of a particular implementation of C are a
simple thing, to which the complexities of writing portable code is a
low-priority addition.

... In the context of TEACHING. i.e it is
on THAT implementation that one is using tools to demonstrate the
theory. I have done a lot of it. And successfully (according to 3rd
party adjudication).

But there's no need to emphasize any of the implementation-specific
details, unless it's a really unusual machine. Your students stand a
very good chance of ending up working on machines quite different from
the one you're teaching on. Platform-specific features should be a low
priority; there's way too many platform independent things that they
should learn first, because they are more important than platform-
specific features.

 

[Ben Bacarisse]

No, we just have a different perspective from you. To us, the C
language is a simple thing, to which the complexities of
implementation-specific details are a low-priority addition. To you,
the detailed characteristics of a particular implementation of C are a
simple thing, to which the complexities of writing portable code is a
low-priority addition.

I marked this message because I felt I need to explain why I disagreed
with Richard. I am glad, now, that I waited a bit because I could not
have said it better.

 

[Kenny McCormack]

I understand fully.

But to recognise that these tools are good for others is paramount. What
I dont like from some of the clowns here is that these tools are not
beneficial to the majority or that they have no place. They are and they
do.

But, for the reasons I've just described, you'll never get them (or me!)
to admit it.

You'd just be wasting your breath.

 

[Richard]

But, for the reasons I've just described, you'll never get them (or me!)
to admit it.

You'd just be wasting your breath.

Aha. Now I fully understand you. You are not defending your
reasonings. They are just your (hard earned) preferences and reasoning
be damned. That I can except.

 

[Flash Gordon]

No, we just have a different perspective from you. To us, the C
language is a simple thing, to which the complexities of
implementation-specific details are a low-priority addition. To you,
the detailed characteristics of a particular implementation of C are a
simple thing, to which the complexities of writing portable code is a
low-priority addition.

<snip>

To explain pointers I would (and have) started off from the point of not
needing a programming language let alone the details of one specific
programming language. From this perspective I have managed to not only
explain pointer to someone who does not know how to program, but also
explain buffer overflows and why they don't always cause a visible
effect to someone who does not know how to program. IMHO the concept of
pointers is far too simple to need to go in to real detail unless you
are programming in assembler or have enough experience to start dealing
with fixing really obscure bugs.

 

[Kenny McCormack]

There is another side to this argument, but I won't go into it at the
moment.

Aha. Now I fully understand you. You are not defending your
reasonings. They are just your (hard earned) preferences and reasoning
be damned. That I can except^Waccept.

Yes. The difference between me and the CLC regs is that I am honest
about it.

 

[Chris Dollin]

I know you have.

Then stop arguing with me as though I'd said something different.

And I say that the tools give an advantage which
totally overshadows any overhead to learn them.

That is at least a respectable argument. (We differ about the
value of the advantage, but you already knew that.)

Can I ask you how many people you have taught computer languages?

Not many; it's been too long since I had to.

I *know* that in my style of teaching that pointers and similar are no
more difficult that the concept of a while loop for example when taught
using the tools to do the job.

Good. FRichard, I really don't have a problem with your ability
to teach pointers or C or whatever, just with your claims that
it's /necessary/ to introduce these implementation-dependencies
to teach them effectively. May claim is, and has been, that it's
not /necessary/, and I also believe that it's extra load for
students to handle those implementation dependencies and learning
how to use the debugger.

You have said that you use the debugger routinely, so it's not
surprising to me that you value it and teach how to use it. I
don't value it as much as you, and I wouldn't /dream/ of using
it as a teaching tool in the early stages of teaching C. I
think such concentration on low-level details makes it harder
to teach the "big picture"; because C is so strong in dealing
with the low level, it's /really important/ to show how to
handle the less-detailed stuff.

What you see as a strength, I see as an issue. I don't think
we're likely to change /those/ views. I'm not arguing to
convince you (although of course that would be nice); I'm
arguing to try and pick around the subject and expose it so
that people can get a sense of what the options and considerations
are and take away whatever they find valuable.

Possibly you prefer to sit there at a chalk board and waffle on for
hours with diagrams and arrows?

You do an awful job of guessing what it is I'd do if I were
to seriously try and teach someone C nowadays. Sorry.

But I know where this is heading. its the old "debuggers are evil"
mentality again and "hard to use". Well they are not and they are
not. they are trivial to use and add much to the development/learning
process.

I know you think so, and you know I think otherwise, and we've both
vented on thsi topic before.

 

[Nick Keighley]

Richard wrote:


Hallelujah! Fear you my so-called singing the ISO chorus!

myself, I go back to the older, deeper ANSI Chorus!!

Fnar Fnar Fnar!