Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!zodiac!joyce!sri-unix!garth!smryan From: smryan@garth.UUCP (Steven Ryan) Newsgroups: comp.lang.misc Subject: Re: Many people's opinions on computer languages (was: Third public review of X3J11 C) Message-ID: <1386@garth.UUCP> Date: 8 Sep 88 20:35:12 GMT References: <8365@smoke.ARPA> <225800053@uxe.cso.uiuc.edu> <8374@smoke.ARPA> <340@quintus.UUCP> <910@l.cc.purdue.edu> <8695@ihlpb.ATT.COM> Reply-To: smryan@garth.UUCP (Steven Ryan) Organization: INTERGRAPH (APD) -- Palo Alto, CA Lines: 123 >>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. What is the purpose of language? To specify good code on a PDP-11 or good code on the machine in use? Postdecrement and postincrement operators are horrendous on a RISC. The lack of a boolean mode and the requirement that && and || shortcircuit are horrendous on a RISC. On the other hand, the machine I use has a (32 int)*(32 int)=(64 int) instruction which C does not provide for. I feel the language should provide access to every instruction the hardware provides. Programmers can then abstract out machine independent operators if they wish. A good extensible language would permit infix operators to be defined as the programmer sees fit. >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. So what? It's not that job of language designer (except, of course, Wirth, from whom all blessings flow) to decide what is good and bad programming--just make good tools. Give programmers direct access to the machine so they can be honest about writing machine dependent code. Give them good abstraction facilities so they encapsulate it if they desire. >>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 How about `xor' `|-' `+|' .... ? >>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. Other language have other solutions which do not use any escape. In fact, nearly every other language. >>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. Ever see Smalltalk? Postfix and infix notation, and that's it. No prefixes, no functional notations. From what I've seen of Smalltalk, it's easier to understand than C. How about calculus integrate:f from:l to:U instead of (*calculus.integrate)(f,l,u) Have you ever seen calls with dozens of arguments? How do you know what each argument stands for? Algol60 had a neat feature (inspired Smalltalk?): integrate(f) from:(l) to:(u) >>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. LISP is the primary language of numerical analysis, after all. >>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. And if you don't like the operating system, write a new one. Same with device drivers. Same with cpu. Same with disc drives. God forbid someone who is a tad more expert might help out. >>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. Even more overhead if you want both and someone decided for you you need to make to calls. >And why should a programmer programming in a HLL care whether these can >be performed simultaneously. He specifies what he needs in the HLL, If the HLL permits it to be specified. >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 Oh, c'mon. If the programmer is forced to write incredibly complicated code because someone decided an operation is unnecessary, do you really expect any compiler to decode what is happenning and produce efficient results. That's like putting up fence on a path, making people walk way around, and then assuming it will be as if the fence did not exist. >@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! Well, that's certainly addressing the issue. If you can't dispute the message, sacrafice the messenger.