brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/12/90)
The weak of heart be warned: This is not a friendly article. 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? > 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! Would he find it somehow ``easier'' to code in this language if the pointers were suddenly stripped away? No! STOP SAYING THAT POINTERS MAKE THINGS HARDER FOR THE PROGRAMMER! If you're trying to say that high-level data structures make things easier, SAY IT! STOP MAKING FALSE, RIDICULOUSLY MISLEADING STATEMENTS! > 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. ---Dan's Evil Alter Ego There, I'm in a much better mood now.
jlg@lanl.gov (Jim Giles) (10/14/90)
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
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/14/90)
In article <65696@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > From article <10635:Oct1213:40:5990@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein): > ] 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. What the hell are you talking about? You made a stupid statement. I asked you questions designed to show its stupidity. Now you're failing to answer the questions. Predictable, I suppose. You're repeatedly making statements like these: Pointers can never be more efficient than arrays because *(p+i) is just as slow as p[i]. Pointers inherently force the programmer not to use any higher-level abstraction. All data structures may be expressed as recursive data structures. You refuse to acknowledge that sometimes pointers can be used without adding an index first, that some of us don't mind using the most appropriate available tool for the job, and that packed array tries cannot be expressed as recursive data structures. Hell, you refuse to even look up packed array tries so that you know what you're talking about. > 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. Oh? C'mon, Jim, you're modifying history here. Maybe some C fanatics have religious objections to your language. I don't, and I don't know anyone who does. What I see happening is you suddenly shouting ``Pointers are evil! Pointers are useless!'' in the middle of what had previously been perfectly reasonable discussions. > ]> 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. [ various red herrings ] Jim, nothing in Nemesis that you've described to me requires any extensions to implement in C; you haven't told me about the syntax, but that doesn't really matter. The programmer can get all the greatness and glory of the Giles Gaggle, with whatever typechecking and constraints you want, with at most a C++-like preprocessor. Agreed? [ efficiency concerns, including: ] > And how does a macro or other preprocessor even > _begin_ to tell the compiler about no-alias conditions? Aha! You finally bring up an issue worthy of discussion! For the compiler to take advantage of un-aliased variables, it either has to compile several copies of the code with different aliasing restrictions, or let the programmer talk about aliasing somehow. Convex lets you selectively specify pointer arguments as unaliased, for example. Q has an assertion to express the lack of aliasing. I admit that C as is, while powerful enough to support the Giles Gaggle, may not be perfectly efficient without some extensions. This is an area where language design has to advance. > ] 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. Either you're mistaken or you're lying. I expect an apology. > ] 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? I did not make either of those statements. I expect an apology. Recursive data structures can never be used for packed array tries. Recursive data structures do not allow bounded-memory reverse-direction traversal of, say, a stack or tree. > And, I _HAVE_ been saying that high-level data structures make things > easier - a _LOT_ easier than the "pointers only" approach. No. You've been spending your time saying how bad pointers are. > ]> 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. No; I merely see that this is not a human factor issue. > But, at least in my experience, pointers are associated > with more than their fair share of hard to find errors. Fine. If you believe this based on your experience with C, provide something better. However, this isn't relevant to the issue of whether pointers belong in a language, which is what we are discussing. (You brought it up in the first place.) ---Dan
asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) (10/20/90)
In article <10635:Oct1213:40:5990@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > The weak of heart be warned: This is not a friendly article. [... that's OK, I deleted the nasty stuff ;-)] > Any arguments for > eliminating pointers must be based *solely* on compiler and run-time > efficiency. I partially agree. I would assert that any arguments for *any* language change (not just eliminating or modifying pointers) must be based also on the readability, maintainability, and, well, "programmer-friendly"-ness of the feature. I state this based both on what I've read in the industry, my personal experience, and, ironically enuff, what I've read on USENET. How many times have you read postings and counter-postings about whether *this* feature is more efficient than *that* feature? Is *this* code faster than *that* code? One is readable, another looks like it came out of a random-token generator. My point is this: it has been demonstrated time and again that when you let the programmer alone to "optimize" code, s/he will very rarely optimize the places that most need it. S/he in fact will frequently make it even less optimal by mucking with it. Very often when the code is presented in the most straightfoward, easy-to-understand manner, the compiler can actually produce superbly optimal object code. The programmer can hack that into something "efficient", and actually make it run *slower*. In the mean time, the programmer has wasted valuable person-hours trying to shave a microsecond from a process which has to wait for a longer running parallel (say, I/O) anyway, and actually make something else less efficient. This is not even considering valuable person-hours for the maintenance programmer trying to figure out what's going on later. Therefore, compiler efficiency must be assumed to be programmed-in by the compiler writers. Let us hope they know what they're doing. Programmer-efficiency is much more important in the long run. This *must* be considered in adding new (or removing old) language features. -- =============Opinions are Mine, typos belong to /bin/ucb/vi============= "We're sorry, but the reality you have dialed is no | Alvin longer in service. Please check the value of pi, | "the Chipmunk" or pray to your local deity for assistance." | Sylvain = = = = = = =All this time I thought it was spelled "diety"= = = = = = =
asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) (10/20/90)
I shouldn't do this, but my wife'll tell you I never do what I should ... In article <65696@lanl.gov> jlg@lanl.gov (Jim Giles) writes: [... everythang I ain't innerested in 'sbeen nuked] > 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? YES!! This *is* a topic to discuss! I have another posting (which is why I shouldn't do this, I'm being redundant) which emphasizes this very point. The time to read and understand code is much more important than the micro- seconds some cryptic implementation may save. The fellow with the Hermes language stated it best ... get it correct first, then worry about efficiency. Get it correct in a readable fashion! If it's correct and unreadable, it can not be improved. If it's incorrect and at least readable, someone can fix it quickly. If it's incorrect, unreadable, but *fast*, it's worthless. (I'm *so* glad the subject of this thread has changed! ;-) -- =============Opinions are Mine, typos belong to /bin/ucb/vi============= "We're sorry, but the reality you have dialed is no | Alvin longer in service. Please check the value of pi, | "the Chipmunk" or pray to your local deity for assistance." | Sylvain = = = = = = =All this time I thought it was spelled "diety"= = = = = = =