Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!husc6!bbn!rochester!crowl From: crowl@cs.rochester.edu (Lawrence Crowl) Newsgroups: comp.lang.misc,comp.software-eng Subject: Re: Software Technology is NOT Primitive Message-ID: <3603@sol.ARPA> Date: Mon, 26-Oct-87 20:28:17 EST Article-I.D.: sol.3603 Posted: Mon Oct 26 20:28:17 1987 Date-Received: Thu, 29-Oct-87 04:48:51 EST References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <5077@utah-cs.UUCP> <594@l.cc.purdue.edu> Reply-To: crowl@cs.rochester.edu (Lawrence Crowl) Organization: U of Rochester, CS Dept, Rochester, NY Lines: 133 Xref: mnetor comp.lang.misc:796 comp.software-eng:10 In article <594@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >I suggest that the software developers first consider the power of existing >hardware, next the natural power of hardware (what unrealized operations can >be easily done in hardware but are not now there), and finally the "current >use." No, software developers should first consider the task to be solved. The efficient use of the hardware is moot if the software does not meet the need. >There are instruction present on most machines which someone knowing the >machine instructions will want to use as a major part of a program, but which >the HLL developers seem to ignore. The task of language developers is not (or should not be) to directly support the hardware, but to provide an environment in which a programmer can effectively express the solution to a problem. In those cases where efficiency matters, the language model is generally chosen to be efficiently realized on conventional machines. Catering to specific instructions on specific machines is generally a loss because the resulting programs are useful only on that machine. Supporting common instructions directly in the language often means presenting an inconsistent model. For instance, the arithmetic right shift provided by many machines provides division by two except when the number is negative and odd. Should languages be designed around this quirk? I do not think so. >I suggest that a language intended for library development be approached by >the developers with the attitude that a machine cycle wasted is a personal >affront. I think we will find that the resulting languages will be easier >to use and less artificial than the current ones. I think that just the opposite is true. Designing a language around optimizing the use of a specific machine is likely to leave a language so riddled with special case restrictions as to be hopelessly complex. >Implementing an arbitrary set of types is no more difficult for the user than >the 5 or 6 that the guru thinks of. Who implements the arbitrary set of types? The user? The language designer? If the language provides mechanisms to allow the user to implement types, then the task of the language implementer is only difficult. There are many issues in value instantiation, etc. which must be delt with in a language that allows definition of arbitrary types. If the implementer must implement the arbitrary set of types, then the task is impossible. >Allowing the user to put in his operations and specifying their syntax is not >much more difficult for the compiler than the present situation. User modifiable syntax is a very difficult to define consistently and very difficult to parse. The consensus so far appears to be that it is not worth the cost. >For example, I consider it unreasonable to have any language which does not >allow fixed point arithmetic. It may be said that this would slow down the >compiler. However, every compiler I have had access to is sufficiently slow >and produces sufficiently bad code that it would be hard to do worse. If the target audience of the language does not need fixed point arithmetic, the introduction of a fixed point type is counter productive. How many compilers have you looked at? Some produce very good code. Others are atrocious. It is far easier to criticize code generators than to provide a generator that produces better code. >I suggest that there be a major effort to produce an incomplete language >which is > 1. Not burdened by the obfuscated assembler terminology. We already have this. > 2. Easily extended by the user. What do you mean by "extended". Different notions have different costs and benefits. > 3. Designed with the idea that anything the user wants to do should >be efficiently representable in the extended language. What do you mean? Is the resulting representation efficient with respect to execution time? Is the resulting representation efficient with respect to run-time storage requirements? Is the representation of what the user wants concisely represented in the source? Choosing one of these options might lead one to design C, Forth or Prolog, respectively. > 4. Restrictions on the use of machine resources should be as >non-existent as possible, and should be overridable by the user if at all >possible. The restrictions on register usage in the C compilers I have seen I >consider a major felony. Many such restrictions are present to allow the resulting programs to be time efficient. This requirement is in conflict with what I suspect you want for point 3 above. > 5. Remember that the user knows what is wanted. I hereby execrate >any language designer who states "you don`t want to do that" as either a >religious fanatic or sub-human :-). Those who say that something should not >be allowed because "it might get you into trouble" I consider even worse. The user may know what is wanted, but translating that into code is not always a simple task. Consider assigning a boolean value to an integer. Is this something that "the user knows what he's doing" and the language should accept, or is it something that "the user doesn't want to do" and may "get him in trouble"? Almost always it is not what the user wants. If it is what the user wants, the result is usually a non-portable, difficult-to-understand program. (The management usually does not want the latter even if the programmer does.) > 6. Realize that efficient code does not necessarily take longer to >produce than inefficient, ... True, but the one in a thousand cases where this is true don't help much. Efficient code almost always takes longer to produce than inefficient code. You must invenst development time to get efficiency. >... and that there are procedures which are not now being used because the >programmer can see that the resources available to him will make the program >sufficiently slow that there is no point in doing the programming. If that is the case, the procedure was either not worth much to begin with, or not within the bounds of feasible computations given today's hardware. >I think that if a reasonable language were produced, we will see that there >will be a new era in algorithm development, and that the hackers will be >competing in producing efficient software. Algorithm development is independent of any specific language, so a new language will probably have little affect on algorithms. Hackers are already competing in producing efficient software, so a new language will have little affect here also. >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