[log in to unmask] wrote:
>
...
> There is a good reason, however, why folks like Seeley bash Fortran:  We
> have procrastinated far too much in incorporating useful and well-tried
> programming paradigms from other languages, and inventing new ones.

On the other hand, that may also be the very reason that Fortran
still exists at all - while several "more progressive" languages have
come and gone.

But, the problem is not that Fortran adopts too few features.  The
recent past has generated massive numbers of them.  The problem
is that they have an increasingly "tacked-on" look to them.  The
features tend *not* to be well-tried, but original or novel in style
or syntax.  And, they don't integrate well.

Consider the plight of modules.  Fortran adopted a definition
of modules which failed to separate the declarations of exported
types, values, variables, and procedures from their implement-
ation.  This has taken years to correct, and the fix is a new form of
module whose most significant property is that it's vastly more
complicated than the nature of the problen it's designed to address.

Or pointers.  Pointers tend to be problematical in any language, but
Fortran's tend to be more so.  I understand that for years (and maybe
still) more than half of all problem reports to Fortran implementors
are related to pointers.

Or, consider the recurrent discussion caused by the rather trivial
mistake of making KIND specifiers be of INTEGER type.  I heard
that there was originally a reason to do so that didn't pan out, but
that when the reason disappeared, the decision was not reconsidered.

And the list goes on...

> [...]                           Dahl and Nygaard pioneered
> object-oriented programming with Simula in 1962 and 1967.  When did
> Fortran get support for object-oriented programming?  Last month.  The
> list goes on and on.

When was this demonstrated to be a forward step in the production of
reliable and efficient programs?  Well, not yet.  Objective evidence
is hard to find, and most indicates this to be a problematical feature
at best.  Adding it to Fortran mostly amounts to "me-too" as a design
criterion.

...
> Participating means that you actually need to come to the meetings.  It's
> essentially impossible to contribute effectively otherwise.  It took me
> nearly thirty years to convince by management of this.  You really ought
> to get started on it.

This has never made much sense to me, even in the old pre-email,
pre-usenet, pre-web days.  It makes even less sense now.  In fact, it's
not at all clear why meetings are of any relevance except for inertia on
the part of the bureaucrats in the standard organizations.  I think that
new features need to be discussed in as public a forum as possible - and
should be *very* thoroughly discussed before any official proposal to
the committee is made, much lesss "set in stone".

You mention that "only" two of the present proposals for the next
revision (tentatively call F2008?) are of moderate complexity, yet
how many outside the committee even know what they are, much less
have had a chance to comment *before* they are too far along to be
changed?  Daylight is needed much more than meetings.  This forum,
the usenet newsgroup, and (if the participation restrictions can be
loosened) the j3 mailing list seem appropriate (or maybe the committee
should set up an additional forum specifically for this purpose).  Discussions
on all major feature proposals should occur in all three places *before*
any of those features are even written up for the committee's consideration.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare