Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!yetti!geac!daveb From: daveb@geac.UUCP Newsgroups: comp.lang.misc,comp.software-eng Subject: Re: Software Technology is NOT Primitive Message-ID: <1737@geac.UUCP> Date: Thu, 29-Oct-87 14:03:34 EST Article-I.D.: geac.1737 Posted: Thu Oct 29 14:03:34 1987 Date-Received: Fri, 30-Oct-87 23:56:46 EST References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <5077@utah-cs.UUCP> <594@l.cc.purdue.edu> <3603@sol.ARPA> Reply-To: daveb@geac.UUCP (Dave Collier-Brown) Organization: The little blue rock next to that twinkly star. Lines: 136 Xref: yetti comp.lang.misc:760 comp.software-eng:12 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." In article <3603@sol.ARPA> crowl@cs.rochester.edu (Lawrence Crowl) writes: | 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. Well, that's motherhood and apple pie, but it isn't **useful**. Perceived need has already affected the architecture of the machines, to the extent that need can be know a priori. In fact, both software and hardware developers have tried to seperately track user's needs. What they haven't done is track each other, about which Herman justifiably complains. || 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 think you're setting up a straw man.... An HLL instruction (/) may well be mapped into a ASR for those cases (constant-expressions) where the result is isomorphic with divide. And is, in a Pascal compiler I used recently. || 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. Well, if the library **designer's** language is machine independent, I'll vote for it. I would like the **implementer's** language to be machine-specific, even if it has to be assembler.... || 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. The consensus is not necessarily the truth: see ML (in the previous posting) as an example of a successful (if kludgily implemented) extensible language. || 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. The state of practice, as usual, is falling badly behind the state of the art... || 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. Bravo! One of the running jokes at a former employer's place of business was the manager or the accountant sticking his head in the programmer's office area and saying "but the programmer said", to which all the programmers would chime in "Nobody would evvvvvvvver want to do that". | The user may know what is wanted, but translating that into code is not always | a simple task. Once upon a time the pdp-11 C compiler assumed that the programmer was the boss. Its error messages basically meant "I don't know how to generate code for that". Casts were a method of giving hints to the compiler about how to interpret (generate code for) expressions. This was successful, but has been compromised as the compilers became less pdp-11 specific. || 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. You can precompute a surprising number of near-optimal sequences, in at least one case by running a prolong (oops, prolog) program across a very complete machine description, then binding the results into the compiler. | || ... 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. Since he was TALKING about hardware, you can assume that it is within the realm of possibility. -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.