Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ucsd!rutgers!iuvax!inuxc!att!ihlpb!nevin1 From: nevin1@ihlpb.ATT.COM (Liber) Newsgroups: comp.lang.misc Subject: Herman Rubin's opinions on computer languages (was: Third public review of X3J11 C) Message-ID: <8695@ihlpb.ATT.COM> Date: 8 Sep 88 00:33:29 GMT References: <8365@smoke.ARPA> <225800053@uxe.cso.uiuc.edu> <8374@smoke.ARPA> <340@quintus.UUCP> <910@l.cc.purdue.edu> Reply-To: nevin1@ihlpb.UUCP (55528-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 150 In article <910@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >When I see a language, the corresponding question is >whether the designers have provided a way for me to use the hardware instruc- >tions, and how easy and convenient it is for me to do that. In other words: when you look at a language, you look to see how low a level it is and how easy and convenient it is for you to hand optimise in it. This doesn't sound like you want a *high* level language to me. >Consequently, the first thing to strike me about PL/I is that the insertion of >the hardware instructions the gurus did not consider in their infinite wisdom >worthy of including in the language is forced to be in the same clumsy form >which discourages the use of assembler language. That the language designers >do not consider this problem important is, I believe, the major problem in >producing efficient semi-portable software. Don't you mean NON-portable software? To me, semi-portable software means that the machine-dependent parts are isolated and that's all that has to be changed when porting to a different machine. With your ideas, the machine-dependent parts would be tightly integrated with the rest of the software; this is what makes porting a nightmare. >> I have no desire to praise PL/I, but I honestly don't see any resemblance >> to any of the assembly languages I've ever used. >I repeat, what about the multitudinous operations which the gurus have not >included. What, from a functionality point of view, can't you program in PL/I that you can program in all assembly languages (and, for a given assembly language, would need no changes whatsoever when porting it to another machine which uses the same CPU)? In other words, what machine-independent OS-independent code are you referring to that can be done in assembly but not done in PL/I? >The only assembly language I have used in which I used this used ^. I do not >know of any use for ^ other than concatenation and power (or superscript) until >the C gurus came up with the idea of saying, "Nobody uses this, so we will use >it for exclusive or." What would you have chosen for xor, considering a very limited keyboard, and that most of the other symbols were taken? C was created in the early 70s, when a PDP-11 was considered state-of-the-art. Remember, C was not intended to be a verbose language; keystrokes were to be kept at a minimum. Given these conditions, what would you have chosen? >This is similar to the use of \ for an escape character. I pose the same question as above. And remember, the escape character should be one character, be printable, and the ESC key did not exist on most keyboards at the time. >Language designers should have more respect for even moderately established >notation in mathematics and computational theory. Well, this is funny considering mathematicians don't show respect for moderately established notations. sin^(-1)(x) should not mean arcsin(x), abuse of the ' symbol, d/dx not really division, etc. And they aren't limited by what appears on a keyboard, either. Language designers do the best they can; the only other way to do things is to invent new symbols for everything (')+(' for non-associative [floating point] addition, etc.), and that is not practical in reality. >> In the absence of an agreed notation for such a fundamental operation, >> the use of functional notation has a lot to commend it. >This is a major bone of contention and interpretation. I consider that >a binary operator function normally uses an infix symbol. Who invented the f(x,y) syntax anyway? It sure wasn't the computer gurus. Prefix notation is extendable (arbitrary number of arguments), infix is not (well, not easily). And quite frequently I find myself having to add another parameter to a function when I try to generalize it. This would be very difficult to do with infix notation. >It may be >necessary to invent a corresponding symbol, which need not be a single >character, for the purposes of a program if one is not available. Well, unless you have a nice graphics terminal, you aren't inventing a symbol; you are merely using an ordered collection of other symbols to represent your own. >I see the problem of assembler language that it is functional notation >and not overloaded operator. I never found this to be a problem when I programmed in assembler. I liked having a 1:1 correspondence between assembly language and machine language, and overloaded operators would most definitely go against that. And if you, a mathematician, have so much trouble with functional notation write yourself a preprocessor. >What do you think the reaction of HLL users >would be if you required them to write addint(x,y) for x+y if one wanted >to add the integers x and y? Many already do. It occurs in a very old language; a language about as old as FORTRAN. It's call LISP. Or, did you mean to ask that addint(x,y) be used for adding integers, addreal(x,y) for adding reals, etc.? If you did, then I answer No, I don't want to have to do this. That is one of the reasons I'm using an HLL in the first place! And how do you propose to define the overloaded operators? If you do it the C++ way, you haven't escaped your original problem, only moved it. >in addition to the usual operations. I maintain that any acceptable language >should allow such additions, including the temporary addition of infix >functions, if necessary. Then WRITE a language, and show us that this is indeed better. >One point concerning the above. Standard mathematical operations can produce >more than one result. And many functions can produce more than two results. If you are going to generalize, then do it right! >A simple example is division, with quotient and >remainder. Another example is that one frequently wants both the sine and >cosine; it is only about 30% more expensive to produce both of them simul- >taneously than to produce one. A LOT of overhead if you only need one. And why should a programmer programming in a HLL care whether these can be performed simultaneously. He specifies what he needs in the HLL, and the compiler is supposed to generate the best possible machine code for doing that. If the compiler isn't doing that you should be complaining about the implementation, not the language. Neither of these two examples show any inherent problems with most HLLs (C, PL/I, etc.); the problems are with a given implementation. _ __ NEVIN J. LIBER ..!att!ihlpb!nevin1 (312) 979-4751 IH 4F-410 ' ) ) Anyone can survive being frozen in liquid nitrogen; / / _ , __o ____ it's surviving the *thawing* that counts :-). / (_ Jef Poskanzer writes: @I just did some find/sed/grep hacking to find out just how prevalent @cross-posting is. @Here are the people who cross-posted to five groups: @, Herman Rubin, Congratulations!