Drew McCormack wrote:
> Not at all. None of that would be lost. Any new language could simply
> be built on top of the current fortran backend. Any new language should
> basically include Fortran 90's nice array capabilities; they are the
> state of the art. Fortran falls down somewhat in other areas in my
> view, and it is there that improvements could probably be made.
>
Have you ever worked in a commercial compiler writing setting? Such
transplants are typically difficult, and are often infeasible (viz. cost
more than rewriting). At least that's been my experience.
>> A
>> much better alternative is for users to actually express real interest
>> in
>> pure dialects of Fortran such as F. It will be relatively easy for
>> vendors to
>> restrict their front ends to F-like syntax. But this has not
>
Because there is no real market for strict subsets.
>
> I think the C++-Java comparison is useful here. C++ extends C, and has
Yes, as was discussed to death many times before. C++ is *not* merely an
extension of C (viz. it's not a strict superset, see the classic Bjarne
paper approximately titled ": C++: As close to C as possible - but no
closer" (as C had been begotten from Algol, etc.). The "algol" leg of
language evolution has been to have discontinuities, while Fortran has
tried to move forward without tossing away the installed base. The
former has proved to be "better" in that old code (e.g. all C code is
now "old" code ;>) runs fine with old processors (and the cost of
maintaining such processors isn't all that steep; but one shouldn't
think that it's zero either! as the system evolves, as the
microarchitectures change, a performance oriented or a debugger oriented
environment (worse, both;>) takes a lot of "running in place" to stay
"the same") while the latter has proved to be more challenging (writing
a performance competitive parallelizing Fortran 9x compiler typically
inherited very little code from it's predecessor, but was expected by
the users to have all the same behaviors on old codes ... even beyond
that required by the Standard...).
> for developers in the short term, because people have to rewrite some
> code, it is better for the software produced in the long run.
>
People don't (in the aggregate) rewrite the code. They link to it. For
example, the OS core isn't recoded in Java. It continues to be a C
entity (at least for the Unix, and Unix like systems; no doubt much of
the PL.8 codebase at IBM and various other languages in other places,
remain). Nor is that likely to change. Note that it hasn't been recoded
in C++ either ;>
> Don't agree here. I'm not for J3 'retiring' fortran either. Keep
> fortran going, but let's start developing a more modern scientific
I suppose it depends on what one means by "keep going". In the 80's and
90's I was a strong supporter of the "radical" upgrades to Fortran. As
most of the committee probably recalls, I eventually came to see the
error of my ways. We would have been much better off with a Fortran
which nailed down more of the existing practice and increased
portability ... and left the major innovation to some successor
Fortran-like language.
> also work seamlessly with code written in fortran (and maybe c). Then
> let the marketplace decide.
Working seamlessly is not necessarily possible (consider objects for
example, C++, smalltalk, Java and Fortran2003 all have radically
different object models. Seamless is simply infeasible. But for some
subset of fundamental data types, it should be possible (if not
seamless). As some, no doubt, are tired of hearing, one of the major
problems I had with the OOF proposals net out to be that we've created
yet another hard to bridge interoperability problem for the next
generation. It may have been too early to know whether the winner in the
Object universe at large was going to be Java, C+, C# (it's clear it's
not SmallTalk ;<) but there is no practical hope that it will be
Fortran, and getting at "platform" objects is going to present
entertaing interoperability challenges (vs. having picked a model which
was the same as the most common platform). It was too late to have any
shot at "winning" and too early to know which model *should* have been
cloned....
Oh well, back to my rock.
--
Keith H. Bierman [log in to unmask]
Sun Microsystems PAE | [log in to unmask]
15 Network Circle UMPK 12-325 | 650-352-4432 voice+fax
Menlo Park, California 94025 | sun internal 68207
<speaking for myself, not Sun*> Copyright 2003
------------------------------------------------------------
NOTICE: This email message is for the sole use of the
intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited.
If you are not the intended recipient, please contact
the sender by reply email and destroy all copies of the
original message.
|
