Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!hcx1!hcx2!bill
From: bill@hcx2.SSD.HARRIS.COM
Newsgroups: comp.lang.fortran
Subject: Re: f8x impact on debugging (was: Re: y
Message-ID: <44400039@hcx2>
Date: 24 Apr 89 19:22:00 GMT
References: <12179@lanl.gov>
Lines: 49
Nf-ID: #R:lanl.gov:12179:hcx2:44400039:000:2323
Nf-From: hcx2.SSD.HARRIS.COM!bill    Apr 24 15:22:00 1989


> Actually, I didn't ask that question (I'll have to check back for who
> did).  But, thanks for your answer anyway.

Oops, sorry.

> It has been my experience, though, that adding new features doesn't prevent
> vendors from improving the Fortran compiler in other ways - it prevents
> them from spending time implementing other languages.  

What other languages?  :-) I don't know about your vendor, but we don't
implement a new language every day.  We're too busy keeping up with the
ones we have!

> A host of new Fortran features may actually cause the quality of
> commercial compilers to improve since the vendors will be forced to work
> on them again.

Don't you believe it!  Nothing could be further from the truth.  If their
existing FORTRAN compiler was designed with 8x in mind, then it probably
hasn't "matured" yet (it can't be too old, can it?); that is, it probably
still doesn't generate "wonderful" code, and may still be a bit unstable.
(In my experience, it takes about 3 years after the first release of a
compiler for it to become reasonably stable.)  In that case, the code
improvement and bug-fix rate is likely to slow considerably while all
those new features are put in.  In fact, I dare say the stability will
decline considerably, as those new features interact with the old ones
in exciting ways.  :-)

If their existing FORTRAN compiler was NOT designed with 8x in mind, then
adding those "host of new features" is likely to destabilize the compiler,
possibly forever.  If one were to consider all the costs involved, it
probably is not economically viable to add those features to a mature and
stable compiler.  You would be better off doing another one (perhaps
reusing some code from the old one), rather than making your existing
customers mad, losing benchmarking contests because the compiler aborts
(yes, it happens), etc.

Your comment suggests that the vendor isn't working on the compiler.  There
is probably a very good reason: if it ain't broke, don't fix it.
Compilers, like other large programs, eventually mature to a point where
any change breaks more than it fixes; the prudent vendor recognizes this
and stops making changes.

Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.harris.com or hcx1!bill@uunet.uu.net