Hello

Have you looked at F?  I do not know if Walt is considering a F for 2003
F2003 I suppose.  This is Fortran 90 with all the baggage removed.  I think
that Walt and Dick did a good job with F.

Alistair

Alistair Mills
[log in to unmask]
0118 989 2925


-----Original Message-----
From: Fortran 90 List [mailto:[log in to unmask]] On Behalf Of
Drew McCormack
Sent: 27 February 2004 08:09
To: [log in to unmask]
Subject: Re: Stir it up again? (was: Retire FORTRAN?!)

The posting below makes many good points, with the general thread being
that most languages are imperfect, and fortran is not any less perfect
than existing languages. I think I can agree with this.

As usual, this discussion has brought up many criticisms of C++,
usually as a means of justifying fortran failings: "C++ is much worse
than fortran in this respect, so fortran must be OK."  I am not about
to come to C++'s rescue; it is a diabolical language in many regards.

But consider this: C++ is being replaced in its application domain by
other languages, like java and C#. C++ will eventually die. Many of the
mistakes made in C++ have been improved upon in newer languages, and
eventually everyone will have made the transition to the new-improved
model.

What I am trying to say is that the way things work in the general
world of software is that languages have a limited lifetime. They begin
as the latest and greatest, like C++ in the 80's, and later get
superseded by improved languages like Java. They don't usually go away
completely, but instead die a long slow death as people make the
transition to the newer languages. (Note that plain C is probably an
exception in this regard, because C has really taken on the position of
THE low-level language.)

I have not signed the petition, because I don't see any point trying to
force fortran to die. At the same time, I don't see why fortran should
necessarily remain the scientific language for all time, just as C++
has not remained the boss in other domains. There should be a natural
evolution, with each new language taking the best parts of the previous
generation, and improving on the rest. This does not seemed to have
happened in scientific programming, and perhaps it should.

So I would be quite happy to see competition for fortran. There is no
question that legacy aspects of fortran are a burden. Take something
simple like the 'implicit none' I have to write at the top of every
subroutine. This should not be necessary in any modern language, but is
required in fortran for legacy reasons. It is not easy to 'fix' fortran
in this respect, but a whole new scientific language certainly could
address it.

If someone is to define a new scientific language, here is my wish list:
- Fortran 90 array syntax, and performance
- Python like simplicity, and OO features
- Unlike python, a compiled or just-in-time compiled language
- Possibly garbage collection, perhaps with the possibility of
overriding to perform manual memory management
- Perhaps some generic programming, like C++'s templates, but hopefully
somewhat simpler.
- Simple (I have to teach this thing to students with little
programming background)

Actually, looking at this list, java goes quite a long way, but not all
the way. For example, it doesn't have built in multi-dimensional
arrays, or fortran 90 array ops. These are essential in a scientific
language.

Drew McCormack



On Feb 26, 2004, at 6:20 PM, David LaFrance-Linden wrote:

> I'm not a Fortran programmer, but hear me out.  I learned enough F90
> (and HPF) to write an F90/HPF debugger.  Believe me, as a result I'm
> aware of many corner cases of the type and expression system, calling
> conventions, copy-in/copy-out, etc, that many people aren't.  I also
> have a knack for computer languages.  I've also seen (back in the
> Common Lisp standardization days) the battles between "the language"
> and "the environment" as well as "purity" and "practicality".  I
> believe I understand Fortran's role in the world.  Bottom line, I
> think Fortran is the right language for much of the HPTC community; it
> has powerful array mechanisms, good formulaic expression, and lots of
> compiler work over the decades.  I read the petition items and respond
> in my own way below.  In general, many of the items have nothing to do
> with Fortran that language, and those that do are also true of
> most/all languages.  An interesting spoof might be to write a petition
> for retiring C++, and another for Java, based on this format and it's
> arguments.  I'd sign them!
>
> Jing Guo states:
>
>     Therefore, I think these "whiners" should be treated seriously,
>     not literally by their complaints, but for deeper reasons
>     behind their persistent complaints.
>
>     I actually work with people like them and hear their complaints
>     everyday.  They *are* developers we rely on to improve, modernize,
>     and develop Fortran software.  The complaints were never new,
>     except that they were raised by *every* group of developers with
>     different emphasis.  Also, they were *rearly* properly addressed.
>
> The above is true of C, C++ and Java.  Serious people have complaints,
> they are seldom addressed, and life goes on.  I'm not trying to
> belittle the problem, but when I have such discussions with people the
> end result is usually that I point out how all the other alternatives
> raise semantic nightmares much worse than what the language already
> states.  I've learned that people on standards committees are *REALLY
> SMART PEOPLE*.  Sometimes I come up with a corner case, only to
> discover they've already thought about it.  Arm-chair language design
> is just that: arm-chair.  It is *REALLY HARD* to design a language
> that balances sufficiency of consistency and utility.  Somebody is
> always going to be unhappy, but if they have enough energy to
> complain, I would hope they have enough energy to understand and
> appreciate why it was done the way it was.
>
> ----------------------------------------
>
> My assessment of the petition:
>
> (1) FORTRAN2003 Is Unlearnable.  Matter of opinion.  All languages are
> unlearnable, especially the non-basic parts of C++.  The major issue
> here is a person's ability to grasp the concepts and apply them.  IMO,
> the real problem is forcing scientists to do programming.  Much better
> would be a corp of scientifically trained computer engineers; let the
> scientists do the science, interface with the engineers, and let the
> engineers do the programming.
>
> (2) FORTRAN2003 Is Unimplementable.  Why do you care?  I'm sure there
> is vendor representation on the standards committee.  If a feature
> renders too many vendors against it, it will be a deal-killer.
> Therefore, almost by definition, the standard is inplementable.
>
> (3) The FORTRAN Business Model Is Not Sustainable.  Why do you care?
> This is a market force item and says nothing about the language.  If
> the business model is indeed not sustainable, it will collapse on its
> own, in its own way, in its own time.  You are free to jump ship at
> any time; that doesn't doom the ship.
>
> (4) An Arcane Language Does Not Attract New, Talented Developers.
> "Arcane" is a matter of opinion.  Fortran has been progressing over
> the years to include structure in both data and control flow, and with
> F2K3 more modern concepts.  Hardly "arcane."  The way to attract
> talented developers is to make the tasks exciting, important and/or
> relvent.  That says nothing about the language.  People flocked to
> Java because it was the newest sexy language that "fixed" all the
> problems of C/C++.  And I can tell you it attracted almost everybody,
> read: including the incompetents.  Focus on the ends, not the means.
> There are plenty of exciting ends out there for which Fortran is the
> appropriate means, and that is how you will attract the *truely*
> talented developers.
>
> (5) FORTRAN2003 Adds No Functionality.  I can't comment technically,
> but I'll point out that by the same argument C++ added nothing on top
> of C.  After all, cfront was a program that translated C++ into
> corresonding C.  The point: Syntax is important, precisely because it
> does make things easy.  To make this point even stronger, Common Lisp
> has (language-level, not preprocessor) macros, which allow the user to
> extend the syntax of the language to embody a concept.  Embodying
> concepts facilitate expressibility, expressibility narrows the gap
> between thought and implementation, and anything that can be done to
> narrow that gap is good.  (Preprocessor macros only go 5% toward that
> end.)
>
> (6) FORTRAN Ignores Long-term Trends in Computer Architecture.
> Fortran is no better or worse than C or C++.  Remember that I/O is not
> part of the C or C++ language; I/O is provided by libraries and
> toolkits.  It would actually be a bad idea to wed these "long-term
> trends" into the language, precisely because the trends keep
> changing.  Suppose Fortran directly supported SMPs.  Well, then comes
> NUMA which requires yet more extensions/toolkits.  C and C++ are no
> different.  Even UPC as-the-language expresses parallelism in a
> certain way, which gets optimized by the compiler and runtime for the
> particulars of the hardware and interconnects.  It is important that a
> language does not exclude these long-term trends, but it should be
> very careful about adopting them *into the language*.
>
> (7) FORTRAN Syntax Is Archaic.  Compared to?  The only character on my
> keyboard that C doesn't use is $, @ and `, and some extensions allow $
> as an identifier.  To be explicit, it uses all of
>         ~!#$%^&*()_+-={}[];:'"\|,<.>/?
> It's a nightmare.  C++ is even worse because of how it combines some
> of them (e.g., ->*)  Java simplified things a bit.  IMO, Lisp has the
> simplest syntax, but people dislike all the parens, and *THAT* is
> largely a failing of the language-insensitive editors they have, which
> has nothing to do with the language proper.
>
> (8) FORTRAN Makes Simple Programs Difficult To Write.  Wait a minute,
> are you trying to write simple programs, or are you trying to derive
> simple programs from larger ones.  Those are two different issues
> which the commentary confuses.  To write a small program, you don't
> have to use modules.  When was the last time you tried to derive a
> small C++ program from a large one that had a huge class hierarchy,
> most of which wasn't going to be used.  This is not a language issue,
> it is a fact of life, for all languages.
>
> (9) New Language Features Inhibit Optimization.  Various rules of F90
> are quite clear that if the user aliases data the result is undefined,
> and this allows compilers to do optimizations that C/C++ compilers
> cannot because C/C++ language explicitly allows the user to alias
> data.  Another fact of life: Users who really care about ultimate
> performance will always learn how to tune their coding style to take
> advantage of the compiler/hardware combination, and that's true for
> all languages.  For those that want good performance, Fortran
> optimizations are still ahead of the curve than C/C++.
>
> (10) FORTRAN2003 Has Too Many Subtleties.  Pop quiz: In Java, what's
> the difference between a Vector, a List, a ArrayList and a LinkedList?
> If you think that's confusing, try using Java's AWT or Swing packages.
> Pop quiz: In C++, when should I use reference parameters and when
> should I use pointer-to parameters?  The real problem here is that as
> CS-types build upon the shoulders of their predecessors, languages
> grow.  That growth pulls in new concepts, sometimes that are closely
> related (Fortran's POINTER and ALLOCATABLE, C++'s reference and
> pointer-to) but serve different purposes.  That isn't the fault of the
> language.  Yes, subltties are introduced, and that is why I'll repeat
> my claim from point (1): Much better would be a corp of scientifically
> trained computer engineers; let the scientists do the science,
> interface with the engineers, and let the engineers do the
> programming.
>