Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!ut-sally!utah-cs!defun!shebs From: shebs%defun.uucp@utah-cs.UUCP (Stanley T. Shebs) Newsgroups: comp.lang.misc,comp.software-eng Subject: Re: Software Technology is NOT Primitive Message-ID: <5084@utah-cs.UUCP> Date: Wed, 28-Oct-87 00:21:52 EST Article-I.D.: utah-cs.5084 Posted: Wed Oct 28 00:21:52 1987 Date-Received: Sat, 31-Oct-87 03:22:39 EST References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <3603@sol.ARPA> <596@l.cc.purdue.edu> Sender: news@utah-cs.UUCP Reply-To: shebs%defun.UUCP@utah-cs.UUCP (Stanley T. Shebs) Organization: PASS Research Group Lines: 162 Xref: mnetor comp.lang.misc:802 comp.software-eng:15 In article <596@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >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. Then the software developer has dozens of tens of thousands of tasks to solve! There aren't enough software people in the world to solve each problem in an individual and idiosyncratic fashion, so instead several tasks are decreed to be "similar", which really means that some compromises have to be made. This situation is not unique to software. For example, bridge designers don't usually get new and unique rivets for each bridge - instead, they have to order from a catalog. Everybody wants every one of their programs to be maximally efficient on all imaginable hardware, while at the same time spitting on programmers because it doesn't happen at the press of a couple keys. It's unfortunate that the popular culture encourages the belief that hackers can conjure up complicated programs in a few seconds. I suspect it even influences people who should know better. To quote Fred Brooks, "there is no silver bullet". >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. I find it interesting that the people who have been programming the longest - numerical analysts - are exactly those who use dozens of different algorithms to solve the same problem, each with slightly different characteristics. Could mean either that multiplicity of algorithms is coming to the rest of computing soon, or that numerical analysts haven't yet found the correct forms for their algorithms... >> 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. I think you would have a hard time proving that the minor syntactic improvements of the Cray assembly language (with which I am familiar) have any effect at all on productivity, reliability, etc. After all, Lisp programmers can be immensely productive even though the assignment statement has a verbose prefix (!) syntax. >Who is the target audience? There is no adequate language for the production >of library subroutines. Aha! I wondered if that was the motivation for the original posting... You have touched upon my thesis topic; but you will not have to die for it :-). My thesis is most directly concerned with the implementation of Lisp runtime systems, which have many similarities to Fortran libraries (really). The basic angle is to supply formal definitions of the desired functionality and the hardware, then to use an rule-based system to invent and analyze designs. Not very intelligent as of yet, but I have hopes... Of course, this approach involves a couple assumptions: 1. As you say, there is no "adequate" language for the production of library subroutines. After poking through the literature, it is pretty clear to me that no one has *ever* designed a high-level language that also allows direct access to different kinds of hardware. There are reasons to believe that such a beast is logically impossible. The output of my system is machine-specific assembly language. 2. I also assume that human coding expertise can be embodied in machines. What compilers can do today would have amazed assembly language programmers of 30 years ago. There is no reason to believe that progress in this area will encounter some fundamental limitation. I've seen some recent papers (on the implementation of abstract data types using rewrite rules) that still seem like magic to me, so certainly more advances are coming along. Closer to reality are some compiler projects that attempt to figure out optimal code generation using a description of the target machine. This is extremely hard, since machine "quirks" are usually more like machine "brain damage". >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. Take a look at HAL/S, which is a "high-level assembly language" used in the space shuttle computers. Allows very tight control over how the machine code will come out. In fact, there are probably a few people reading this group who could offer a few choice comments on it... ><< 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. What's wrong with Forth? It can be extended in any way you like, it can be adapted to specific machine architectures, the syntax is better than raw assembly language, and its compilers don't do awful things behind the user's back. You'll have to be more specific on how it fails. I agree with you that C and Prolog cannot always be adapted to machine peculiarities. >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. How do you know it "does not need any registers for other purposes"? Are you familiar with the compiler's code generators and optimizers? Writers of code generators/optimizers tend to be much more knowledgeable about machine characteristics than any user, if for no other reason than that they get the accurate hardware performance data that the customers never see... >An obvious example of this is [...] the denial of such >simple elegant ideas as goto. "Goto" is neither simple nor elegant on parallel machines. >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. OK, this is the time to use assembly language. What's the problem with that? It's the accepted technique; no one will fault you for it. >> 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. (I assume 80-90% of optimal is meant) You had better come up with some hard evidence for that. Various computer scientists have been trying to prove for years that the right language, or the right method, or the right environment, or the right mathematics will make efficient programming "easy". So far no one has succeeded, but the journals are full of polemic and anecdotes masquerading as scholarly work. It's really depressing sometimes. No silver bullet... ><< Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 >> Lawrence Crowl 716-275-9499 University of Rochester >Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 stan shebs shebs@cs.utah.edu