🚀 go-pugleaf

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