🚀 go-pugleaf

pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>The problem, bfore considering market demand, can also be expressed
>thus: should David Chase and Jim Giles and Preston Briggs and Hank Dietz
>(just to mention some frequent contributors to this sort of discussion)
>spend their time devising ever more ingenious and complicated and hairy
>code generator level hacks, or would their research and development
>efforts be better spent on clever compilation of higher level languages
>and source level programmer's assistants? 

I *was* working on (not yet clever) compilation of a slightly higher
level language at Olivetti, but we all got laid off in February and
had to find new jobs.  It's very nice being employed, paid, and
appreciated.  Without a job, one tends to consider market demand,
especially with a baby on the way and no national health insurance.

There's no lack of higher level alternatives that would probably be
more reliable than C, C++, and Fortran, optimized or not, and many of
my colleagues, advisors, and advisors' advisors have tried hard to
sell/give/push them to the rest of the world.  So far, they've had
little luck.  I'll bide my time; there's many interesting aggressive
optimizations that can also be applied to high level languages too,
when they finally catch on.  To quote Rovner (PARC CSL-84-7):

"Time spent by programmers to solve storage management problems has
decreased from an estimated 40% in Mesa to an estimated 5% in Cedar
(...). Automatic storage deallocation can improve programmer
productivity dramatically without affecting performance adversely."

That's the big picture that you're looking at, and the one that I'd
like to look at, but so far the programming public in general is not
interested.  We've tried very hard to get them interested, but not
much luck yet.  (I.e., at least in this case you are preaching to the
choir).  Now, once you've opted for C/C++/Fortran, and the ultimate
importance of efficiency, one might as well deliver it as reliably and
portably as one can.  Optimizing compilers fill that (very large)
niche; they tend to be less buggy at optimizing C/C++/Fortran than
your average programmer, and tend to do a good job.  Compilers can be
regression-tested, and their known bugs can be catalogued, and
hopefully repaired -- neither of these things holds for humans.

Those people on the C/C++ bandwagon who *are* interested in garbage
collection are discovering that optimizations (not even terribly
aggressive ones) *correctly* applied to C/C++ can prevent the correct
functioning of many garbage collectors, unless "volatile" is applied
liberally to the code (this is massive overkill, but it makes the
collectors work).  Daniel Edelson's C++ collector is *probably* robust
in a single-threaded process, especially if a small number of
"volatile" declarations are used, and may be robust in a
multi-threaded process (the possible non-robustness appears only if a
compiler is very aggressive about tracking of aliases and reordering
of loads and stores for scheduling or other purposes -- clearly, this
is permitted -- else why would the language have "volatile" in it?)

If I were king of the world, things would be different.  But I'm not.

David Chase
Sun Microsystems