jperry@UNIX.SRI.COM (John Perry) (05/21/87)
Weak type-checking is for people with large egos who like languages which permit an infinite degree of "cleverness". Such languages, like C, are a throwback to the days when program input was done on punch cards and, therefore, people were overly concerned about writing terse programs so that data entry wouldn't be so costly. "Sophisticated" languages, like Lisp, Prolog, and C are grotesque invitations to error, egocentric programming, and unreadability --- especially in C with its overreliance on pointers which are ambiguous references by definition. In my opinion, Lisp and Prolog have actually been a large factor in the current problems experienced in the AI community (buggy products, overshooting all deadlines, poor market acceptance, poor user-friendliness of products, etc., etc.). A sterling example of all of this is in the area of word processing/typesetting packages where Donald Knuth, ** all by himself **, came up with a series of such packages (TeX, MetaFont, LaTex) which are considered the state of the art in the word processing/typesetting area. And he used the language considered the least practical language in the world for such grandiose purposes Standard Pascal. And he used NO pointers. Finally, in the case of C, the language is so full of goofy bugs (like the scanf "feature" of having to collect the newline), cryptic syntax (e.g. its FOR loop), and inconsistent restrictions (you can assign records but you can't assign arrays) that it rather amazes me that it has gained such universal acceptance. Almost everything about the language is counterintuitive (like the system calls where the destination string is the first parameter and the source string is the second) --- even many UNIX gurus I know keep a C manual by their side because, even after coding megalines, they still need to consult it often. The progress of languages such as Modula-2 and Turing may be slow due to sunk-cost principles, the earlier arrival of (ugh!) Ada, and many political and economic considerations --- but I think reason will ultimately win out and roust out the ticking bombs currently so popular in software engineering. John W. Perry
gwyn@BRL.ARPA.UUCP (05/22/87)
How can anyone take your evaluation of relative merits of programming languages seriously when you have made so many factual errors in your posting? Programming and data entry are two different activities. C was never designed to be used in a punched-card environment. C pointers are a key feature of the language, which after all was originally designed primarily for systems programming on "bare metal". The C run-time support for hosted environments developed later, as C was discovered to be both high-level and low-level enough for a wide range of uses. Don Knuth certainly did not produce the TeX-based facilities "all by himself". In particular, LaTex was primarily produced by Leslie Lamport. The TeX language is just as horrible as troff's (which has provided comparable facilities for many years), only different, and TeX has never been free of bugs (which should surprise nobody except those who think that a suitable language is all that's needed to have perfect code). Knuth also did not use Standard Pascal; he relied heavily on the availability of "other" in case statements. Porting TeX is not simply a matter of taking the "portable" source and compiling it. He didn't use pointers because Pascal pointers are painful and untyped; this has no bearing on whether C pointers are useful or not. How could anyone criticize scanf()'s handling of newline, which is under the C programmer's control in the first place and which can be totally bypassed in favor of other input facilities tailored to the application in the second place, as opposed to Pascal's READLN? (Scanf() has some problems, but that's not one of them.) How could anyone think "dest := src" is intuitive while "strcpy(dest,src)" is counter-intuitive? Certainly the C language has its blemishes, but to pretend that other languages such as Modula-2 don't and to criticize C for not being just like some other language is merely to reveal one's personal background, not any absolute "reason". C can be used well; Pascal can be used well; Ada can be used well; even BASIC can be used well. Of these, I find C the most universally useful for a wide range of applications. (Modula-2 might be a contender if I could count on existence of compilers for it everywhere.) But I consider other languages for a project, and I sometimes develop a language tailored to the application's needs. (If portability is even remotely a consideration, I make damn sure I can quickly implement the language everywhere. Software economics involves far more than simply selecting a programming language.)