I believe the profession used to be called 'systems analyst'.  If you look on this list you might find one or two - but they might prefer another name.

Gaz

-----Original Message-----
From: David LaFrance-Linden [mailto:[log in to unmask]]
Sent: Friday, 27 February 2004 3:21 AM
To: [log in to unmask]
Subject: Re: Stir it up again? (was: Retire FORTRAN?!)


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.


************************************************************************
The information in this e-mail together with any attachments is
intended only for the person or entity to which it is addressed
and may contain confidential and/or privileged material.
Any form of review, disclosure, modification, distribution
and/or publication of this e-mail message is prohibited.  
If you have received this message in error, you are asked to
inform the sender as quickly as possible and delete this message
and any copies of this message from your computer and/or your
computer system network.  
************************************************************************