🚀 go-pugleaf

Here is the second half the articles I've received to date that should
have gone exclusively to comp.lang.misc, but were cross posted to
comp.unix, as well.  I have no idea why I'm getting all of these.
Please stop it.  I plan to discard any further such messages I receive.
Thanks.
-- 
Ron Heiby usenet@mcdchg.UUCP	Moderator: comp.newprod & comp.unix

----------

From: gatech!rutgers!l.cc.purdue.edu!cik (Herman Rubin)
Summary: We can do a much better job if we are flexible(very long)
Organization: Purdue University Statistics Department

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

----------

From: gatech!rutgers!pioneer.arpa!eugene (Eugene Miya N.)
Organization: NASA Ames Research Center, Moffett Field, Calif.

In article <5084@utah-cs.UUCP> shebs%defun.UUCP@utah-cs.UUCP (Stanley T. Shebs) writes:
>Take a look at HAL/S, >space shuttle computers.
>In fact, there are probably a few people reading this group who could
offer a few choice comments on it...

You asked:
	Grrrrrr.

>From the Rock of Ages Home for Retired Hackers:

--eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA
  "You trust the `reply' command with all those different mailers out there?"
  "Send mail, avoid follow-ups.  If enough, I'll summarize."
  {hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene

----------

From: gatech!rutgers!cs.rochester.edu!ken (Ken Yap)
Organization: U of Rochester, CS Dept, Rochester, NY

Let us not forget that the computer is a tool and that raw computing
speed is but one measure of the effectiveness of the hardware.  If that
computing power has to "go to waste" in a spreadsheet program, I don't
care, as long I get *my* job more effectively. All those cycles going
into painting a bitmap window, think it's a waste? Fine, want to design
METAFONT characters with punch cards, or even a glass TTY?

I used to wonder what we would do with all those MIPS of computing
power hardware would give us. Now I realize that there is at least one
application that can soak up any amount of CPU power you can get -
advanced interfaces. Have a look at the October SciAm issue. Take the
Wired Glove.  Imagine a biochemist being able to experiment with
molecules by "handling" them. Would you begrudge all those cycles
required to support this mode of interaction? I certainly wouldn't.

	Ken

----------

From: gatech!rutgers!sunybcs!sher (David Sher)
Keywords: software hardware measurements
Organization: SUNY/Buffalo Computer Science

(Followup's to comp.lang.misc)
Time for a stupid analogy:
Someone gives me a 2 watt power line and asks me to build a toaster:
So using my electronics ability and ingenuity I build a toaster that
toasts a piece of bread that was very carefully placed in it in about
15minutes.  

However things advance and he now hands me a 2 Megawatt power line
and says ok buid me a toaster,  and I throw together a toaster that
toasts bread in about 1 minute.  (The most work going into making sure
the user does not electrocute himself.) He then comes back and complains,
I gave you a million times as much power and you only give me a factor
of 20 speedup!  Power engineering sure advances faster than electrical!

Disclamer: As should be obvious by now, I know nothing about constructing
appliances.   This story is not true, and the names have been changed to
protect the innocent and all that stuff.  
-David Sher
ARPA: sher@cs.buffalo.edu	BITNET: sher@sunybcs
UUCP: {rutgers,ames,boulder,decvax}!sunybcs!sher

----------

From: gatech!rutgers!ucbvax.berkeley.edu!ames!lll-tis!oodis01!uplherc!esunix!bpendlet (Bob Pendleton)
Organization: Evans & Sutherland, Salt Lake City, Utah

in article <36KEN@ORION>, KEN@ORION.BITNET (Kenneth Ng) says:
> hardware today, try adding LRU caching, address lookaside buffers,
> I/O processors, massive error detection and correction logic, ethernet
> and other communication technology, paging, the entire virtual memory
> schemes on a lot of machines, etc., etc, etc.

> Kenneth Ng: ken@orion.bitnet

Why compare hardware and software at all? Its like comparing roads and cars.
Cars even run on roads, much like software runs on hardware. ( Forgive the
awful analogy. It is deliberately obsurd. ) Even though they affect each 
others development, the technologies are very different.

Look at LRU caching and paging. This technique depends on a statistical 
property of programs in general, but to get maximum performance from a
given machine a programmer needs detailed knowledge of its implementation
on that specific machine.

Two very different technologies. Two very different points of view.
Two different cultural heritages.

		Bob P.
-- 
Bob Pendleton @ Evans & Sutherland
UUCP Address:  {decvax,ucbvax,ihnp4,allegra}!decwrl!esunix!bpendlet
Alternate:     {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!bpendlet
        I am solely responsible for what I say.

----------

From: gatech!rutgers!cs.rochester.edu!crowl (Lawrence Crowl)
Organization: U of Rochester, CS Dept, Rochester, NY

In article <4943@ncoast.UUCP> crds@ncoast.UUCP (Glenn A. Emelko) writes:
>In those rough times [of 16K memory], people were very concerned and concious
>about storage, both on disk, as well as memory usage.  This forced software
>engineers to think creatively, to tighten code, and to produce very powerful
>LITTLE algorithms that could do many things and could be called from many
>other parts of the code.

It also forced them to spend a lot of money achieving these goals.

>Code was many times designed to be recursive, if not reentrant, and it was
>expected that the software engineer knew alot about the machine and
>environment (in terms of the hardware) that was hosting the program, which
>allowed for tricks and little magical wonders to happen (laughing, in other
>words, the designer took advantage of what was available).

It also make anyone else maintaining or porting the program spend weeks (read
thousands of dollars) just trying to understand a small program in order to
accomplish the task.

>In contrast, today, many designers know nothing about the destination machine
>(it's a UNIX box?), and most are not very concerned about how much memory,
>disk space, or anything else that they use, and really could care less if
>there are four subroutines in their code which could be combined into one
>general purpose all encompasing sub.

The also produce a functionally equivalent program in far less time which is
available on far more machines.  (Boss, I can spend eight more weeks and double
the speed of program.  Of course, then it will only run on the 40 or so
machines which are exactly like our development machine.)

>In fact, I have noted many specific cases of generally sloppy, slow, and
>out-and-out crude coding techniques passing as "state of the art," simply
>because it is running on a machine that is so blindingly fast that it does
>make that code seem reasonable.

Not fast, cheap.

>Yes, I am talking about the "most popular" spreadsheet of 1984, and a lowly
>Z80 machine ripping it to shreads [speed-wise]!  Is this the current state of
>software technology?  Yes, I believe so.

Which goes to show that raw performance is not highly valued by customers.

>We have software today which can probably be out-run by the software of 1978,
>even when we use it on that powerful processor.  Sure, it's USER FRIENDLY,
>ERGONOMIC, etc., but does it keep pace with the advances in the industry?

Raw speed is only one aspect of advances in the industry.  Hardware
concentrates on speed while software concentrates on functionality.  (Mr.
Customer, I am giving you a fast sort, but I do not have time to implement
a backup utility.)

-- 
  Lawrence Crowl		716-275-9499	University of Rochester
		      crowl@cs.rochester.edu	Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl	Rochester, New York,  14627

----------

From: gatech!rutgers!cs.rochester.edu!crowl (Lawrence Crowl)
Organization: U of Rochester, CS Dept, Rochester, NY

In article <596@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>[reguarding access to machine specifics from high level languages]

See Stanley Shebs's article <5084@utah-cs.UUCP>.  I will not address those
topics which he addresses.

>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
>integer arithmetic; ...

You are still oriented on supporting the hardware instead of describing a
solution.  A real high level language is independent of the word size.  If a
machine does not have a long integer, the implementation of the language must
build it from short integers.

>... of the machines I have looked into in the past few years, no two have the
>same floating-point arithmetic.

Given that highly accurate floating point routines are heavily dependent on
specific floating point formats, this is a problem.  No high level language
will be portable from machine to machine when the formats are different.  The
IEEE floating point standard should help.

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

Any language which allows the programmer to make use of the quirks must make
them visible.  This makes the language complex, difficult to understand,
difficult to reason about and makes the resulting programs non-portable.

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

If you are trying to get 100% performance, you will have to use assembler.
No language that has any meaning beyond a single machine can hope to meet your
needs.  It seems that your real complaint is that assembler languages are too
verbose, not that high level languages do not allow sufficient access to the
machine.  It should not be too hard to whip together an expression-based
"pretty" assembler.

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

Very few languages are incomplete in the sense of being able to compute an
arbitrary function.  However, assembly languages are examples of incomplete
languages.  All languages are incomplete with respect to their support of
the programmer for some application area.  It is true that there are no
languages tuned to the machine specific implementation of highly optimized
numerical libraries.  I suspect it would look very much like the "pretty"
assembler.

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

You apparently program in a very narrow world where performance is everything.
The vast majority of programming is not done in such a world.

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

C++ allows programmers to introduce new types and overload existing operators.
It does not allow the definition of new operators, but does allow definition of
functions which achieve the same effect at the cost of a slightly more verbose
syntax.

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

So complain to the compiler writer.  This is not the fault of the language or
of its designer.

>[Efficient code takes longer to produce than inefficient code] because of the
>badness of the languages.

Effient code takes longer because the algorithms are generally more complex,
not becuase the languages are bad.

>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

----------

From: gatech!rutgers!ihlpf.ATT.COM!joelynn (Lynn)
Organization: AT&T Bell Laboratories - Naperville, Illinois

I agree with Glenn's opinion of today's "software".

I would like to add my .02.

Having programmed on the old Z80 based TRS80 with 4k and then 16k to work on,
I have just gotten tired of trying to keep up with the hardware.
It seems the more I learned about the machine's capabilities, the faster
the machine changed.  The sooner my programs became obsolete.  I just
got tired of relearning a new operating system to find it out of date in
a couple short months.  For this reason, I welcome UNIX.
BUT...
I have been handicapped by UNIX simply because it cannot use the total
environment available to it.  This, i think is due to the inability
of the current generation of programmers to look at the whole picture
of what is to be done, and what may be requested of the routine.

----------

From: gatech!rutgers!ll-xn!culdev1!drw (Dale Worley)
Organization: Cullinet Software, Westwood, MA, USA

crowl@cs.rochester.edu (Lawrence Crowl) writes:
| 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.

This is not so simple...  What do you mean by "division by 2"?  There
are actually at least two ways of doing integer division:  one way is
to always round the mathematical quotient towards 0.  This is the
common, or "Fortran", way to do it, but to a certain extent it is
historical accident that most programming languages do it this way.
Of course, this is *not* what arithmetic right shift does.

But this method is not necessarily the most natural way to do
division.  In many cases, this is more natural:  round the
mathematical quotient *down*, that is, more negative.  This is
equivalent to the common way for positive quotients, but is different
for negative quotients:  (-1)/2 = -1.

(If you think this method is silly, consider the problem:  I give you
a time expressed in minutes before-or-after midnight, 1 Jan 1980.
Find the hour it occurs in, expressed in hours before-or-after
midnight, 1 Jan 1980.  The advantage of the second division here is
that the quotient is computed so the remainder is always positive.)

I have had to write functions in several programming languages to
perform this second form of division.

Dale
-- 
Dale Worley    Cullinet Software      ARPA: culdev1!drw@eddie.mit.edu
UUCP: ...!seismo!harvard!mit-eddie!culdev1!drw
If you get fed twice a day, how bad can life be?