🚀 go-pugleaf

: From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
: Message-ID: <By2MH8.JFB@mentor.cc.purdue.edu>
: I can get gcc on some machines, [..but..] it cannot be used for program
: design for more than one machine, which is something I am supposed to be
: involved in.  This is a major reason for asking for a good macro
: translator, to isolate the dependent problems from the independent ones
: and still be able to communicate. 

So it's supposed to be easier to invent an entire language from scratch
and target it to N machines, all producing good code, than to port an
existing compiler to M-less-than-N machines?  An interesting perspective,
one that has lead many people to reinvent the travois rather than use
steel-belted radials (kevlar belts being unavailable in their size). 

: I can communicate the algorithm to a mathematician using any one of those
: machines in such a way that a language hacker could come up with good
: code in consultation.

Yes indeed.  As I've been saying all along, Herman Rubin's problems are
primarily economic ones.  He hasn't allocated enough money (or other
incentives) to pay "language hackers" to work on his problems.  If
anything, he's been providing social DISincentives. 

:: So as near as I can see, solutions to the problems Herman Rubin
:: complains about are out there, and available for use now.  Herman Rubin
:: simply refuses to use them until they are customized for his needs to
:: an uneconomical extent.
: For an individual machine, they have always been there.  Programming in
: obfuscated assembler languages can do anything.

Which, of course, misses the point of what I said on two accounts.
First, I was not talking about "obfuscated assembler language".  I was
talking about tools for building high-level languages.  And second
(and most silly), it totally overlooks the *main* point, which was
the economic one.

:: The bottom line: Herman Rubin is attributing to malice and stupidity 
:: what is adequately explained by simple economics.
: I have generally charged inadvertence rather than malice.  However, I do
: charge anyone who leaves out something "because it can be misused" with
: malice.  I do charge anyone who says that "these tools are adequate to do
: a good quick job" with malice if it is not the case.

The "because it can be misused" is a straw man.  *Some* people claim
that "because it *tends*to*be* misused" as a reason to omit a feature,
but this is not really close to Herman Rubin's version.  And second,
most people I've seen respond to Herman Rubin's postings have NOT
held anything like this position.  Certainly, *I* do not.

The "these tools are adequate to do a quick job" being malice if the
"adequate" is false is blatant overstatement.  It may simply be a
mistake, or a misunderstanding of what "job" is involved.  Jumping to
the conclusion of "malice" is unwarranted, by a wide margin. 

: The situation is similar to what has happened to our educational system;
: we have set up procedures so that more harm than good has been done.  In
: education, teaching rote without understanding destroys minds and makes
: it difficult to acquire the understanding later; in hardware and software,
: restricting the possibilities makes subsequent flexibility much harder.

"I would agree with you if you were correct." In schools, there is a
demonstrated "dumbing down" of vocabulary and such, year by year, and it
is pretty plausibly linked to the misguided practice of removing
exposure to "above average" topics and vocabulary (where "average" is
based on last year's acheivement).  But in computer languages, the
notations are NOT getting less and less expressive as time goes on. 
Consider the standardized versions of Fortran over the years.  Or the
shift from C to C++.  Or Pascal to Ada.  Or the shift as various Lisp
dialects became Common Lisp. 

The general trend is for languages to become more and more expressive
over time, and for optimizations routinely done to be more and
more advanced, contrary to Herman Rubin's analogy above.

Note well, I'm not saying here that "most current languages solve Herman
Rubin's problems" or anything close to that.  Simply that Herman Rubin's
claim that languages are "dumbing down" over time is not consistent with
the facts of the matter. 

:: Yes, this  [.. the interface to code generation ..]
:: is the most central problem, which Jim Giles mentioned also.
:: Some method is needed which will specify the generated code, and yet
:: will fit in with the optimizations and register allocations and so on
:: which are already in place.  Jim says this "isn't too difficult", but 
:: I think it is the single most difficult part.  I've seen several
:: solutions, each with some advantages over the others.

: THIS is one aspect of the problem; the attempt to get a detailed complete
: package, instead of putting partial solutions together; the attempt to
: take the programmer out of an interactive optimization procedure with the
: compiler; the failure to realize that the present so-called optimizations
: and register allocations are often bad; etc.

Herman Rubin's complaints here simply do not follow from what I said.  
I said the problem was hard, and no single solution I was aware of was
clearly better than others.  It does NOT follow that I advocate doing
nothing.  I said that inserting explicit instructions in the istream
requires integration with automated optimizations to be effective.  It
does NOT follow that I want to "take the programmer out of an
interactive optomization procedure".  I implied that the baby of current
automated optimizations should not be thrown out with the bathwater of
increased programmer control.  This does NOT imply that I think current
"so-called optimizations" are all perfect, or even good. 

Herman Rubin is simply putting up a straw man here.  Certainly,
I don't acknowledge the effigy as a good likeness of ME.

:: [...] if a programmer comes up with something unforseen by the
:: optimizer, there's no simple way to give a hint about it.
: So put in simple ways to give hints, instead of saying that no hints
: can be given.  

Another non-sequitur.  I never said that "no hints can be given".

: The difference is not the last 1% of speed, but often
: 50% of the running time or more.

Herman really has a case where "hints to the optimizer" about single
instructions can yield 50% of the running time of a whole system?  Wow. 
The most I've ever seen was 5 to 10 percent of time in a system spent on
a single instruction in an early version of a hash routine. 

Of course, the point is unaffected by this...  the point is, if istream
changes of that granularity affect performance that needs to be had,
there's no alternative to specifying the istream by hand. 
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw