Path: utzoo!attcan!uunet!abcfd20.larc.nasa.gov!ipsun.larc.nasa.gov!jcburt From: jcburt@ipsun.larc.nasa.gov (John Burton) Newsgroups: comp.society.futures Subject: Re: C's sins of commission (was: (pssst...fortran?)) Message-ID: <1990Sep14.160429.2732@abcfd20.larc.nasa.gov> Date: 14 Sep 90 16:04:29 GMT References: <1990Sep13.185833.17455@cunixf.cc.columbia.edu> <62927@lanl.gov> Sender: news@abcfd20.larc.nasa.gov (USENET File Owner) Organization: NASA Langley Research Center, Hampton, VA USA Lines: 128 >This leads us to pointers. Just about everything about C pointers is >bad. From the fact that pointers are hopelessly confused with arrays >(which are completely separate conceptually) to the syntax of pointer >use, C's pointers are a mess. Not a mess, just cryptic, as is most of C. C IS NOT a high level language, it was originally designed as a mid-level language, somewhere between Pascal and Assembler...it is NOT designed to be used by novice! > In addition, many language design people >now feel that pointers of _any_ kind are a bad idea. C.A.R. Hoare >condemned them as long ago as the early 70's (about the time C was >'designed'). He pointed out that pointers are the data structuring >element that corresponds to GOTOs in flow control - if the one is >bad, so is the other. Again, what they are considering is a high-level language. C is a mid-level language. Assembler DOES NOT have arrays and the PRIMARY method of flow control IS the GOTO... BTW: since the early 70's it has also been shown that the total LACK of GOTO's is also bad. Selective use of GOTO is the key. >Since this is comp.society.futures, I will discuss pointer replacements. >Essentially, pointers only do three things for you: 1) recursive data >structures (graphs, trees, etc....); 2) dynamic memory; and 3) run-time >'equivalence'. C pointer arithmetic only does what one dimensional array >indexing already does (scaled address calculations): arrays are better for >this - so it's _not_ counted as one of the features of pointers. Sorry, but it IS more expensive (execution time wise) to sequentially index through an array, than it is to simply increment a pointer... Array indexing is better for randomlly accessing the array... just because random access is better for somethings, should we totally do away with sequential access? come on, be fair... >Recursive data structures are best implemented directly (to use a >C/Fortran like declaration syntax with the type names on the left): > > Type Tree is record > integer :: value > tree :: left, right > end type Tree > >Note that the elements inside a tree-valued data type are not _pointers_ >but are actually trees themselves. No more confusing pointers with >what they point to - the pointers aren't explicitly visible. No more >forgetting the dereference operator (or, conversely, putting it in >incorrectly) - there isn't a dereferencing operator. To be sure, the >compiler _may_ internally use pointers to do the implementation of >these recursive structures (but then, it probably uses GOTOs to internally >implement loops), but since they aren't explicitly visible to the user, >his life is much easier. when i think of a (data structure) tree, i tend to think in terms of nodes being linked together NOT immediately adjacent (draw a data structure tree...nodes are not directly attached...there is a line connecting the the nodes...the line is a pointer... Not using pointers would make life easier for a novice programmer. It would severly limit the experienced programmer... > > [more stuff about the evils of C] > >J. Giles One thing that has apparently slipped the mind here is that comparing C, Pascal and Fortran, is the same as comparing apples to oranges... Fortran was designed to be a "high-level" scientific language, it was designed to "protect" the user from the machine (and protect the machine from the user) while still allowing him/her some freedom to do calculations. Protecting the user from himself is another story...I still have nightmares about debugging large Fortran systems that use COMMON & EQUIVALENCE extensively. Few errors (other than straight syntax) were caught by the compiler...most errors were debugged (or not) at the runtime stage. Pascal was designed from the ground up as a "high-level" teaching language. It was designed to enforce structured programming, and to detect as many errors as possible at the earliest possible stage (i.e. the compiler). Basically it provided a high level of insulation between the machine and the user, but at the expense of functionallity. (Note: you can still do almost anything you want in Pascal, it just takes more work). C on the other hand was design as a "Mid-Level" systems language. It was to be used to write device drivers and low level routines. Essentially it filled the gap between Assembly Language (high functionality/flexiblity, *low* user protection) and the high level languages (High user protection and lowered functionality/flexibility). It was designed to have freer access to the machine, but still provide some level of protection. Basically what the above posting indicated is that the average programmer should not use C. Fine, the average programmer should also not do systems programming, and the average programmer should not use assmebler... Speed of execution is another aspect for comparison...Pascal and Fortran were designed to accomplish tasks safely (Pascal more so than Fortran). C was designed to accomplish tasks quickly. The often made comparison of indexing through a 1-dimensional array (linear representation of a multidimensional array) instead of incrementing pointers is not strictly valid. For every array access, there is a corresponding index calculation (usually a multiplication and an addition) to determine where to look for the data. Incrementing a pointer is faster (generally a register increment operation). The difference between the two methods is the same as the difference between a random access data structure (array) and a sequential access data structure (pointers). Neither is inherently better, they each have particular applications where they are the best choice. The problem is that C, Pascal, and FORTRAN were design for (different) specific purposes, and are currently being used as high level general purpose languages which is NOT what they were designed to do. C wasn't even designed as a high level language...Each is probably the best choice in its area, but not necessarily outside its area... Ada is an example of a (government decreed) high level general purpose language...supposedly it can do everything C, Pascal, and FORTRAN can do, but i'm not sure it would be the language of choice in the specifc areas that C, Pascal, and FORTRAN were designed for... When asked the question, "what is the *best* programming language?" the answer should be "it depends on what you want to do..." perhaps the future of computer languages shouldn't be trying to find a "best" general purpose language, but instead, develop transparent ways for modules written in one language to be used in programs written in other languages...this is already being done to some extent, but it should be taken further... John Burton (jcburt@ipsun.larc.nasa.gov) (jcburt@cs.wm.edu)