Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.society.futures
Subject: Re: C's sins of commission (was: (pssst...fortran?))
Message-ID: <63973@lanl.gov>
Date: 24 Sep 90 20:58:31 GMT
References: <9009220848.AA00539@wheat-chex>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 174

From article <9009220848.AA00539@wheat-chex>, by bson@AI.MIT.EDU (Jan Brittenson):
> [...]
> Jim Giles:
> 
>  >> 	1. Pointer range check (to see if a buffer crosses page
>  >> 	   boundaries, for instance).
> 
>  > Well, without pointers, why do you need a pointer range check?  Computing
>  > the range of something that doesn't exist seems a little silly.
> 
>    Pointers _are_ addresses, and nothing else.  [...]

Yes, but you're missing the point.  Surely what's wanted above is
a reliable method to allocate buffers that don't contain page
boundaries or other unpleasant hardware dependent things.  This
is clearly the job of the memory manager - to give the programmer
adequate support for machine dependent problems of this kind.
The programmer should merely have to allocate memory (with the
right mode flags on his request, and the manager should return
an allocated object with the right memory boundary properties
(whether this means "doesn't cross a boundary", or "starts on
a boundary", etc.).  And, as I've pointed out before, dynamic
memory allocation probably should not involve programmer visible
pointers.

> [...]
>  > Now, if you're talking about non-standard extensions to C which would
>  > allow you to do this stuff - then any other language can contain the
>  > same non-standard extensions.
> 
>    Extensions, or non-uptight about pointer typing, call it whatever
> you like.

Ah, but I'm still not convinced that the language of the future should
even _contain_ pointers.  No one has yet provided an example of a user
level application that _requires_ them.  System level applications also
_mostly_ don't need them.  And, like GOTOs in flow control, pointers
in data structuring tend to result in spaghetti.  If this is deliberate,
it on the programmers head.  If someone just get some wires crossed though,
I'm willing to apportion at least _some_ of the blame on the language
feature itself.

> 
>  >> [...]
>  >> 	2. Calculate physical addresses for DMA controllers.
> 
>  > Why should I care?  The system/environment should be able to give me the
>  > address if I need it.  But, how do I use a raw address anyway? [...]
> [...]
> ...or like C, which most certainly is more defined than assembler!

Once again, you've missed the point.  Not even the systems programmer
that has to write the access routines for the DMA controller _cares_
what its address is.  What he wants is to be able to say "DMA_port=command"
whenever he needs to.  Why not have the compiler (or the loader) contain
a list of all the hardware-specific addresses with some mnemonic names
that the programmer can just declare and use?  Why does the programmer
have to mess with addresses at all?

> [...]
>                Neither of these groups would have particular use for
> your proposed language - the application people would ask you what
> syntax applies to selecting records in a database, [...]

I don't understand the objection.  I give the programmer _more_ clear,
explicit, direct, data structuring tools that C has, remove pointers
(which still haven't been proven useful), and you claim it will be harder
to use.  The database person would probably use whatever syntax he
_presently_ uses except without the need for dereferencing on the linked
list types of stuff.  Give me a _specific_ example of what you think
would be hard.

> [...]                                             while the system
> people would ask you how to set up 2D bitblt operation in a graphics
> device, [...]

Again, the same way they do now - except the graphics device itself
would now be a named object and the programmers would no longer have
to pretend the absolute address of it was somehow part of their task.

> [...] or how to create a channel program in a mainframe environment.

Oh?  You can do that in C?  On the Cray for example, channel programs
aren't even written in the same _machine_ language.  The C compiler
doesn't even generate channel code.  Not at all.  (Maybe there's a
different C compiler that does, but I've not seen it.)  What does
this have to do with the discussion about whether pointers (or any
other feature) should be incorporated in a programming language?

> [...]
>    For sure, some of the work done by system folks falls somewhere
> in-between. But I seriously doubt programming efficiency or
> maintenance would be improved to any degree worth mentioning by
> forcing everyone to learn Yet Another Language and an entirely new set
> of idioms when the previous ones are considered quite sufficient.

Yes, I can see your point.  Once you've learned a language it _is_
kind of like a trap.  You begin to see only how _that_ language works
and not how to solve your _actual_ problems at all.  This kind of
thing has happened _many_ times before in history.  The great modern
bridges were not built by the same people who built the great ancient
ones - or even their intellectual descendents.  Stone masons couldn't
_ever_ span distances over 200 feet - yet they considered their work
to be "quite sufficient" for all practical bridge building work.

Yes, perhaps the current generation of C programmers will have to retire
before a fresh group - without the biases - can address the problem from
new and more effective points of view.

> [...]
>    Can you give me one example of a project you or a first-hand
> reference has been involved in that falls between the two major
> categories I've outlined above, and which by itself constitutes a
> project large enough to warrant not simply making do with what you've
> got and are used to, and possibly for an employer to require
> experience with your language as desirable?

Yes.  Our organization is currently switching _TO_ C/UNIX from something
else.  All the trouble you predict is indeed upon us - the retraining, the
expense, the incidental blunders along the way.  Unfortunately, after all
this, is it becomming clear that C/UNIX are worse that what we had.  Fewer
features, harder to use, _SLOW_.  Those of us that _knew_ C/UNIX before
the conversion warned that this would be the case.  But, both users and
management succumbed to the hype. (Note, there are still people here that
think we did the right thing.  In a couple of years all this trauma will
be behind us, they say.  Then, we will have advantages of a industry
standard system, they say.  Unfortunately, we had to add so much non-UNIX
stuff to the system - just to make it marginally acceptable - that
switching to any other UNIX system later would be just as traumatic as
what we are doing now.  Oh, well)

>  >> [...]  > 	3. Sort a linked list on addresses of some data
>  >> pointed to > 	 from within the node. Or to keep it sorted as new
>  >> (addresses > 	 of) data is added.
> 
>  > I guess you'll have to tell me how this differs from sorting on the
>  > index of the data within an array or sequence.  Since the sequence is
>  > dynamic, ...

I don't understand your answer on this.  It seems to me that the
objections you raise are _MORE_ applicable to pointers, not less.

>  >> [...]
>  >> 	4. Implement malloc()/free().
> 
>  [... I said standard C can't do it ...]
>
>    No doubt you're correct. Implementation is fairly trivial in
> "nonstandard" C, and I fail to see how it could be made easier or more
> "defined" without any pointers (i.e. explicit object addresses) at all?

Actually, the implementation is quite trivial. period.  I don't see
why we have to mung-up the language design to do something which should
be done in assembly for efficiency anyway.  Even so, the system kernel
starts up a tool called the memory manager which handles all the rest
of memory as a single large array, using indices relative to wherever
the kernel ends.  Where's the user-visible pointers in that?  The run-time
memory manager for the I/O library and application programs works the
same way - it has all the memory that the system allocated for the heap
in one large array.  The only piece that needs to have _raw_ pointer access
is the part that performs the alias - that is, the copy of the reference
when the allocation process finishes (or, when the deallocation process
starts).  This little fragment amounts to less than a half-dozen instructions
on most machines -surely you can't object to _that_ much assembly in an
operation that is _blatantly_ machine dependent.

> [... discussion about text string efficiency.  I refuse to argue     ...]
> [... any further.  It is clear that _some_ people regard it as an    ...]
> [... important issue.  You don't.  I regard it as a subset of the    ...]
> [... sequence type construct - Which has other applications: most    ...]
> [... linked lists in C that I encounter would really have been _much_...]
> [... more efficient as sequences - for example.                      ...]

J. Giles