Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!rutgers!iuvax!pur-ee!j.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc,comp.software-eng Subject: Re: Software Technology is NOT Primitive Message-ID: <596@l.cc.purdue.edu> Date: Tue, 27-Oct-87 10:38:38 EST Article-I.D.: l.596 Posted: Tue Oct 27 10:38:38 1987 Date-Received: Fri, 30-Oct-87 01:16:04 EST References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <3603@sol.ARPA> Organization: Purdue University Statistics Department Lines: 242 Summary: We can do a much better job if we are flexible(very long) Xref: mnetor comp.lang.misc:799 comp.software-eng:14 In article <3603@sol.ARPA>, crowl@cs.rochester.edu (Lawrence Crowl) writes: > 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. Which of the tasks to be solved should the software developer consider? On one machine there may be hundreds or even tens of thousands of users. Some of these users may have dozens of different types of problems. > << 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. 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 inte- ger arithmetic; of the machines I have looked into in the past few years, no two have the same floating-point arithmetic. This includes the CDC6x00, VAX, CYBER205, CRAY, PYRAMID, IBM360 and its relatives. And should we use the same algorithm on different machines? I, for one, would question the intelligence of those who would attempt to enforce such restrictions. 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 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. > 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. If the instruction is not there, it cannot be used. It may be worth replacing, or it may be desira- ble to completely revise the computational procedure. After a program is written, especially a library program, it may be found that quirks in the machine cause the program to be too inefficient. In that case, it is necessary to think the whole program design over. A good programmer will soon learn what is good on a particular machine and what is not. 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. These algorithms cannot be programmed in any HLL and be worthwhile. (Any machine architecture can be simulated on any other machine with any sufficiently complex language if there is enough memory, but the resulting program is not worth attempting.) There are algorithms which are clearly computationally very cheap, using only a few simple bit operations, for which it is obvious that no HLL can give a worthwhile implementation, and for which it is questionable as to which machines have architectures which make those algorithms not cost an arm and a leg. << 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. > Of course the user must decide what is needed. << 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. > If the syntax is somewhat limited, it will still be very powerful and not so difficult to parse. The reason that the typical assembler language is so difficult to use is due to the parsing difficulty 35 years ago. Except for not using types, Cray's assembler constructs on the CDC6x00 and on the CRAY's go far in the right direction. << 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. > Who is the target audience? There is no adequate language for the production of library subroutines. If you say that the audience does not exist, then you are certainly wrong. If you say that the audience is small, then one could equally criticize the existence of a Ph.D. program in any field. 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; in fact, I believe that this exemplifies one of the major reasons for the brain-damaged nature of our youth. How can a compiler produce good code if it cannot use the instruc- tions necessarily involved in that code? If fixed point arithmetic is needed, the tens of instructions needed to achieve that in a language such as C do not constitute good code if the hardware is available. 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. << 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. > 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. << 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. > First execution time, second storage. I do not advocate obfuscated code to attain this, and I do not believe it is necessary. None of the languages you have cited meet any of my points. << 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. > 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. << 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. > An obvious example of this is structured programming and the denial of such simple elegant ideas as goto. The bit-efficient algorithm above starts out with a case structure; I immediately observed that, by 99.999% of the time keeping the case as a location only and using goto's, the code would be considerably speeded up without any loss of clarity. > 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.) > I agree that the resulting program will probably be non-portable. I do not agree that it will necessarily be difficult to understand. There are cases where the program will be difficult to understand. The algorithm I mentioned above which is bit-efficient would be incomprehensible to someone as knowledgeable as myself about the mathematics involved without having a description of what is being done at each stage. This would be true regardless of any programming tools available. The algorithm is not very difficult with the explanation. << 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. > This is because of the badness of the languages. I do not mean completely efficient code is easy to produce, but I thik that 80% to 90% will not be that hard to get. << ... 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 the fact that the use of machine instructions which I produce without trying very hard to get reasonably efficient procedures is a sufficient rebuttal. << 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. > It is true that the language does not directly affect the algorithm. However, someone who considers whether or not there is any point in implementing the resulting algorithm will necessarily consider the available tools. If an algorithm involves many sqare roots, I would be hesitant in using it rather than a less efficient one which does not unless square root is a hardware instruction, which it should be but is not on most machines. The number of reasonable algorithms is infinite, not merely very large. << 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 -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet