🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #1676

Re: C's sins of commission

#1676
From: Norman Graham
Date: Wed, 10 Oct 1990 19:35
71 lines
4373 bytes
From article <2627@l.cc.purdue.edu>, by cik@l.cc.purdue.edu (Herman Rubin):
> In article <2883@igloo.scum.com>, nevin@igloo.scum.com (Nevin Liber) writes:
>> In article <64618@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>  
>> >It is my contention that future languages
>> >shouldn't have pointers at all.  Not just no C-like pointers, none at
>> >all.  I just picked on C as the most unpleasant example of what I'm
>> >against.
>  
>> I really hate to agree with you Jim :-), but I'm beginning to think
>> that you are right.  The only real argument I can see _for_ having
>> pointers is efficiency; more specifically, to help in
>> hand-optimisation.  Extensions to C such as C++ are showing that
>> pointers aren't needed nearly as much as they use to be; heck, code
>> seems to be more readable w/o them.  In languages such as Icon and
>> LISP I find that I don't even miss them.
> 
> I must strongly object.  When one considers what a variable or any other
> type of reference is, it is a pointer.  Fortran originally only used
> pointers, as there was no call by value.  I cannot imagine a language
> for mathematical use which does not have variable arrays, functions, 
> etc.  These are all expressed, consciously or not, as pointers.

Pointers will always be required by those who demand that languages
reveal the machine-level representations of their constructs. But 
that is only one view that languages can provide: Languages can 
provide no information about the location of a value, or they can
remove the notion of storage (memory) entirely. Are these latter
views bad? It depends on the design of the rest of the language.

I cannot imagine that 'mathematical use' requires that pointers
(or memory for that matter) be part of the language--unless by
'mathematical use' you mean the class of problems that requires
very fast massaging of large matricies (i.e. wringing the most
computation from every cpu cycle). In this case, efficiency is
paramount; assembly language coding is not out of the question here.

IMHO, pointers are required only when directly manipulating hardware
devices (as in operating systems).

> Now if one can have fixed pointers, why not variable pointers?  We are
> no longer in the days when the only way to call a subroutine was to
> have the address in the instruction.

Certainly, if pointers are values in the language then we should make
them first class citizens: They must be able to point to any value 
that is conceptually stored in memory; pointers should be able to be
stored in data structures, passed to and from functions, etc.

> One has to go through contortions in Fortran to use a subroutine which
> has a variable function or subroutine as an argument.  Now there are
> developments in programming languages which should have been apparent
> way back when which may decrease the need for some uses of pointers,
> but why hobble the intelligent programmer?  I have deliberately used
> arrays of pointers as the most convenient means of handling array
> refill procedures, and while I can find a way around it, it is clumsy
> and even less portable.

Pointers are not the only way of providing these kinds of operations--
they're not even the most beautiful (conceptually speakin, of course).
The ability to pass functions to function and to store functions in
data structures only requires that functions be first class values in
the language: Pointers to functions are unneeded if functions are 
values in the language. You just need to match the tool to the 
problem. If you require pointers, use a languages with pointers;
otherwise use a conceptually more simple language~r{_{_.
-- 
Norman Graham   <norman@a.cs.okstate.edu>   {cbosgd,rutgers}!okstate!norman
The opinions expressed herein do not necessarily reflect the views of
the state of Oklahoma, Oklahoma State University, OSU's Department of
Computer Science, or of the writer himself.
Technical Details
Message-ID: <1990Oct10.193502.2011@d.cs.okstate.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!uokmax!d.cs.okstate.edu!norman
References: <2627@l.cc.purdue.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!uokmax!d.cs.okstate.edu!norman
From: norman@d.cs.okstate.edu (Norman Graham)
Newsgroups: comp.lang.misc
Subject: Re: C's sins of commission
Message-ID: <1990Oct10.193502.2011@d.cs.okstate.edu>
Date: 10 Oct 90 19:35:02 GMT
References: <2627@l.cc.purdue.edu>
Organization: Oklahoma State University
Lines: 71