Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: C's sins of commission
Message-ID: <26375@megaron.cs.arizona.edu>
Date: 14 Oct 90 06:22:48 GMT
Organization: U of Arizona CS Dept, Tucson
Lines: 130

In article  <65680@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
]
]Here we see the basic confusion between the semantics of something and
]its implementation.

That was _clearly_ a rephrasing something _you_ said.  The purpose of
the rephrasing was _clearly_ to show that you had this basic
confusion.  Taking a quote out of context like that is really low.

In article  <65662@lanl.gov> jlg@lanl.gov (Jim Giles) writes:

]And yet, you do not find it "simple hubris" when people (including
]yourself) maintain that the features of C are all anyone ever needs.

That is a lie.  Slander, libel, and not even a nice or true thing to
say about me.  I have never, _never_, NEVER, said, implied, intimated,
believed, thought, or given credence to the statement that the
features of C are all anyone ever needs.  If anyone asked my opinion
on C, I would say that it is OK in it's application domain, widely
known, and has some nice features.  But if your application isn't
seriously performance bound, use a real language like Lisp or Icon,
one that supports multiple paradigms and has lots of nice high-level
data structures.

]If my opposition to pointers seems overblown, it is because all the
]false hype popularizing C is even more so.  How many time have you
]chastized a C supporter for claiming that a preference for Fortran
]was misguided?

My opinion on Fortran is about the same as my opinion on C, except for
the part about having some nice features.  Maybe if I knew a Fortran
more recent than Fortran 77 I could even say nice things about it.

]This is a variation on the old "blame the victim" approach that lawyers
]defending rapists use.  What you're saying is that you don't have the
]problem and those that do aren't worth considering.

That is a pretty sleazy rhetorical ploy.  People who have trouble
reading my code are not the moral equivalents of rape victims.  They
are not very competent programmers either.  As to "blame the victim",
there is not necessarily any "blame" associated with incompetence.  I
just don't want to be bound in _my_ actions by the possible
incompetence of other people.  I also don't expect professional
basketball players to play blindfolded with one arm tied behind their
backs so that clutzes like me have a chance to be in the NBA.

]  Aside from the
]ethical questions about your apathy toward other programmers, what about
]practical issues such as increased software costs, or increased taxes
](the government hires programmers too - not all of them are as immune
]as you are to these errors)?

First, I do not claim immunity to errors.  I claim that using pointers
does not cause me to make errors.  Second, I do not claim that
everyone should use pointers.

]But, let's test your claim:  what is the expected argument type in the
]following ANSI C style function prototype?
]
]   int f(char *x);
]
A pointer to a character.

]Now, is the argument expected a single character which is passed by
]reference?  Does the function expect an array of char?  Does the
]function expect a sequence of char (terminated with a zero byte)?

Yes.  One of those.

]Or, perhaps the function expects something entirely different and
]it is declaring its argument to be a (char *)

In a post-ANSI C this would be trouble.  The programmer's problem, not
mine.

OK, now your turn.  In the following LISP function

(defun f (x) ....

What is x supposed to be?  One of the above things?  A symbol?  An
array?  Hmm.  Looks like you are going to have to look at the code.

]  You can't tell?  You are now having a problem
]pointers that you claim you don't have.  The only way to tell what
]this argument is expected to be is to inspect the body of the function.
]Commentary and other sources may _claim_ that the argument is used

Well, you either trust the documentation or you don't.  If you don't,
then you have to inspect the body of the function anyway to see if it
does what you want it to.

]Then leave the discussion!  C is a fait accompli and this is a
]discussion about the possible design of some future language.

It is?  Then how come the article I responded to looked like a nothing
more than a pointless (heh,heh) slam at pointers?

]... The rank and extent of an array is fixed for the lifetime
]of the array (which may be dynamic: specified in an allocate statement).

APL programmers will be surprised to hear that.

]The length of a sequence ... is variable.

Mathematicians will be surprised to hear that.

]  This
]means that the concatenate operator is quite appropriate and useful for
]sequences, but is of doubtful use for arrays

I don't see the relationship.  When you concatenate two sequences to
get a third, you haven't changed the length of any sequence.  Changing
the length of a sequence implies that it is a mutable object in the
first place, and in the second place makes it deque.

]  If both arrays and
]sequences are implemented in the same way (as you insist using pointers),

More slander.  I never insisted on any such thing.

]then the introduction of a concatenate operator would endanger error
]due to accidental use on arrays.

Oops.  And maybe you just discovered a useful new operation on arrays
by observing their similarity to sequences.  It works in APL.
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman