trb@floyd.UUCP (Andy Tannenbaum) (08/03/83)
The New (August) Byte is devoted to the C language. I haven't read it but there seem to be some interesting articles. One gripe: The cover has a picture of a toolbox at its center. The labels on its drawers say: putchar, write, read, isalpha, atoi, atol, getchar, isdigit, exit, strcmp, isascii, scanf, calloc, brk, index, printf, qsort. Not one C reserved word in the bunch. You'd think that the issue was devoted to the UNIX system rather than to C. Andy Tannenbaum Bell Labs Whippany, NJ (201) 386-6491
dan@idis.UUCP (08/04/83)
Many people don't distinguish between the C language and the standard UNIX C language subroutine library. I have even heard the complaint that since the Whitesmith's C compiler doesn't come with a UNIX like standard I/O library, it isn't real C. I don't agree. C is for loops and statement braces and pointers and structures. Contrary to popular notions, there is no C language write statment called "printf." Did you ever wonder how many years of UNIX and C Language experience most of the authors of the recent avalanche of UNIX/C books have? I have heard the claim that programmers don't write good manuals. If this is true, the supposedly good writers that are busy writing about C may not know very much about the subject. Murphy strikes again. Dan Strick University of Pittsburgh [decvax!mcnc]!idis!dan
henry@utzoo.UUCP (Henry Spencer) (08/07/83)
Claiming that the definition of C does not include things like "printf"
is both theoretically defensible and thoroughly silly. Sure, you can
define a C without such things -- but it's useless. No simple string
operations, no i/o, etc... In most other languages, these things ARE
part of the basic language, and rightfully so. Thanks to Dennis
Ritchie's abilities as a language designer (plus some good luck in
places), these things can be defined as (more or less...) ordinary
C functions, and hence don't need to be built into the very language.
But that doesn't make them any less necessary. These things are no
more -- and NO LESS -- wired into the basic definition of C than, say,
the "ls" program is wired into the basic definition of Unix. In theory,
it's a side issue; practically, the functionality is necessary, and it's
silly to add gratuitous differences in the way that functionality is
invoked. Even Whitesmiths has (I'm told) recently toed the line by
offering an i/o library with the standard names.
In short, if your programs won't compile, then you really don't care
about nit-picking distinctions between "standard C" and "standard C
with the standard C library". For most practical purposes, the library
is part of the language.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryeric@aplvax.UUCP (08/07/83)
You are right about authors with little experience in C writing books. Why, in the BYTE is an article by two complete novices: Johnson and Kernighan. (Couldn't resist) eric ...!seismo!umcp-cs!aplvax!eric
kwmc@hou5d.UUCP (08/08/83)
C without standard io libraries etc IS NOT USELESS. I once wrote a bootstrap loader in this way, it was much quicker than mucking around in assembler. Ken Cochran hou5d!kwmc
jcw@cvl.UUCP (Jay C. Weber) (08/08/83)
>If this is true, the supposedly good writers that are busy writing >about C may not know very much about the subject. Amen. This also goes for UN*X. I was reading an article in PC-WORLD a couple of months ago and laughing at the apparent lack-of experience the author(s) had on UN*X systems. The biggest blunder went something like this: "a fork is when two copies of the same file are created so that even though the new one is changed, the first one still remains as a backup." Also, the author(s) kept referring to the utilities including compilers, text formatters, etc. as the "shell", also calling them "special system routines". The most amazing part is that one of the authors recently published a book on UN*X. Good Grief. -Jay Weber {..!seismo!rlgvax!cvl!jcw}
trb@floyd.UUCP (Andy Tannenbaum) (08/08/83)
Two points re people's comments on the C Language. David Hesselberth (of pur-ee) wonders how Byte has the nerve to call C a medium level language while calling such "lowly" languages as COBOL and BASIC high level languages. The term "high level" does not mean "state of the art" or "clever" in this context. A high level language is one which "protects" a user from the intricacies of a computer. An octal code program to be entered through the switches (!) is a very low level language code. Assembly language is higher, relocatable yet higher, with macros higher, C higher, BASIC higher, /bin/sh higher. It has nothing to do with the elegance of the work done using the language or the elegance it took to design the language. Secondly, Henry Spencer (of utzoo) suggests that printf is as ingrained into C as ls is ingrained into UNIX. Perhaps he's right, in the sense that it's there, but a substitute would be just as, if not more, fitting. You can't call it C if it uses BEGIN/END instead of curly brackets (giggle) but you certainly call it C if you are using it to program a machine that doesn't use printf/scanf etc, especially if you're using the compiler to program a machine outside the tty interface environment, like in a controls environment. Here in Ocean Systems at Bell Labs, we use C programs with goofy libraries to run satellite processors in our signal processors. If you deny that these processors are running C programs, I will chuckle and shake my head at your ignorance. Loosen up your prejudice about C and UNIX a bit, else you'll strangulate them to death. Andy Tannenbaum Bell Labs Whippany, NJ (201) 386-6491
dan@idis.UUCP (08/09/83)
Another curious indication of how the world views the C language: the first of three compiler comparison articles discussed half a dozen C compilers for the 8086 family. There was only one pointer variable used anywhere in the benchmark routines and this was in an error message routine that was presumably never invoked. Apparently the authors of the article considered pointers and register variables to be machine dependent hacks that have no real status in the C language. My opinion: C without pointers is just transliterated PASCAL. Avoiding the use of pointers in C is about as appropriate as avoiding GOTO statements in FORTRAN or PROGs in LISP. Dan Strick University of Pittsburgh [decvax!mcnc]!idis!dan
gjphw@ihuxm.UUCP (08/10/83)
The recent comments about the latest BYTE magazine articles concerning
the C language are most interesting. While I have not yet read this issue
of BYTE, and I am not a C freak, some of the references to the C language
can be understood from a historical perspective.
C is best understood as an intermediate language, in the class with
BLISS, MACRO, and even some versions of the IBM H-level assembler. It
does not remove the programmer as far from the hardware as a high level
language would (e.g., PL/1), but it also allows versatile data structures.
Some ambiguity lies around the criterion for the level of a programming
language, and further discussion of where C might fit on the language
line must wait for this definition.
At the time that C was being developed, the computing world was in
the thralls of ALGOL. In ALGOL, the language consists of logical
constructs, data structures, and mathematical operations. I/O was
considered an implementation feature and left as a function call. It
seems that the interpretation of what should be included in the definition
of a language and what is an auxiliary function has changed. The net
result is as expressed by D. Strick, that there is no practical distinction
between the core language and its auxiliary functions.
Having said too much, further discussion of this might be better
carried on in one of the computer newsgroups, where the heavies dwell!
Patrick Wyant
Bell Labs (Naperville, IL)
*!ihuxm!gjphwsts@ssc-vax.UUCP (Stanley T Shebs) (08/10/83)
Not to stray too far from the original subject, but pointers in C are far more essential than PROGs in Lisp. The good Lisp programmer uses a variety of structured macros rather than PROG. In my ~3500 lines of Lisp, I have one PROG (and it's there for historical reasons), but lots of 'loop' and 'let' macros. Getting back to C, there's no doubt that pointers are essential to the language. How would you implement call-by-address, strings, or linked structures (well ok, it can be done, but you might as well use Fortran) I have come to understand Byte less and less over the years - give me a Dr. Dobb's any day! stan the lep hacker ssc-vax!sts (soon utah-cs)