🚀 go-pugleaf

In article <594@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

>I suggest that there be a major effort to produce an incomplete language
>which is 
>        1.  Not burdened by the obfuscated assembler terminology.
>
>        2.  Easily extended by the user.
>
>        3.  Designed with the idea that anything the user wants to do
>should be efficiently representable in the extended language.

Sounds like you want Forth.

>        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.

There are reasons for those restrictions, as is clear from studying one
or two compilers.  Some registers are needed for implementing protocols,
particularly in function calling.  Other registers are used for constant
values (0, 1, -1 are popular).  You should try writing a register allocator
before engaging in name-calling.

>        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.

By your rationale, every language should include PEEK and POKE, and the
hardware shouldn't generate any of those silly "segmentation violation"
traps.  Lisp systems should allow the programmer to acquire the address
of an object, even if it will be worthless one millisecond later when the
garbage collector kicks in.  I hardly think a responsible language designer
would include a capability that has proven from experience to be a source
of catastrophic and mysterious bugs, especially if the capability itself
is not particularly important.
 
>        6.  Realize that efficient code does not necessarily take longer
>to produce than inefficient, [...]

Efficient code *will* take longer, if only because you have to spend time 
on profiling and analysis.  Of course, you might be lucky and write efficient
code on the first try, but it doesn't happen very often.

>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.

The whole proposal sounds like something out of the 50s or 60s, when debates
raged over the value of "automatic programming systems" (like Fortran!).

It is interesting to note that the proposal omits what is probably the #1
reason for HLLs: PORTABILITY.  It's all well and good to talk about exploiting
the machine, but my tricky code to exploit pipelined floating point operations
on the Vax will be utterly worthless on a Cray.  The prospect of rewriting
all my programs every couple years, and maintaining versions for each sort
of hardware, would be enough to make me go work in another field!

In fact, the view that software should be independent of hardware is one of
the great achievements of software technology.  The battle of abstraction vs
specialization has been going on for a long time, and abstraction has won.
The victory is rather recent; even ten years ago it was still generally 
assumed that operating systems and language implementations had to be written
in assembly language...

>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907

							stan shebs
							shebs@cs.utah.edu