Drew McCormack <[log in to unmask]> wrote:

> .... 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,

In my view, C++ is a diabolical language because Bjarne Stroustrup
thought he could design a language by himself.  Designing any other than
toy languages is diabolically difficult.  I used to disparage committees
with cliches such as "A camel is a horse designed by a committee," but
having seen the value of review by many people with different viewpoints,
I am convinced that a modern computer language design should not be
undertaken by an individual except with great humility and the
expectation that many mistakes will need correction in later revisions.
Even Niklaus Wirth needed five attempts after he concluded Algol 68 was
going in the wrong direction (Algol W, Pascal, Modula-1 and -2 and
Oberon).  He didn't have the hubrus to undertake the design of a language
with comprehensive scope on his own.  Ichbiah didn't design Ada on his
own; the extension from Ada-83 to Ada 95 was done by a committee of seven
working full time for a year.

> 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.

This is just plain wrong.  Look at the evolution of Fortran from 1956 to
1966 to 1977 to 1990 to 1995 to 2003.  Far from "not happening," Fortran
is the ONLY language in the scientific programming arena that did what is
asked!

We have a six-million-line suite of Fortran programs for spacecraft
navigation, with lineage going back to 1959.  The cost to re-write them
in a "modern" language that is incompatible with Fortran is prohibitive.
A new language that supplants Fortran will have to be upwardly
compatible.  Hmmm, I think it's called "Fortran 2003."  BTW, I do have
one data point concerning the cost to convert this code.  In 1996, one of
JPL's middle managers got a wasp up his ass and decided that maintenance
of the nav code was too expensive (6.5 work years per year).  So he
decided that it ought to be rewritten in C++.  The estimate was 120 work
years.  If the result were to reduce maintenance cost to zero, the
project would break even in 2023.  Now after 126 work years of effort
have been expended, the estimate for completion is (get this) 120 more
work years.  Leslie Hatton has actually measured (gasp!) lifetime
ownership costs for many substantial programs in several languages.  He
finds the total lifetime cost of C++ programs to be roughly six times the
cost of equivalent programs in C, Fortran 77 or Ada, which he finds to be
roughly the same.  Stephen F. Zeigler finds the cost of his Ada programs
to be roughly half the cost of his equivalent C programs.

> 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)

Ummm, Fortran 2003 covers the first and third of these, and has OO
features wished for in the second.  Whether the processor does or does
not do garbage collection is orthogonal to the language design -- unless
you botch the design.  Generic programming is on the list of features
desired for the next revision after Fortran 2003.  H. L. Mencken wrote
(approximately) "For every complex problem there is a solution that is
clear, simple and wrong."  You're dreaming if you think you're going to
get a "Simple" language with the scope necessary for serious work.

Aleks Donev wrote:

! Any competition would need a long time to catch up.

and Drew replied:

> Not at all. None of that would be lost. Any new language could simply
> be built on top of the current fortran backend.

It's not that simple.  If you naively include pointers with C semantics,
there are lots of things the front end simply cannot tell the back end.
The semantics of C pointers are the primary reason that C optimizers
cannot do as good a job as Fortran optimizers, notwithstand that they've
had far more effort poured into them by an enormously larger number of
clever people than Fortran.  Pointer optimization in C, and therefore
also register optimization, are NP hard.  The best one can hope for are
clever heuristics.  These actually do fairly well, but still not as well
as Fortran.  The lesson is that you have to be careful with the design.
An entirely new language risks having subtle traps in it that sabotage
the possibility to use all of the optimization techniques learned through
the ages.

> I think this is exactly the problem with attempting to persist with an
> existing language, rather than introducing a more modern competitor. In
> theory fortran could probably fulfill all of our needs, but it is
> constrained by legacy. As long as the legacy elements have to be
> supported, the language is susceptible to abuse.

The problem with introducing a modern competitor is legacy code.  One
needs the legacy elements to remain in the language, or one needs a sugar
daddy with a ton of money to pay for the conversion.  *REAL* programs
aren't thrown away every year so that a new crop of students can write
new ones in the latest fad language.  *REAL* programs embody tremendous
amounts of lore that aren't written down in the design documents, and
that are frequently expressed in subtle ways.  I have a wonderful proof
of this theorem but the margin is too small to contain it.

I don't use dangerous features in my new code, so whether they're
"subject to abuse" is irrelevant.  It takes time and effort to replace
their use in old codes (where there were no alternatives at the time they
were developed) with newer safer features.  It would take far more time
and effort to rewrite the old codes entirely, certify them, wring out all
the bugs, revise the computational strategies to cope with idiosyncracies
of the semantics of the new language that force different optimization
strategies onto the processor, ....

--
Van Snyder                    |  What fraction of Americans believe
[log in to unmask]       |  Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or disapproved
by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.