Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!ames!ucbcad!ucbvax!UNIX.SRI.COM!jperry From: jperry@UNIX.SRI.COM (John Perry) Newsgroups: comp.sys.apple Subject: Reply. Message-ID: <8705212252.AA23990@sri-unix.ARPA> Date: Thu, 21-May-87 18:52:26 EDT Article-I.D.: sri-unix.8705212252.AA23990 Posted: Thu May 21 18:52:26 1987 Date-Received: Sat, 23-May-87 14:30:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 55 You are correct (i.e. I forgot) about Leslie Lamport's involvement in TeX and I should have known better since Leslie used to work at SRI where I am employed. And you are also quite correct about LaTeX not being written in strict Jensen and Wirth Pascal --- but it is so close to Standard Pascal that it seems to be picking at nits to debate the point. However, I do NOT see how my mistakes on the above points have anything to do with my criticisms posted in my previous memo. Perhaps you could enlighten me on that. Your reply seems to suggest that I consider Pascal as a superior software writing language when compared to C and you, therefore, direct your criticism to that point. However, I thought my concluding points made it clear that the languages I considered superior to C were based on Pascal's principles of clarity and parsimony and I, in fact, mentioned Modula-2 and Turing as being examples of such. I agree that all languages have "blemishes", as you put it, but I think that it is the overall clarity of language structure that makes a language good even in spite of shortcomings in its "dirty details". C is excellent in "dirty details" --- it has all the tricks near and dear to the heart of any hacker. However, its overall design shows inconsistencies, obfuscations, reliance on the most error-prone features of programming, and its stauchest supporters (Kernighan and Ritchie) write books encouraging the use of programming idioms which save a few characters of typing at the very great expense of program clarity. That is why I support the addition of good, practical "dirty details" to languages with a fundamentally sound basic structure. Modula-2 goes much of the way toward that end. I mentioned several examples of C's shortcomings including inconsistent rules for structured data types (e.g. can't assign arrays, can assign records) and interactive I/O (scanf). You chose to defend the scanf by saying that the programmer has control over collecting the terminating newline in a (needless) variable and that this control made it a feature, not a bug. I couldn't get the gist of your argument but it was like suggesting that any bug that the programmer knew about was a feature just because he knew about it. Then, I was incredulous at your suggestion that strcpy(s,t) is clearer than the simple assignment s := t as your defense to my argument about non-scalar inconsistencies in C. First, the very name "strcpy" is a typical, obfuscated hacker abomination. Second, how can any procedure call be seen as simpler than an assignment statement? Thus, you can guess that I find C less than acceptable both at the macroscopic and microscopic level. It's a little like arguing religion because no one can say, with evidence in hand, that C is more/less readable/writable than, say, Modula-2. We only have our observations and resultant convictions. My conviction is that, despite the limitless overconfidence programmers have in their own abilities, we should use the simplest, clearest tools at our disposal. I find no languages among the vast choices available which fit this save Pascal and its direct (Modula-2) and indirect (Turing) successors, not including Ada. John Perry