🚀 go-pugleaf

From article <10635:Oct1213:40:5990@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
> The weak of heart be warned: This is not a friendly article.

Well, actually my additions to it aren't _that_ bad.

> 
] In article <65409@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
]> Why indeed?  Why force the programmer to use explicit pointers when
]> the language can be designed to allow the programmer to explicitly
]> state what he really wants to do?
]
] That's another really stupid statement. Jim, if I take your favorite
] language and add pointers to it without telling the programmer, HOW WILL
] HE EVER KNOW? How will adding pointers *force* him to stop using your
] gaggle of data structures? How? How? How?

Well, if this were an argument over what should be _added_ to a
language after all the features I desire were already present, then
your point would be quite valid.  In fact, the language I'm
co-designing probably _will_ eventually have pointers (at least, if
it ever developes that far).  I have pointed this out to Dan
numerour times in past correspondence: yet another thing he
consistently has chosen to ignore.

But, this _isn't_ a discussion over what to put into a language in
_addition_ to the features I recommend!  Every time I recommend (for
example) that a language should support arrays, the C supporters
immediately claim that I don't need them since pointers already
give me all the functionality I need.  The main reason I take the
stand that pointers aren't needed at all is that the opposition
is opposed to _anything_else_.  Personally, if all the features
are placed in a language, I don't _care_ if pointers are also added.
I _do_ care if the features I want _aren't_ present and some turkey
tells me that pointers are an acceptable substitute - they aren't.

] [...]
]> It's easier for the programmer,
]
] No! If I take C and add the Giles Gaggle to it---through macros, a smart
] preprocessor like C++, or whatever---is the programmer ``stuck'' with
] pointers? No!  [...]

Well, actually in this case the programmer _is_ still stuck with
pointers.  If the mechanism for providing the features I want isn't
in the _compiler_, then the compiler can't enforce the constraints
that make those features useful.  A preprocessor which just turns
the features into pointers will not tell the compiler that (for
example) a multidimensional array must obey bounds in _each_
dimension.  In C++, if you want multidimensional bounds checking,
you have to hand code the tests yourself in the MATRIX type
definition - where they almost certainly aren't as efficiently
implemented as they would be if the compiler knew of the type
directly.  And how does a macro or other preprocessor even
_begin_ to tell the compiler about no-alias conditions?

] [...]
] STOP SAYING THAT POINTERS MAKE THINGS HARDER FOR THE PROGRAMMER!

Ah, but they _DO_ make programming harder if they are the _only_ means
of support for the features we've been discussing.  It has been _your_
contention until this very article that pointers _should_ be the only
means of support for these features.  I'm glad to see that you're
finally willing to admit the acceptability of some more modern
features.

] [...]
] If you're trying to say that high-level data structures make things
] easier, SAY IT! STOP MAKING FALSE, RIDICULOUSLY MISLEADING STATEMENTS!

What?  Am _I_ the one who claimed that recursive data structures could
never be used for 'trie' data structures?  Am _I_ the one who claimed
that only the pointer data type would allow reversing a stack by swap-
ping links?

And, I _HAVE_ been saying that high-level data structures make things
easier - a _LOT_ easier than the "pointers only" approach.  In fact,
_SO_ much easier that I can't find any application outside systems
programming that should ever need or want pointers at all.  Even for
systems programming the need is _VERY_ rare: memory management,
memory mapped devices - little else.

]
]> easier for the compiler to generate efficient code,
]
] Now *that* is a reasonable assertion. It doesn't make you look like an
] idiot, it's a good basis for discussion, and it fact it's the *only*
] thing that could be considered a ``pointer problem.'' Any arguments for
] eliminating pointers must be based *solely* on compiler and run-time
] efficiency.

In addition, arguments about _any_ language feature should include as
much information about human factors as possible.  You are trying to
exclude this.  But, at least in my experience, pointers are associated
with more than their fair share of hard to find errors.  Why shouldn't
this experience be a valid point of discussion?  How about the time
it takes to read and understand code - is not this also a topic we may
discuss?

J. Giles