Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!ima!bbn!rochester!crowl From: crowl@rochester.UUCP Newsgroups: comp.lang.misc,comp.software-eng Subject: Re: Software Technology is NOT Primitive Message-ID: <3670@sol.ARPA> Date: Wed, 28-Oct-87 14:58:02 EST Article-I.D.: sol.3670 Posted: Wed Oct 28 14:58:02 1987 Date-Received: Sat, 31-Oct-87 08:42:06 EST References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <3603@sol.ARPA> <596@l.cc.purdue.edu> Reply-To: crowl@cs.rochester.edu (Lawrence Crowl) Organization: U of Rochester, CS Dept, Rochester, NY Lines: 91 Xref: utgpu comp.lang.misc:773 comp.software-eng:17 In article <596@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >[reguarding access to machine specifics from high level languages] See Stanley Shebs's article <5084@utah-cs.UUCP>. I will not address those topics which he addresses. >Are we to be limited to those features which are portable to all machines? >If we do this, the only arithmetic operations we can allow are fairly short >integer arithmetic; ... You are still oriented on supporting the hardware instead of describing a solution. A real high level language is independent of the word size. If a machine does not have a long integer, the implementation of the language must build it from short integers. >... of the machines I have looked into in the past few years, no two have the >same floating-point arithmetic. Given that highly accurate floating point routines are heavily dependent on specific floating point formats, this is a problem. No high level language will be portable from machine to machine when the formats are different. The IEEE floating point standard should help. >The languages should not be designed around the quirks; they should be >powerful enough to enable the programmer to make use of the quirks. ... I am >not advocating a language to optimize a specifice machine. I believe that a >language should be sufficiently powerful that the intelligent programmer can >optimize on whatever machine is being used at the time. Any language which allows the programmer to make use of the quirks must make them visible. This makes the language complex, difficult to understand, difficult to reason about and makes the resulting programs non-portable. >I can give competitive algorithms for generating normal random variables on >the CYBER205 which I know, without programming them, will not be competitive >on any of the other machines I have listed above. If you are trying to get 100% performance, you will have to use assembler. No language that has any meaning beyond a single machine can hope to meet your needs. It seems that your real complaint is that assembler languages are too verbose, not that high level languages do not allow sufficient access to the machine. It should not be too hard to whip together an expression-based "pretty" assembler. >I question the need for a language which will keep the user ignorant of the >powers of the computer. I also question whether such a language, unless very >carefully presented as incomplete, with sufficiently many indications of its >deficiencies, will facilitate the eventual enlightenment of the learner; ... Very few languages are incomplete in the sense of being able to compute an arbitrary function. However, assembly languages are examples of incomplete languages. All languages are incomplete with respect to their support of the programmer for some application area. It is true that there are no languages tuned to the machine specific implementation of highly optimized numerical libraries. I suspect it would look very much like the "pretty" assembler. >Unfortunately, some machines such as the CRAY do not provide decent fixed >point multiplication; on such machines it is necessary to work around it, and >one may find it advisable to totally revise the algorithm. You apparently program in a very narrow world where performance is everything. The vast majority of programming is not done in such a world. >The user should be able to introduce type definitions (structures in C), new >operators (such as the very important &~, which may or may not compile >correctly), and overload old operators. This should be very flexible. C++ allows programmers to introduce new types and overload existing operators. It does not allow the definition of new operators, but does allow definition of functions which achieve the same effect at the cost of a slightly more verbose syntax. >The VAX has twelve general-purpose registers available. If I write a program >which uses eleven registers, I object to the compiler, which does not need any >registers for other purposes, only giving me six. So complain to the compiler writer. This is not the fault of the language or of its designer. >[Efficient code takes longer to produce than inefficient code] because of the >badness of the languages. Effient code takes longer because the algorithms are generally more complex, not becuase the languages are bad. >Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 -- Lawrence Crowl 716-275-9499 University of Rochester crowl@cs.rochester.edu Computer Science Department ...!{allegra,decvax,rutgers}!rochester!crowl Rochester, New York, 14627