Hi,

I was presenting in an IRAD project review yesterday. One of our
department heads (not mine thank God) asked what language some of the
code was written in. The presenter said Fortran at which the
department head winced and commented that Fortran is no longer being
taught and that we should be using a "modern" language or we will have
trouble supporting the code.

I tried to point out to her that a large segment of the sciecne and
achedemic community uses Fortran and that for the process of number
crunching it is more efficient and suited than C or C++.

I need some statictics to shove in her face so as to put this issue to
rest for our project once and forever.

Suggestions?

Sincerely,

Jim Klein
Optical Designer and Optical Software Writer (Fortran+Winteracter on
PC and LINUX).

"Jim Klein" <jameseklein@earthlink.net> wrote in message
news:1p2lpv0i2q4deufft15i2chr99at4dobca@4ax.com...
> Hi,
>
> I was presenting in an IRAD project review yesterday. One of our
> department heads (not mine thank God) asked what language some of
the
> code was written in. The presenter said Fortran at which the
> department head winced and commented that Fortran is no longer being
> taught and that we should be using a "modern" language or we will
have
> trouble supporting the code.
>
> I tried to point out to her that a large segment of the sciecne and
> achedemic community uses Fortran and that for the process of number
> crunching it is more efficient and suited than C or C++.
>
> I need some statictics to shove in her face so as to put this issue
to
> rest for our project once and forever.
>
> Suggestions?
>

Here's some background that the department head might have up her
sleeve:

http://archive.adaic.com/docs/reports/lawlis/n.htm
http://math.nist.gov/tnt/overview.html
http://www.codesourcery.com/pooma/pooma
http://www.boost.org/
http://www.oonumerics.org/blitz/
http://www.amath.washington.edu/~lf/software/CompCPP_F90SciOOP.html

In postmodern 2003 the mantra "that a large segment of the science
...." doesn't persuade any more

-- 
Ciao,
Gerry T.
______
"It is dangerous to be right in matters on which the established
authorities are wrong." --  Voltaire.
..

On Sat, 25 Oct 2003 14:45:52 GMT, Jim Klein
<jameseklein@earthlink.net> wrote:

[snip]
>I need some statictics to shove in her face so as to put this issue to
>rest for our project once and forever.
[snip]

What kind of statistics would help?  Numbers of people using Fortran
won't work, since we're outnumbered.  (McDonald's burger consumption
also outnumbers filet mignon consumption.)

Maybe a list of schools still teaching Fortran?

Is this woman a programmer, or just spouting something she heard?  
You may have lost your opportunity in the seconds after she made her
statement.  An incredulous stare, followed by something like "What
have you been smoking?" would have helped.

Ken Plotkin

> Hi,
>
> I was presenting in an IRAD project review yesterday. One of our
> department heads (not mine thank God) asked what language some of the
> code was written in. The presenter said Fortran at which the
> department head winced and commented that Fortran is no longer being
> taught and that we should be using a "modern" language or we will have
> trouble supporting the code.
>
> I tried to point out to her that a large segment of the sciecne and
> achedemic community uses Fortran and that for the process of number
> crunching it is more efficient and suited than C or C++.
>
> I need some statictics to shove in her face so as to put this issue to
> rest for our project once and forever.
>
> Suggestions?
>
> Sincerely,
>
> Jim Klein
> Optical Designer and Optical Software Writer (Fortran+Winteracter on
> PC and LINUX).

Every rocket motor that the United States has used to date to put hardware
and people into space was tested at the Arnold Engineering Development
Center (AEDC) here in middle Tennessee.  And (only) Fortran is still being
used to calculate performance data from those engines.

Most major jet engine manufacturers have tested both commercial and military
engines here, using Fortran to calculate that performance data.

However, I've been told that some of the math models for a new generation of
engines will be written in C.  We've not tested those engines yet.

-- 
Jim Patterson
email: last 5 char. of GM sportscar
underscore
1st 3 char. of fanatic@
charter dot net

"Jim Klein" <jameseklein@earthlink.net> wrote in message
news:1p2lpv0i2q4deufft15i2chr99at4dobca@4ax.com...

Jim Patterson wrote:
....
> However, I've been told that some of the math models for a new
> generation of engines will be written in C.  We've not tested those
> engines yet.

So, are those new engines going to be about twice or three times
as big as the Fortran tested engines of the same performance?  With
more bugs and downright failures as well?

If things in other technical fields worked as well as C and its
descendents do in software, the world would indeed be a much
more dangerous and less efficient place.

-- 
J. Giles

Ken Plotkin <kplotkin@nospam-cox.net> wrote:

>On Sat, 25 Oct 2003 14:45:52 GMT, Jim Klein
><jameseklein@earthlink.net> wrote:
>
>[snip]
>>I need some statictics to shove in her face so as to put this issue to
>>rest for our project once and forever.
>[snip]
>
>What kind of statistics would help?  Numbers of people using Fortran
>won't work, since we're outnumbered.  (McDonald's burger consumption
>also outnumbers filet mignon consumption.)
>
>Maybe a list of schools still teaching Fortran?
That would be a start
>
>Is this woman a programmer, or just spouting something she heard?  
Something she heard. I'm afraid she said it to be saying something
that sounded managerial.

>You may have lost your opportunity in the seconds after she made her
>statement.  An incredulous stare, followed by something like "What
>have you been smoking?" would have helped.
I probably gave her "the" stare. 

Jim
>
>Ken Plotkin

"Jim Patterson" <BR-549@mayberry> wrote:

>> Hi,
>>
>> I was presenting in an IRAD project review yesterday. One of our
>> department heads (not mine thank God) asked what language some of the
>> code was written in. The presenter said Fortran at which the
>> department head winced and commented that Fortran is no longer being
>> taught and that we should be using a "modern" language or we will have
>> trouble supporting the code.
>>
>> I tried to point out to her that a large segment of the sciecne and
>> achedemic community uses Fortran and that for the process of number
>> crunching it is more efficient and suited than C or C++.
>>
>> I need some statictics to shove in her face so as to put this issue to
>> rest for our project once and forever.
>>
>> Suggestions?
>>
>> Sincerely,
>>
>> Jim Klein
>> Optical Designer and Optical Software Writer (Fortran+Winteracter on
>> PC and LINUX).
>
>Every rocket motor that the United States has used to date to put hardware
>and people into space was tested at the Arnold Engineering Development
>Center (AEDC) here in middle Tennessee.  And (only) Fortran is still being
>used to calculate performance data from those engines.
>
>Most major jet engine manufacturers have tested both commercial and military
>engines here, using Fortran to calculate that performance data.
>
>However, I've been told that some of the math models for a new generation of
>engines will be written in C.  We've not tested those engines yet.

That is the kind of data I can use. Thanks,

Jim

"James Giles" <jamesgiles@worldnet.att.net> wrote:

>Jim Patterson wrote:
>...
>> However, I've been told that some of the math models for a new
>> generation of engines will be written in C.  We've not tested those
>> engines yet.
>
>So, are those new engines going to be about twice or three times
>as big as the Fortran tested engines of the same performance?  With
>more bugs and downright failures as well?
>
>If things in other technical fields worked as well as C and its
>descendents do in software, the world would indeed be a much
>more dangerous and less efficient place.

Oh, you mean like Windows ME. 

Hi:

I can't offer you statistics, but you might want to download a demo from:

http://www.geometrics-unlimited.com

A commercial code written entirely in Fortran with Winteracter.

Provides a good mixture of scientific number crunching (Fortran) and GUI
(Winteracter).

Several hundred copies have been sold with zero complaints.

Not to say that it couldn't have been done with C, but does prove that it
can be done with Fortran.

Mike

Jim Klein wrote:

> Hi,
>
> I was presenting in an IRAD project review yesterday. One of our
> department heads (not mine thank God) asked what language some of the
> code was written in. The presenter said Fortran at which the
> department head winced and commented that Fortran is no longer being
> taught and that we should be using a "modern" language or we will have
> trouble supporting the code.
>
> I tried to point out to her that a large segment of the sciecne and
> achedemic community uses Fortran and that for the process of number
> crunching it is more efficient and suited than C or C++.
>
> I need some statictics to shove in her face so as to put this issue to
> rest for our project once and forever.
>
> Suggestions?
>
> Sincerely,
>
> Jim Klein
> Optical Designer and Optical Software Writer (Fortran+Winteracter on
> PC and LINUX).

Jim Klein wrote:
> 
> Hi,
> 
> I was presenting in an IRAD project review yesterday. One of our
> department heads (not mine thank God) asked what language some of the
> code was written in. The presenter said Fortran at which the
> department head winced and commented that Fortran is no longer being
> taught and that we should be using a "modern" language or we will have
> trouble supporting the code.
> 
> I tried to point out to her that a large segment of the sciecne and
> achedemic community uses Fortran and that for the process of number
> crunching it is more efficient and suited than C or C++.
> 
> I need some statictics to shove in her face so as to put this issue to
> rest for our project once and forever.
> 
> Suggestions?
> 
> Sincerely,
> 
> Jim Klein
> Optical Designer and Optical Software Writer (Fortran+Winteracter on
> PC and LINUX).

Just a few remarks:
- The latest standard for C, C99, that I know of, is desperately trying
  to get the wrinkles out of C with regards to numerical calculations.
- Apocriphically, arguments for these efforts seem to have been to 
  be able to compete with Fortran!
- To quote or paraphrase Gauss, IIRC, we need notions, not notations:
  New and fancy languages may help in places, but unless you have the
  right notions, nothing will come of it.
  (IIRC, he said something like that in response to a fellow
mathematician
  who claimed it was very tough to prove some theorem on prime numbers,
  because there was no notation for them. Gauss of course proved this
  on the back of an envelope. I think it was Fermat's little theorem).

I could recite what we, our competitors and our customers do with 
Fortran, but I will refrain instead.

Regards,

Arjen

In article <1p2lpv0i2q4deufft15i2chr99at4dobca@4ax.com>, Jim Klein 
<jameseklein@earthlink.net> writes
>Hi,
>
>I was presenting in an IRAD project review yesterday. One of our
>department heads (not mine thank God) asked what language some of the
>code was written in. The presenter said Fortran at which the
>department head winced and commented that Fortran is no longer being
>taught and that we should be using a "modern" language or we will have
>trouble supporting the code.
>
>I tried to point out to her that a large segment of the sciecne and
>achedemic community uses Fortran and that for the process of number
>crunching it is more efficient and suited than C or C++.
>
>I need some statictics to shove in her face so as to put this issue to
>rest for our project once and forever.
>
>Suggestions?
>
>Sincerely,
>
>Jim Klein
>Optical Designer and Optical Software Writer (Fortran+Winteracter on
>PC and LINUX).

Can you get hold of a nice official looking recent document from the 
standards committee with Fortran 2000 in the title, or even better 
whatever the one after Fortran 2000's going to be called?

And agree with her that of course you wouldn't use any outdated, 
no-longer-standard language for her project, be it F77, C or C++. You 
don't have to tell her how much of your code looks just like F77 anyway 
:-)

It's no good telling such people that Fortran is better suited to number 
crunching. They always interpret it as "I don't understand C++ and can't 
be bothered to learn it".

Catherine.
-- 
Catherine Rees Lay
To email me, use my first name in front of the "at".

While it was 25/10/03 3:45 pm throughout the UK, Jim Klein sprinkled
little black dots on a white screen, and they fell thus:

> Hi,
> 
> I was presenting in an IRAD project review yesterday. One of our
> department heads (not mine thank God) asked what language some of the
> code was written in. The presenter said Fortran at which the
> department head winced and commented that Fortran is no longer being
> taught 

By whom?  Where?

> and that we should be using a "modern" language or we will have
> trouble supporting the code.

Is this "modern" in the strict chronological sense, in terms of the 
programming principles on which it is based or what?

Fortran 90 satisfies the former quite well in comparison to many 
languages.  Even more so does Fortran 95 IINM.

> I tried to point out to her that a large segment of the sciecne and
> achedemic community uses Fortran and that for the process of number
> crunching it is more efficient and suited than C or C++.
<snip>

My department uses a mixture of F77 and F90, but I think you have to be 
a postgrad to get involved with it....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on
on the 'group where everyone may benefit.

"Catherine Rees Lay" <spamtrap@polyhedron.org.uk> wrote in message
news:l94xUroWmln$EwqH@spamtram.polyhedron.com...

[...]

> It's no good telling such people that Fortran is better suited to
number
> crunching. They always interpret it as "I don't understand C++ and
can't
> be bothered to learn it".
>

Hear. Hear.

-- 
Ciao,
Gerry T.
______
"A proof is a proof. What kind of a proof ? It's a proof. A proof is a
proof. And when you have a good proof, it's because it's proven." -- 
Jean Chr�tien, Prime Minister of Canada.

Hello,

On Tue, 28 Oct 2003 11:57:10 +0000, Catherine Rees Lay
<spamtrap@polyhedron.org.uk> wrote:

<snip requoted>
>
>Can you get hold of a nice official looking recent document from the=20
>standards committee with Fortran 2000 in the title, or even better=20
>whatever the one after Fortran 2000's going to be called?

As per WG5, its official informal (how's that?) name is Fortran 2003.

<snip>
>
>Catherine.

--=20
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Catherine Rees Lay <spamtrap@polyhedron.org.uk> wrote:
> 
> It's no good telling such people that Fortran is better suited to number 
> crunching. They always interpret it as "I don't understand C++ and can't 
> be bothered to learn it".

argh. 

Maybe the statement could be that C++ has antiquated non-support for
arrays, and non-support for safe implementation facilities like
comprehensive bounds checking.  The Language Formerly Known as
Fortran, does, as does Java, but with higher level semantics for
multi-dimensional arrays as opposed to Java.

I would also emphasize the safety of TLFKAF.  Also emphasize the
comparatively constrained nature of general pointers and the
distinction between heap storage by arbitrary references, and
ALLOCATABLE.   Drop "buffer overruns". 

Emphasize how the TLFKAF formerly known as Fortran is better suited to 
safe software practices, and still offers higher performance.

Maybe give examples of specific C++ inadequacies to show that it is
not a non-understanding of C++ and unwillingness to learn, but an
actual understanding of C++.

Dan Nagle <dnagle@erols.com> writes:

> On Tue, 28 Oct 2003 11:57:10 +0000, Catherine Rees Lay
> <spamtrap@polyhedron.org.uk> wrote:

> >Can you get hold of a nice official looking recent document from the 
> >standards committee with Fortran 2000 in the title, or even better 
> >whatever the one after Fortran 2000's going to be called?
> 
> As per WG5, its official informal (how's that?) name is Fortran 2003.

Except that Fortran 2003 is the revised name of the *SAME* one that
was previously being called Fortran 2000.  It isn't the next one after
Fortran 2000.  Probably that's what you meant (I know for sure that
you know of it), but the way it was worded above, I bet a lot of
people would incorrectly read it as saying that the next standard
after Fortran 2000 was going to be Fortran 2003.  That will just
cause confusion (exactly the kind of confusion that is part of why
I was against changing the name to Fortran 2003.)

Just to clarify for others, the next revision after "the revision
formerly known as Fortran 2000" is still in the early planning
stages.  There has been no action, even at an informal level,
on setting up either schedule or content (or name).  Several
people have personal ideas on what it should be like.  Not a
single proposal has yet been voted on at any level.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

G.F. Thomas wrote:

> "Catherine Rees Lay" <spamtrap@polyhedron.org.uk> wrote in message
> news:l94xUroWmln$EwqH@spamtram.polyhedron.com...
> 
> [...]
> 
>>It's no good telling such people that Fortran is better suited to
>>number crunching. They always interpret it as "I don't understand C++ and
>>can't be bothered to learn it".

> Hear. Hear.

Indeed, it's far better to hand them the Josuttis' book and tell them to 
find the multi-rank array examples for you.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

Jim Klein wrote:
> 
> I need some statictics to shove in her face so as to put this issue to
> rest for our project once and forever.

Here are the stats that might do the trick. You may want to add that
according to Nielson Web ratings it's one of the busiest sites on the
planet. So far this year, it averages ~150k visitors per day.

	http://netlib.org/utk/misc/counts.html

Dr Chaos wrote:
> 

> 
> Emphasize how the TLFKAF formerly known as Fortran is better suited to
> safe software practices, and still offers higher performance.
> 
> Maybe give examples of specific C++ inadequacies to show that it is
> not a non-understanding of C++ and unwillingness to learn, but an
> actual understanding of C++.

Two publications to support this, in my view:
- A recent overview in ACM Sigplan of difficulties with C++ as the
language for 
  computer science courses (I mused over that a few weeks ago in this
  forum)
- An article in Doctor Dobbs' Journal (november 2003) comparing the
conformance
  of compilers to the ever-evolving C++ standard.

I will not say C++ is a bad programming language (at least not in public
:), but it is
certainly at the top of my list of difficult languages and these two
articles 
support my views.

I have seen lamentations over the Fortran standard being complex and
strewn with
exceptions to the rules, but some aspects of C++ really take the
biscuit.

Regards,

Arjen

Hi All,

Thanks for the replies. I shall use the replies appropriately.

Jim Klein




"G.F. Thomas" <gfthomas@sympatico.ca> wrote:

>
>"Jim Klein" <jameseklein@earthlink.net> wrote in message
>news:1p2lpv0i2q4deufft15i2chr99at4dobca@4ax.com...
>> Hi,
>>
>> I was presenting in an IRAD project review yesterday. One of our
>> department heads (not mine thank God) asked what language some of
>the
>> code was written in. The presenter said Fortran at which the
>> department head winced and commented that Fortran is no longer being
>> taught and that we should be using a "modern" language or we will
>have
>> trouble supporting the code.
>>
>> I tried to point out to her that a large segment of the sciecne and
>> achedemic community uses Fortran and that for the process of number
>> crunching it is more efficient and suited than C or C++.
>>
>> I need some statictics to shove in her face so as to put this issue
>to
>> rest for our project once and forever.
>>
>> Suggestions?
>>
>
>Here's some background that the department head might have up her
>sleeve:
>
>http://archive.adaic.com/docs/reports/lawlis/n.htm
>http://math.nist.gov/tnt/overview.html
>http://www.codesourcery.com/pooma/pooma
>http://www.boost.org/
>http://www.oonumerics.org/blitz/
>http://www.amath.washington.edu/~lf/software/CompCPP_F90SciOOP.html
>
>In postmodern 2003 the mantra "that a large segment of the science
>..." doesn't persuade any more

> I was presenting in an IRAD project review yesterday. One of our
> department heads (not mine thank God) asked what language some of the
> code was written in. The presenter said Fortran at which the
> department head winced and commented that Fortran is no longer being
> taught and that we should be using a "modern" language or we will have
> trouble supporting the code.

The next standard for Fortran is nearing publication, which is expected
next year.  Is 2004 modern enough?  For a summary of the new features, see
ftp://ftp.nag.co.uk/sc22wg5/N1551-N1600/N1579.pdf

> I tried to point out to her that a large segment of the sciecne and
> achedemic community uses Fortran and that for the process of number
> crunching it is more efficient and suited than C or C++.

> I need some statictics to shove in her face so as to put this issue to
> rest for our project once and forever.

> Suggestions?

The simplest answer is to use the correct tool for each job.  Even though
this isn't crossposted to alt.woodworking, an analogy might help:  You can,
with a struggle, use a claw hammer for a plane, and with no struggle use a
plane for a hammer, but neither is well suited to the job it wasn't designed
for.  If you want some war stories....

The spacecraft orbit determination program suite at JPL has been under
continuous development in Fortran (Fortran, Fortran II, Fortran IV, Fortran
66, Fortran 77, Fortran 90, Fortran 95) since 1957 or so.  It's about six
million lines now.  Maintenance costs are about six work years per year.

In 1996, an enlightened manager decided that the maintenance costs could
be reduced if the whole thing were re-written in C++.  The estimate to
finish the project was 120 work years.  If rewriting it could reduce the
maintenance cost to zero work years per year, the project would have broken
even in 2023 -- assuming the new program still gets the right answers.  So
far, 140+ work years have been expended, and the estimated cost to complete
the project is still 120 work years.  One guy was given the job of re-writing
the integrator for the initial-value problem for ordinary differential
equations.  These 2200 or so lines of Fortran 77 tackle the central problem
of orbit determination:  Solving Newton's equations of motion.  This package
is not a simple RKF45 integrator from Numerical Recipes.  It's a variable-
order variable-step Adams-Moulton integrator that solves second-order
equations directly.  The sophisitication is well justified, but that's a
story for another day.  After two years, he hadn't even finished the
interface!  This guy is not a lazy idiot, or completely unfamiliar with
C++.  He had previously completed several other projects in C++ successfully.
The problem wasn't the engineer; the problem was that C++ is not the right
tool for this job.

Leslie Hatton has actually measured some statistics related to lifetime
costs for programs.  He finds that C++ programs have two to three times the
density of statically-detectable defects as equivalent programs written in
C, Fortran or Ada, and two to three times the cost-per-defect to repair.
Overall, he finds the cost of owning a C++ program is roughly six times
the cost of owning an equivalent program written in C, Fortran or Ada.
See "Does OO Sync with the way we think?" which appeared in IEEE TSE.
Also look for Hatton's "T experiments."  The results were presented at a
conference on software reliability in Oxford in 1996, but I think they also
appeared in an IEEE journal.

At http://sunnyday.mit.edu/16.355/cada_art.html there is an article by
Stephen Ziegler in which he analyzes the detailed work logs and diaries
kept by programmers at Rational and Verdix.  Both companies had similar
products, but Rational's were written in Ada and Verdix's were written in
C; the companies eventually merged, after which Ziegler did his analysis.
He concludes that a program written in C costs roughly twice as much to
own as one written in Ada.  He didn't have Fortran programs to analyze.

-- 
Van Snyder                    |  What fraction of Americans believe 
Van.Snyder@jpl.nasa.gov       |  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.

Picked up from a Fortan distribution list:


I want to share this, because I think all who helped create
Fortran 90 & 95 should be pleased and proud when things
like this happen.

It looks like I failed to teach how to write "Fortran",
however :-(.

=================================================================

Hi Walt.

I'm sending along this email for 2 reasons.  First, to tell you once
again how much I enjoyed the advanced FORTRAN course you presented for
us in Chalk River.  Since then, I've taken what is probably an
unprecedented step in safety analysis legacy codes.  I've made an
addition to a 30-year old code using the O-O capabilities in
FORTRAN-95.  Using a module, with private data members and access
routines is almost unheard of in our environment, but it seems to be
working flawlessly with all the advantages inherent in the FORTRAN language.

<technical question snipped>

-- 
Walt Brainerd         +1-877-355-6640 (voice & fax)
The Fortran Company   +1-520-760-1397 (outside USA)
6025 N. Wilmot Road   walt@fortran.com
Tucson, AZ 85750 USA  http://www.fortran.com

"Michael Metcalf" <metcalfm@acm.org> wrote in message
news:bo2mej$sqo$02$1@news.t-online.com...

> It looks like I failed to teach how to write "Fortran",
> however :-(.

Someone needs to let Microsoft know as well - its Office spellcheckers
insist that FORTRAN is the correct capitalization, and several times I've
had to correct coworkers who changed my (correct) spelling to Microsoft's
incorrect one. I see this error persists some 12 years after the change in
the latest Office 2003.

Steve

In article <bnuc87$f85$1@nntp1.jpl.nasa.gov>,
 vsnyder@math.jpl.nasa.gov (Van Snyder) writes:

>Leslie Hatton has actually measured some statistics related to lifetime
>costs for programs.  He finds that C++ programs have two to three times the
>density of statically-detectable defects as equivalent programs written in
>C, Fortran or Ada, and two to three times the cost-per-defect to repair.
>Overall, he finds the cost of owning a C++ program is roughly six times
>the cost of owning an equivalent program written in C, Fortran or Ada.
>See "Does OO Sync with the way we think?" which appeared in IEEE TSE.
>Also look for Hatton's "T experiments."  The results were presented at a
>conference on software reliability in Oxford in 1996, but I think they also
>appeared in an IEEE journal.

Arnaud de Desitter has referred my attention to http://www.leshatton.org

"Van Snyder" <vsnyder@math.jpl.nasa.gov> wrote in message
news:bnuc87$f85$1@nntp1.jpl.nasa.gov...

[...]

> One guy was given the job of re-writing
> the integrator for the initial-value problem for ordinary differential
> equations.  These 2200 or so lines of Fortran 77 tackle the central
problem
> of orbit determination:  Solving Newton's equations of motion.  This
package
> is not a simple RKF45 integrator from Numerical Recipes.

I should hope not!

> It's a variable-
> order variable-step Adams-Moulton integrator that solves second-order
> equations directly.  The sophisitication is well justified, but that's
a
> story for another day.  After two years, he hadn't even finished the
> interface!  This guy is not a lazy idiot, or completely unfamiliar
with
> C++.  He had previously completed several other projects in C++
successfully.
> The problem wasn't the engineer; the problem was that C++ is not the
right
> tool for this job.
>

Out of curiosity, was Hindmarsh's VODE in C from netlib considered?

-- 
Ciao,
Gerry T.
______
"I read the news today, oh boy..." -- John Lennon

In article <bo69is$r3i$1@nntp1.jpl.nasa.gov>,
vsnyder@math.jpl.nasa.gov (Van Snyder) wrote:

>Subject: Re: Help from fellow Fortran Users
>From: vsnyder@math.jpl.nasa.gov (Van Snyder)
>Organization: Jet Propulsion Laboratory - Pasadena CA
>Date: 3 Nov 2003 19:16:44 GMT
>Newsgroups: comp.lang.fortran
>
>In article <bnuc87$f85$1@nntp1.jpl.nasa.gov>,
> vsnyder@math.jpl.nasa.gov (Van Snyder) writes:
>
>>Leslie Hatton has actually measured some statistics related to lifetime
>>costs for programs.  He finds that C++ programs have two to three times the
>>density of statically-detectable defects as equivalent programs written in
>>C, Fortran or Ada, and two to three times the cost-per-defect to repair.
>>Overall, he finds the cost of owning a C++ program is roughly six times
>>the cost of owning an equivalent program written in C, Fortran or Ada.
>>See "Does OO Sync with the way we think?" which appeared in IEEE TSE.
>>Also look for Hatton's "T experiments."  The results were presented at a
>>conference on software reliability in Oxford in 1996, but I think they also
>>appeared in an IEEE journal.
>
>Arnaud de Desitter has referred my attention to http://www.leshatton.org

The 1994 article in IEEE Transactions on Software Engineering on errors
in real production (siesmic) codes is a VERY GOOD PAPER. I have suggested
it to several other folks whenever the topic of errors in programs has come
up.

Thanks for the other citations.

Van Snyder wrote:
> 
> In article <bnuc87$f85$1@nntp1.jpl.nasa.gov>,
>  vsnyder@math.jpl.nasa.gov (Van Snyder) writes:
> 
> >Leslie Hatton has actually measured some statistics related to lifetime
> >costs for programs.  He finds that C++ programs have two to three times the
> >density of statically-detectable defects as equivalent programs written in
> >C, Fortran or Ada, and two to three times the cost-per-defect to repair.
> >Overall, he finds the cost of owning a C++ program is roughly six times
> >the cost of owning an equivalent program written in C, Fortran or Ada.
> >See "Does OO Sync with the way we think?" which appeared in IEEE TSE.
> >Also look for Hatton's "T experiments."  The results were presented at a
> >conference on software reliability in Oxford in 1996, but I think they also
> >appeared in an IEEE journal.
> 
> Arnaud de Desitter has referred my attention to http://www.leshatton.org

That is a very nice link. Thank you!

Regards,

Arjen

Gordon Sande wrote:
> The 1994 article in IEEE Transactions on Software Engineering on errors
> in real production (siesmic) codes is a VERY GOOD PAPER. I have suggested
> it to several other folks whenever the topic of errors in programs has come
> up.
  It seems that paper you mentioned is unavailable for download, so how 
did you get it?

B52B

In article <bo83am$qmv$1@srv.cyf-kr.edu.pl>,
"B52B@pl" <B52B@pl.pl.pl> wrote:

>Subject: Re: Help from fellow Fortran Users
>From: "B52B@pl" <B52B@pl.pl.pl>
>Reply-To: <BBCC46FB96681E2BB5@24.222.34.2>
>Organization: Academic Computer Center CYFRONET AGH
>Date: Tue, 04 Nov 2003 12:38:41 +0100
>Newsgroups: comp.lang.fortran
>
>Gordon Sande wrote:
>> The 1994 article in IEEE Transactions on Software Engineering on errors
>> in real production (siesmic) codes is a VERY GOOD PAPER. I have suggested
>> it to several other folks whenever the topic of errors in programs has come
>> up.
>  It seems that paper you mentioned is unavailable for download, so how 
>did you get it?

I first saw it in IEEE TSE in 1994 when it was published. I have
recommended the article several time since then. It would not make 
much sense to have recommended it several times in the past if I
had just seen the article.

>B52B
>

B52B@pl wrote:
> Gordon Sande wrote:
> 
>> The 1994 article in IEEE Transactions on Software Engineering on errors
>> in real production (siesmic) codes is a VERY GOOD PAPER. I have suggested
>> it to several other folks whenever the topic of errors in programs has 
>> come
>> up.
> 
>  It seems that paper you mentioned is unavailable for download, so how 
> did you get it?

The article's title is "How Accurate is Scientific Software?" (October,
1994), and it can be downloaded for US$19.00.  Quoting from the abstract 
(http://csdl.computer.org/comp/trans/ts/1994/10/e0785abs.htm):

"The results are deeply disturbing."

Louis Krupp

"Jim Klein"  wrote
> The presenter said Fortran at which the
> department head winced and commented that Fortran is no longer being
> taught and that we should be using a "modern" language or we will have
> trouble supporting the code.

Am I wrong in thinking that "portability" in the C world, and even more so
in the C++ world, means only that the code can be ported with less trouble
than to rewrite it?  Whereas I routinely use fortran written 20 or 30 years
ago that compiles and runs on my current box with no changes whatever.  And
you can't beat a few decades of extensive use to squeeze out the bugs.

Hello,

On the spectrum of portability, I like to define
three regions:

Not Portable (assemblers, code with heavy use of system calls)

Weakly Portable (C/C++, portability obtained manually
and then enshrined via conditional compilation)

Strongly Portable (Ada, Fortran, source is portable
without editing, even automatic editing such as conditional
compilation)

I'll freely admit that the boundaries are somewhat arbitrary.

--=20
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

On Fri, 23 Jan 2004 10:53:25 -0600, "Charles Russell"
<STOPworworSPAM@bellsouth.net> wrote:

>
>"Jim Klein"  wrote
>> The presenter said Fortran at which the
>> department head winced and commented that Fortran is no longer being
>> taught and that we should be using a "modern" language or we will have
>> trouble supporting the code.
>
>Am I wrong in thinking that "portability" in the C world, and even more =
so
>in the C++ world, means only that the code can be ported with less =
trouble
>than to rewrite it?  Whereas I routinely use fortran written 20 or 30 =
years
>ago that compiles and runs on my current box with no changes whatever.  =
And
>you can't beat a few decades of extensive use to squeeze out the bugs.
>

test
"Charles Russell" <STOPworworSPAM@bellsouth.net> schreef in bericht
news:EicQb.3169$L04.1355@bignews4.bellsouth.net...
>
> "Jim Klein"  wrote
> > The presenter said Fortran at which the
> > department head winced and commented that Fortran is no longer being
> > taught and that we should be using a "modern" language or we will have
> > trouble supporting the code.
>
> Am I wrong in thinking that "portability" in the C world, and even more so
> in the C++ world, means only that the code can be ported with less trouble
> than to rewrite it?  Whereas I routinely use fortran written 20 or 30
years
> ago that compiles and runs on my current box with no changes whatever.
And
> you can't beat a few decades of extensive use to squeeze out the bugs.
>
>

Charles Russell wrote:

> "Jim Klein"  wrote
> > The presenter said Fortran at which the
> > department head winced and commented that Fortran is no longer being
> > taught and that we should be using a "modern" language or we will have
> > trouble supporting the code.
>
> Am I wrong in thinking that "portability" in the C world, and even more so
> in the C++ world, means only that the code can be ported with less trouble
> than to rewrite it?  Whereas I routinely use fortran written 20 or 30 years
> ago that compiles and runs on my current box with no changes whatever.  And
> you can't beat a few decades of extensive use to squeeze out the bugs.

Portability, for programs written in any language, depends on four
things:

  1. characteristics of the task,
  2. suitability of the programming language to the task,
  3. willingness of the programmer to follow the language standard, and
  4. willingness of the programmer to write portable code.

Compilers are good examples of tasks with characteristics that preclude
portability.  A compiler that generates code for an AXP platform is not
portable to a Pentium platform -- or, it might run on a Pentium platform
but won't produce code that will run on a Pentium.  Even a compiler that
generates code for a Pentium running Windows might run on a Linux
platform but won't produce output files usable by the Linux system.

Early versions of Fortran were good examples of programming languages
that weren't portable.  Among other things, Fortran 66 didn't have end
of file detection or read from/write to memory.  If the task at hand
required either of those, programmers were forced to use some sort of
workaround or the language extensions provided by their compiler
vendor.  This made it impossible to run programs written for one
vendor's platforms on the platforms of any other vendor.  At one place I
worked, we even managed to pervert the Fortran 66 calling sequence to
support pointers and pointer arithmetic -- definitely non-portable.

Pascal had such a sloppily-written standard with so few features that it
was impossible to write any kind of Pascal program that was both
portable and did something useful.

OTOH, C programs can be much more portable than Fortran programs written
according to standards earlier than Fortran 90.  C supports all sorts of
features not supported in early Fortran standards (character variables
not supported until Fortran 77, pointers, structures, etc.).  However,
many C programs are not portable because of dependence on a particular
architecture or operating system, e.g., compilers, database
implementations, etc., or due to other issues mentioned below.


Some programmers are just so impressed with their own knowledge of the
peculiarities of a particular language implementation that they insist
on using non-standard constructs even when they're not necessary to work
around inherent limitations of the language.  The most obvious Fortran
example of this is dependence on DO loops executing at least once, even
for non-standard-conforming DO statements.  Other non-portable
techniques include use of the *<byte length> suffix for types (though
that was sort of a de facto standard), knowledge of the internal
representation of characters, and the use of EQUIVALENCE and COMMON to
overlay different incompatible (according to the standard) variable
types onto the same storage locations.


Finally, even when a programer knows the standard well enough to write
standard-conforming source code AND is willing to do so, there's the
question of whether the programmer is willing to write portable code.
For simple problems, standard-conforming source is portable; that is,
it will compile without errors and will probably produce the same
results (though be careful of floating point operations, especially
comparisons).

But some programs require interaction with the surrounding system (names
of files & directories, KIND TYPE values, etc.).  In most cases, these
dependencies can be collected and isolated into a relatively few source
files so that only a small part of the program needs to be rewritten for
each different platform (include files really help with this).  But a
remarkable number of programmers seem to delight in spraying system
dependencies (e.g., page size, disk block size, character set knowledge,
etc.).


Over the years, I've had to write portable code and port other people's
code among several different systems and compilers.  The machines had
16-, 32-, 36-, and 60-bit words; 1's-complement and 2's-complement
arithmetic; character sets included ASCII, EBCDIC, CDC Display Code,
etc.; and I've lost track of all the compiler differences (e.g., "long"
is 32 bits for the AXP/VMS C compiler but 64 bits for the AXP/Tru64
Unix C compiler); etc.  I've discovered the biggest problems with code
portability are both language-independent:

  1. Programmers who aren't aware of the issues involved.  This group
     includes most programmers.  These can be programmers fresh out of
     college who've never used more than one vendor's platform or
     employees of one of the vendors (e.g., especially DEC, CDC, or
     IBM) who've never worked for anyone else and can't conceive of any
     other way to do anything.

  2. Programmers who just don't care about portability -- or, worse,
     seem actively opposed to it.  This group includes almost all
     programmers.  I don't know why, but even programmers who do
     understand some of the issues will just ignore them and become
     defensive -- or even belligerent -- when anyone, even their
     managers, asks them to follow portability conventions.  Maybe my
     experience is statistically skewed.  More likely, though, there
     are just a lot of arrogant programmers out there who think they're
     too good or too important to do maintenance or porting and who have
     no sympathy for us peons who get stuck with that work.

It's certainly possible to write portable code in C and, once over the
learning curve, even easier in C++.  Since the Fortran 77 standard, it
has even been possible to write portable code in Fortran.

If you're seeing a difference in portability between Fortran and C code,
there's a good chance that's the result of differences in age.  Old
Fortran programs that have been ported to several different platforms
for 20 or 30 years may have had all of the non-portable code removed or
made portable.  Wait until the C programs are 20 or 30 years old and
have been ported to and used on as many different platforms before
commenting on comparative portability.


Bob Lidral
l i d r a l  at  a l u m  dot  m i t  dot  e d u

Bob Lidral wrote:
....
> OTOH, C programs can be much more portable than Fortran programs written
> according to standards earlier than Fortran 90.  C supports all sorts of
> features not supported in early Fortran standards (character variables
> not supported until Fortran 77, [...]

C had no standard until after F77.  Before the C standard, C was
not even remotely close to portable.  C still has no character string
type.  It has a type for singlr characters, and it has pointers to
those which are often used to emulate strings (badly).

In the meantime, there's a *lot* of code in present use that dates from
the F77 era (and slightly before) that's still very portable indeed.  In
fact, continued access to that very software is often cited as the
reason for retaining Fortran in many programming environments.

> Some programmers are just so impressed with their own knowledge of the
> peculiarities of a particular language implementation that they insist
> on using non-standard constructs even when they're not necessary to work
> around inherent limitations of the language.  The most obvious Fortran
> example of this is dependence on DO loops executing at least once, even
> for non-standard-conforming DO statements.  [...]

People occasionally bring this up.  I first used Fortran in 1968 and
have used it extensively since.  I didn't know of this "one-trip loop"
issue until I found that some F77 implementations had an option to
turn that behavior on.  It never happened in any of my programs
or those I was familiar with (I had assumed that such loops were
illegal - oh, they were, even in F66).  Whether any of the implementations
I used had that semantics I can't tell - I never encountered it.

>  [...] Other non-portable
> techniques include use of the *<byte length> suffix for types (though
> that was sort of a de facto standard), knowledge of the internal
> representation of characters, and the use of EQUIVALENCE and COMMON to
> overlay different incompatible (according to the standard) variable
> types onto the same storage locations.

Similar problems are more rampant in C (even with standardization).
Casts (which are nominally against the standard) between incompatible
types are common.  Dependence on particular sizes of certain types
(short ints are *at*least* 16 bits, though many assume that they're
always *exactly* 16 bits).  Use of unions to overlay different incompatible
(according to the standard) variable types onto the same storage locations.
Assuming that hardware is byte addressed (a mistake that isn't even
possible in many Fortrans).  Assuming knowledge of the internal
representation of various types.

> If you're seeing a difference in portability between Fortran and C code,
> there's a good chance that's the result of differences in age.  Old
> Fortran programs that have been ported to several different platforms
> for 20 or 30 years may have had all of the non-portable code removed or
> made portable.  Wait until the C programs are 20 or 30 years old and
> have been ported to and used on as many different platforms before
> commenting on comparative portability.

I've seen C programs that are 20 or 30 years old.  They aren't portable.
Each port to a new platform tends not to remove the implementation
dependencies but to change to new dependencies on the new platform.
C is a fairly old language you know.  Sure, the really egregiously bad
design of the early days are gone - the first versions of C were had
ambiguous lexical syntax!  People still assume that short is 16 bits.

-- 
J. Giles

Bob Lidral wrote:
(snip including good explanations of portable and non-portable code)

> It's certainly possible to write portable code in C and, once over the
> learning curve, even easier in C++.  Since the Fortran 77 standard, it
> has even been possible to write portable code in Fortran.

> If you're seeing a difference in portability between Fortran and C code,
> there's a good chance that's the result of differences in age.  Old
> Fortran programs that have been ported to several different platforms
> for 20 or 30 years may have had all of the non-portable code removed or
> made portable.  Wait until the C programs are 20 or 30 years old and
> have been ported to and used on as many different platforms before
> commenting on comparative portability.

Well, there is also that C is more often used to do low-level
things that one wouldn't normally do in Fortran.  Some bit manipulation
functions depend on the byte size of word size of the machine.  One 
might, for example, write paging routines in C which depend on
characteristics of the paging hardware.  Code for running bit-mapped
graphics devices also tends to depend on byte size and word size.

One can write reasonably portable C code using sizeof() and CHAR_BIT
to determine bytes/word or bits/byte, but many people don't do that.

Relatively few Fortran programs depend on such, though for some
numerical algorithms it helps to know the machine precision
(epsilon).

-- glen

Charles Russell wrote:

> "Jim Klein"  wrote:
> 
>> The presenter said Fortran at which the department head winced
>> and commented that Fortran is no longer being taught
>> and that we should be using a "modern" language
>>  or we will have trouble supporting the code.
> 
> Am I wrong in thinking that "portability" in the C world,
> and even more so in the C++ world, means only that
> the code can be ported with less trouble than to rewrite it?

You are probably wrong in thinking that.

> Whereas I routinely use Fort ran written 20 or 30 years ago
> that compiles and runs on my current box with no changes whatever.
> And you can't beat a few decades of extensive use
> to squeeze out the bugs.

I think that Jack was merely referring to the fact that
it's increasingly more difficult to find Fortran programmers
to write, maintain and support [legacy] Fortran codes.

Fortran programmers are *not* generally interested in
writing or maintaining code for other people to use.
They are usually "amateur" programmers
who write Fortran programs for their own use
to help them do the work that they were hired and paid to do.

"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> writes:

> Fortran programmers are *not* generally interested in
> writing or maintaining code for other people to use.
> They are usually "amateur" programmers
> who write Fortran programs for their own use
> to help them do the work that they were hired and paid to do.

All generalizations are false.

And we won't go into statistics, even those limited ones
implied by words like "generally" and "usually".

:-)

P.S. I write code for other people to use.  But then, I am
rarely accused of being normal, and I tend to glare at
people who make such vulgar accusations.  :-)

-- 
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

Richard Maine wrote:

> E. Robert Tisdale writes:
> 
>>Fortran programmers are *not* generally interested in
>>writing or maintaining code for other people to use.
>>They are usually "amateur" programmers
>>who write Fortran programs for their own use
>>to help them do the work that they were hired and paid to do.
> 
> All generalizations are false.
> 
> And we won't go into statistics, even those limited ones
> implied by words like "generally" and "usually".
> 
> :-)
> 
> P.S. I write code for other people to use.  But then, I am
> rarely accused of being normal, and I tend to glare at
> people who make such vulgar accusations.  :-)

I *never* accused you of "being normal". :-)

"glen herrmannsfeldt" wrote

> Well, there is also that C is more often used to do low-level
> things that one wouldn't normally do in Fortran.

Language limitations that discourage programmers from playing low-level
tricks may  enhance portability simply by keeping non-numeric operations out
of the code.  Hard on programmers, good for scientists.

"E. Robert Tisdale" wrote

> Fortran programmers are *not* generally interested in
> writing or maintaining code for other people to use.
> They are usually "amateur" programmers
> who write Fortran programs for their own use
> to help them do the work that they were hired and paid to do.


Please persuade the standards committees and the compiler vendors that this
is the group they should cater to.

Charles Russell wrote:

> E. Robert Tisdale wrote:
> 
>>Fortran programmers are *not* generally interested in
>>writing or maintaining code for other people to use.
>>They are usually "amateur" programmers
>>who write Fortran programs for their own use
>>to help them do the work that they were hired and paid to do.
> 
> Please persuade the standards committees and the compiler vendors
> that this is the group they should cater to.

Let's have a show of hands.
Which of the contributors to this thread have an official job title of
"Fortran Programmer"?
"Software Engineer"?

That's what I thought. :-)

Dan Nagle <dnagle@erols.com> wrote in message news:<i9m2101e18uama5head0mfv8g21297uucs@4ax.com>...
> Hello,
> 
> On the spectrum of portability, I like to define
> three regions:
> 
> Not Portable (assemblers, code with heavy use of system calls)
> 
> Weakly Portable (C/C++, portability obtained manually
> and then enshrined via conditional compilation)
> 
> Strongly Portable (Ada, Fortran, source is portable
> without editing, even automatic editing such as conditional
> compilation)
> 
> I'll freely admit that the boundaries are somewhat arbitrary.
> 
> -- 
> Cheers!
> 
> Dan Nagle
> Purple Sage Computing Solutions, Inc.

Why would a C++ program to do a particular numerical computation be
less portable than an equivalent Fortran 95 program?

In article <GbmQb.106233$Rc4.755506@attbi_s54>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:

>One can write reasonably portable C code using sizeof() and CHAR_BIT
>to determine bytes/word or bits/byte, but many people don't do that.

Correct. Most free software uses "configure". Portability has changed
radically in the last decade, but the people posting about it on
Usenet don't seem to have noticed.

-- greg

"E. Robert Tidal" wrote:
> 
> Charles Russell wrote:
> 
> > E. Robert Tisdale wrote:
> >
> >>Fortran programmers are *not* generally interested in
> >>writing or maintaining code for other people to use.
> >>They are usually "amateur" programmers
> >>who write Fortran programs for their own use
> >>to help them do the work that they were hired and paid to do.
> >
> > Please persuade the standards committees and the compiler vendors
> > that this is the group they should cater to.
> 
> Let's have a show of hands.
> Which of the contributors to this thread have an official job title of
> "Fortran Programmer"?
> "Software Engineer"?
> 
> That's what I thought. :-)

Very few.  But if you go search a company like Boeing's job postings,
you will find a surprisingly large number of jobs that include Fortran
as either a requirement or a desired skill.  I searched my own Company's
site a month or so ago and found 52 such openings in just one division.


-- 

Gary Scott
mailto:garyscottNOSPAM@ev1.net

Fortran Library
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Hello,

On 23 Jan 2004 22:58:40 -0800, beliavsky@aol.com wrote:

>Dan Nagle <dnagle@erols.com> wrote in message =
news:<i9m2101e18uama5head0mfv8g21297uucs@4ax.com>...
>> Hello,
>>=20
>> On the spectrum of portability, I like to define
>> three regions:
>>=20
>> Not Portable (assemblers, code with heavy use of system calls)
>>=20
>> Weakly Portable (C/C++, portability obtained manually
>> and then enshrined via conditional compilation)
>>=20
>> Strongly Portable (Ada, Fortran, source is portable
>> without editing, even automatic editing such as conditional
>> compilation)
>>=20
>> I'll freely admit that the boundaries are somewhat arbitrary.
>>=20
>> --=20
>> Cheers!
>>=20
>> Dan Nagle
>> Purple Sage Computing Solutions, Inc.
>
>Why would a C++ program to do a particular numerical computation be
>less portable than an equivalent Fortran 95 program?

C++ Slogan: "With enough work, it's easy!"

Because the C++ program relies (typically) on conditional compilation
of typedef and/or macros to select types, where the Fortran
program relies on the standard kind mechanism.

Because the C++ program relies (typically) on conditional compilation
of kernels for high performance from each different compiler
where the Fortran program can get high performance just by being
written clearly.

Etc.

Conditional compilation means the programmer does the port.
While the results of the manual port are captured by conditional
compilation, the source code becomes more complex.  Each
different path through the conditional compilation must be
kept synchronized with all the others.  And then there's the issue
of new hardware, or a new compiler, or even a new release
of an existing compiler (perhaps with a new mode as the default).
You're right back to manual porting.

Borland has a Delphi for Linux (I haven't checked the status
of the project for a while).  It's supposed to be 80% or better
source compatible with Delphi for Windows.  Borland said
they will not even attempt to make C++ Builder for Linux-
it would never be sufficiently compatible with C++ Builder
for Windows to be worthwhile.

Knowing where the mines are is not the same as clearing
the minefield.

--=20
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

lindahl@pbm.com (Greg Lindahl) writes:

> In article <GbmQb.106233$Rc4.755506@attbi_s54>,
> glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>
>>One can write reasonably portable C code using sizeof() and CHAR_BIT
>>to determine bytes/word or bits/byte, but many people don't do that.
>
> Correct. Most free software uses "configure".

I once looked at using autoconf (which is what most often generates
those configure scripts) for my Fortran apps.  Discovered that I had very
few of the kinds of problems it seems best suited to addressing.
Yes, I could have used it to help customize my Makefiles, but the
overhead of learning it and applying it to my stuff didn't seem
worth the small benefit.  I stuck with my hand-written configuration
script.

(Still, I do quite appreciate the widespread use of autoconf.
Makes installing much of the open source software a lot simpler
than it once was.  If nothing else, it cuts down on the time spent
reading installation instructions becauise I see that the app is
done with autoconf and spend only a very short time skimming
for anything special.)

-- 
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

Richard Maine wrote:
(snip)

> I once looked at using autoconf (which is what most often generates
> those configure scripts) for my Fortran apps.  Discovered that I had very
> few of the kinds of problems it seems best suited to addressing.
> Yes, I could have used it to help customize my Makefiles, but the
> overhead of learning it and applying it to my stuff didn't seem
> worth the small benefit.  I stuck with my hand-written configuration
> script.

I think, though, it has more to do with the things people do in C
vs. Fortran than the language itself.

If one wants to work with eight bit bytes, one can use unsigned char
in C and hope it is implemented as bytes.  On a machine with a 60 bit
word that is not likely, though.  Then again doing anything with eight
bit bytes on a CDC 7600 is going to be hard.

One problem Fortran did have, and configure could probably help with,
is machines with a high precision REAL type, so that algorithms normally
done in DOUBLE PRECISION can be done in REAL.  This was the case with
CDC machines with 60 bit words, for example.

-- glen

On Saturday 25 October 2003 10:45, Jim Klein (jameseklein@earthlink.net) 
held forth in comp.lang.fortran
(<1p2lpv0i2q4deufft15i2chr99at4dobca@4ax.com>):

> Hi,
> 
> I was presenting in an IRAD project review yesterday. One of our
> department heads (not mine thank God) asked what language some of the
> code was written in. The presenter said Fortran at which the
> department head winced and commented that Fortran is no longer being
> taught and that we should be using a "modern" language or we will have
> trouble supporting the code.
> 
> I tried to point out to her that a large segment of the sciecne and
> achedemic community uses Fortran and that for the process of number
> crunching it is more efficient and suited than C or C++.
> 
> I need some statictics to shove in her face so as to put this issue to
> rest for our project once and forever.
> 
> Suggestions?
> 
> Sincerely,
> 
> Jim Klein
> Optical Designer and Optical Software Writer (Fortran+Winteracter on
> PC and LINUX).

I do not have stats but the comment from that person seems to be one from a
fellow who has used C for too long and hasn't heard of Fortran 90/95.

In article <YOzQb.114750$nt4.453109@attbi_s51>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> One problem Fortran did have, and configure could probably help with,
> is machines with a high precision REAL type, so that algorithms normally
> done in DOUBLE PRECISION can be done in REAL.

Perhaps, but this is exactly the problem selected_real_kind() 
solves, so there is no need for something like autoconf to solve 
this particular problem.

$.02 -Ron Shepard

Dan Nagle wrote:
> 
> Hello,
> 
> On 23 Jan 2004 22:58:40 -0800, beliavsky@aol.com wrote:
> 
> >Dan Nagle <dnagle@erols.com> wrote in message news:<i9m2101e18uama5head0mfv8g21297uucs@4ax.com>...
> >> Hello,
> >>
> >> On the spectrum of portability, I like to define
> >> three regions:
> >>
> >> Not Portable (assemblers, code with heavy use of system calls)
> >>
> >> Weakly Portable (C/C++, portability obtained manually
> >> and then enshrined via conditional compilation)
> >>
> >> Strongly Portable (Ada, Fortran, source is portable
> >> without editing, even automatic editing such as conditional
> >> compilation)
> >>
> >> I'll freely admit that the boundaries are somewhat arbitrary.
> >>
> >> --
> >> Cheers!
> >>
> >> Dan Nagle
> >> Purple Sage Computing Solutions, Inc.
> >
> >Why would a C++ program to do a particular numerical computation be
> >less portable than an equivalent Fortran 95 program?
> 
> C++ Slogan: "With enough work, it's easy!"
> 
> Because the C++ program relies (typically) on conditional compilation
> of typedef and/or macros to select types, where the Fortran
> program relies on the standard kind mechanism.
> 
> Because the C++ program relies (typically) on conditional compilation
> of kernels for high performance from each different compiler
> where the Fortran program can get high performance just by being
> written clearly.
> 
> Etc.
> 
> Conditional compilation means the programmer does the port.
> While the results of the manual port are captured by conditional
> compilation, the source code becomes more complex.  Each
> different path through the conditional compilation must be
> kept synchronized with all the others.  And then there's the issue
> of new hardware, or a new compiler, or even a new release
> of an existing compiler (perhaps with a new mode as the default).
> You're right back to manual porting.
> 
> Borland has a Delphi for Linux (I haven't checked the status
> of the project for a while).  It's supposed to be 80% or better
> source compatible with Delphi for Windows.  Borland said
> they will not even attempt to make C++ Builder for Linux-
> it would never be sufficiently compatible with C++ Builder
> for Windows to be worthwhile.
> 

They should probably rewrite the GUI parts using a cross platform GUI
builder.  I bet that would achieve the 80% compatibility marker.

> Knowing where the mines are is not the same as clearing
> the minefield.
> 
> --
> Cheers!
> 
> Dan Nagle
> Purple Sage Computing Solutions, Inc.


-- 

Gary Scott
mailto:garyscottNOSPAM@ev1.net

Fortran Library
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

In article <m2ad4dudm9.fsf@vega.dsl.att.net>, Richard Maine 
<nospam@see.signature> writes
>"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> writes:
>
>> Fortran programmers are *not* generally interested in
>> writing or maintaining code for other people to use.
>> They are usually "amateur" programmers
>> who write Fortran programs for their own use
>> to help them do the work that they were hired and paid to do.
>
>All generalizations are false.
>
>And we won't go into statistics, even those limited ones
>implied by words like "generally" and "usually".
>
>:-)
>
>P.S. I write code for other people to use.  But then, I am
>rarely accused of being normal, and I tend to glare at
>people who make such vulgar accusations.  :-)
>
I only write code for other people to use. And only occasionally are 
they even other people at my company - almost all my Fortran code is 
written or maintained for someone else on a commercial basis.

Therefore (from another post)

Let's have a show of hands.
Which of the contributors to this thread have an official job title of
"Fortran Programmer"?
"Software Engineer"?

That would be me.

Catherine.
-- 
Catherine Rees Lay
To email me, use my first name in front of the "at".

Catherine Rees Lay wrote:
> 
> In article <m2ad4dudm9.fsf@vega.dsl.att.net>, Richard Maine
> <nospam@see.signature> writes
> >"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> writes:
> >
> >> Fortran programmers are *not* generally interested in
> >> writing or maintaining code for other people to use.
> >> They are usually "amateur" programmers
> >> who write Fortran programs for their own use
> >> to help them do the work that they were hired and paid to do.
> >
> >All generalizations are false.
> >
> >And we won't go into statistics, even those limited ones
> >implied by words like "generally" and "usually".
> >
> >:-)
> >
> >P.S. I write code for other people to use.  But then, I am
> >rarely accused of being normal, and I tend to glare at
> >people who make such vulgar accusations.  :-)
> >
> I only write code for other people to use. And only occasionally are
> they even other people at my company - almost all my Fortran code is
> written or maintained for someone else on a commercial basis.
> 
> Therefore (from another post)
> 
> Let's have a show of hands.
> Which of the contributors to this thread have an official job title of
> "Fortran Programmer"?
> "Software Engineer"?

At my company it depends on context.  In the context of "market based
compensation", I am sometimes categorized as a "software engineer". 
When it comes to my title (or RIF assessments...), I'm usually
classified as a "systems engineer".  I'm actually a hardware/software
"integration" engineer or a type of "systems engineer" (I do a lot of TM
data analysis and lab collected data analysis (and boy are our lab tools
a lot better than the TM (and/or other flight test data) analysis
tools...sheesh in 2004 even).

> 
> That would be me.
> 
> Catherine.
> --
> Catherine Rees Lay
> To email me, use my first name in front of the "at".


-- 

Gary Scott
mailto:garyscottNOSPAM@ev1.net

Fortran Library
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

"E. Robert Tisdale"  wrote
> Let's have a show of hands.
> Which of the contributors to this thread have an official job title of
> "Fortran Programmer"?
> "Software Engineer"?

A more interesting statistic would be what percentage of fortran source-code
users spend more than 10% of their time programming.

Lahey did a survey of their compiler users some years ago in which they
asked the direct question, "Do you write code for other people to use?"  I
wonder what they found.  At least they thought to ask the question.

Charles Russell wrote:

> E. Robert Tisdale wrote:
> 
>>Let's have a show of hands.
>>Which of the contributors to this thread have an official job title of
>>"Fortran Programmer"?
>>"Software Engineer"?
> 
> A more interesting statistic would be,
> "What percentage of fortran source-code users
>  spend more than 10% of their time programming?"
> 
> Lahey did a survey of their compiler users some years ago in which they
> asked the direct question, "Do you write code for other people to use?"
> I wonder what they found.  At least they thought to ask the question.

Please understand that
the distinction between professional and amateur programmers
says no more about their expertize than
the distinction between professional and amateur athletes.
Olympic gold medalists, for example, are [supposedly] all amateurs.
Most C and C++ programmers are amateurs as well.
Brian Kernighan, Dennis Ritchie and Bjarne Stroustrup
are all amateur programmers.
Most of the professional programmers that I know
spend much less that 10% of their time programming.
Mostly, they are occupied with related duties
such as research, design and documentation.

But professional programmers generally have a whole set of concerns
that amateur programmers need never consider.
Not only must their code be correct and run fast and efficiently
but it must also be usable by people who are not themselves programmers.
It must be thoroughly tested and debugged before it is released for use.
It must be easy for other programmers to read, understand and maintain.
It must be modular so that the modules can be reused in other programs.
Usually, it must be portable to a variety of target platforms.
If it is part of a larger software development project,
it must be able to interoperate with all of the other parts
without too much knowledge about how those other parts are (or will be)
implemented.

"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> writes:

> But professional programmers generally have a whole set of concerns
> that amateur programmers need never consider.
> Not only must their code be correct and run fast and efficiently
> but it must also be usable by people who are not themselves programmers.
> It must be thoroughly tested and debugged before it is released for use.
> It must be easy for other programmers to read, understand and maintain.
> It must be modular so that the modules can be reused in other programs.
> [...]

Wow.  I had no idea.  I always thought "professional" just meant
you were paid.  I can think of several widely used systems written by
"professionals" that fail some (if not all) of your musts.

jwe

-- 
www.octave.org | www.che.wisc.edu/~jwe | Peace would shock and awe me.

"E. Robert Tisdale" wrote:

> Charles Russell wrote:
>
> > E. Robert Tisdale wrote:
> >
> >>Let's have a show of hands.
> >>Which of the contributors to this thread have an official job title of
> >>"Fortran Programmer"?
> >>"Software Engineer"?
> >
> > A more interesting statistic would be,
> > "What percentage of fortran source-code users
> >  spend more than 10% of their time programming?"
> >
> > Lahey did a survey of their compiler users some years ago in which they
> > asked the direct question, "Do you write code for other people to use?"
> > I wonder what they found.  At least they thought to ask the question.
>
> Please understand that
> the distinction between professional and amateur programmers
> says no more about their expertize than
> the distinction between professional and amateur athletes.
> Olympic gold medalists, for example, are [supposedly] all amateurs.
> Most C and C++ programmers are amateurs as well.
> Brian Kernighan, Dennis Ritchie and Bjarne Stroustrup
> are all amateur programmers.
> Most of the professional programmers that I know
> spend much less that 10% of their time programming.
> Mostly, they are occupied with related duties
> such as research, design and documentation.

Don't forget meetings and dog-and-pony shows -- or were they included
under design and documentation?  :-)

And, for the record, I usually list my profession as "software
engineer" (it used to be "programmer" until I found out software
engineers were paid more).  :-)


Bob Lidral
l i d r a l  at  a l u m  dot  m i t  dot  e d u

John W. Eaton wrote:

> I can think of several widely used systems written by "professionals"
> that fail some (if not all) of your musts.

Sigh.
Your observation is *not* unique. :-(

jwe@bevo.che.wisc.edu (John W. Eaton) writes:

> "E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> writes:
>
>> But professional programmers generally...

> Wow.  I had no idea.  I always thought "professional" just meant
> you were paid.

That's the definition I remember also.  All of this wanders rather
far from the original point, though...whatever it was.  This thread
still seems full of unsupported generalizations, regardless of how one
wants to redefine terms.

I'm not actually sure what point was trying to be made by the
generalizations, but I'm pretty sure I disagree with it and that
there is no concrete data behind it (asking for a "show of hands"
on clf doesn't constitute very concrete data, particularly if the
question asked isn't the same as the point it purports to prove).

-- 
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

Richard Maine wrote:

> That's the definition I remember also.  All of this wanders rather
> far from the original point, though...whatever it was.  This thread
> still seems full of unsupported generalizations, regardless of how one
> wants to redefine terms.
> 
> I'm not actually sure what point was trying to be made by the
> generalizations, but I'm pretty sure I disagree with it and that
> there is no concrete data behind it (asking for a "show of hands"
> on clf doesn't constitute very concrete data, particularly if the
> question asked isn't the same as the point it purports to prove).

I was just trying to explain a remark that Charles Russell
attributed to Jack Klien in the original post:

"The presenter said Fortran at which the department head winced
  and commented that Fortran is no longer being taught
  and that we should be using a "modern" language
  or we will have trouble supporting the code."

It simply asserts that it is difficult to recruit
[affordable,] trained, professional Fortran programmers.
Do you disagree?

In article <4014AE6D.8030908@jpl.nasa.gov>,
E. Robert Tisdale <E.Robert.Tisdale@jpl.nasa.gov> wrote:

>"The presenter said Fortran at which the department head winced
>  and commented that Fortran is no longer being taught
>  and that we should be using a "modern" language
>  or we will have trouble supporting the code."
>
>It simply asserts that it is difficult to recruit
>[affordable,] trained, professional Fortran programmers.
>Do you disagree?

The quote doesn't match your question at all.

In any case, I think that "the department head" is missing the point:
A programmer that is proficient in modern programming can quickly
learn Fortran. You miss it too, when you talk about recruiting people
who already know Fortran. If you're recruiting people so limited that
they can't learn something fairly simple, then you've got a huge
problem. And if the department is turning out students who can't
learn simple, new things...

-- greg

Dan Nagle wrote:
> 
> Hello,
> 
> On 23 Jan 2004 22:58:40 -0800, beliavsky@aol.com wrote:
> 
> >Dan Nagle <dnagle@erols.com> wrote in message news:<i9m2101e18uama5head0mfv8g21297uucs@4ax.com>...
> >> Hello,
> >>
> >> On the spectrum of portability, I like to define
> >> three regions:
> >>
> >> Not Portable (assemblers, code with heavy use of system calls)
> >>
> >> Weakly Portable (C/C++, portability obtained manually
> >> and then enshrined via conditional compilation)
> >>
> >> Strongly Portable (Ada, Fortran, source is portable
> >> without editing, even automatic editing such as conditional
> >> compilation)
> >>
> >> I'll freely admit that the boundaries are somewhat arbitrary.
> >>
> >> --
> >> Cheers!
> >>
> >> Dan Nagle
> >> Purple Sage Computing Solutions, Inc.
> >
> >Why would a C++ program to do a particular numerical computation be
> >less portable than an equivalent Fortran 95 program?
> 
> C++ Slogan: "With enough work, it's easy!"
> 
> Because the C++ program relies (typically) on conditional compilation
> of typedef and/or macros to select types, where the Fortran
> program relies on the standard kind mechanism.
> 
> Because the C++ program relies (typically) on conditional compilation
> of kernels for high performance from each different compiler
> where the Fortran program can get high performance just by being
> written clearly.
> 

My colleagues and I maintain a number of (for our company) rather
large programs, user-interfaces, general-purpose libraries and
so on, partly written in C, partly in Fortran. For the C programs
we always use a small set of user-defined types that guarantee
us that the reals and integers we use have well-known characteristics.

It may not be strictly necessary (nowadays), but it would be very 
frustrating if we had not: imagine coming across a platform that 
all of a sudden uses 2-byte longs instead of 4-byte longs?

One practical problem that arose the other day:

double x ; 
fprintf( outfile, "%f\n", x ) ; /* Works without a problem */

fscanf( infile, "%f", &x ) ; /* Causes a problem */

Can you spot why?

Hint: look up the promotion of float variables to double variables.

Regards,

Arjen

Greg Lindahl wrote:

> In any case, I think that "the department head" is missing the point:

What kind of department do you suppose s/he was head of?

> A programmer that is proficient in modern programming can quickly
> learn Fortran. You miss it too, when you talk about recruiting people
> who already know Fortran. If you're recruiting people so limited that
> they can't learn something fairly simple, then you've got a huge
> problem. And if the department is turning out students who can't
> learn simple, new things...

I guess that's the attitude os a typical amateur programmer.
Programming is a low level skill (like typing)
that the recruit can "pick up" on their own
in a few days (weeks, whatever).

For a professional programmer/software engineer,
programming is a finely honed skill that requires
years of study, practice and experience.

Yes.  A true professional programmer should be able
to pick up Fortran in a very short amount of time.
But professional programmers don't like to highlight
their Fortran programming experience on their resumes
because Fortran has traditionally been associated with
poor programming practices and bad habits, I suppose.

Bob Lidral <l1dralspamba1t@comcast.net> writes:

> Charles Russell wrote:
> 
> > "Jim Klein"  wrote
> > > The presenter said Fortran at which the
> > > department head winced and commented that Fortran is no longer being
> > > taught and that we should be using a "modern" language or we will have
> > > trouble supporting the code.
> >
> > Am I wrong in thinking that "portability" in the C world, and even more so
> > in the C++ world, means only that the code can be ported with less trouble
> > than to rewrite it?  Whereas I routinely use fortran written 20 or 30 years
> > ago that compiles and runs on my current box with no changes whatever.  And
> > you can't beat a few decades of extensive use to squeeze out the bugs.
> 
> Portability, for programs written in any language, depends on four
> things:
> 
>   1. characteristics of the task,
>   2. suitability of the programming language to the task,
>   3. willingness of the programmer to follow the language standard, and
>   4. willingness of the programmer to write portable code.
> 
> Compilers are good examples of tasks with characteristics that preclude
> portability.  A compiler that generates code for an AXP platform is not
> portable to a Pentium platform -- or, it might run on a Pentium platform
> but won't produce code that will run on a Pentium.  Even a compiler that
> generates code for a Pentium running Windows might run on a Linux
> platform but won't produce output files usable by the Linux system.

One word: gcc

David

Madhusudan Singh wrote:
> 
> On Saturday 25 October 2003 10:45, Jim Klein (jameseklein@earthlink.net)
> held forth in comp.lang.fortran
> (<1p2lpv0i2q4deufft15i2chr99at4dobca@4ax.com>):
> 
> > Hi,
> >
> > I was presenting in an IRAD project review yesterday. One of our
> > department heads (not mine thank God) asked what language some of the
> > code was written in. The presenter said Fortran at which the
> > department head winced and commented that Fortran is no longer being
> > taught and that we should be using a "modern" language or we will have
> > trouble supporting the code.
> >
> > I tried to point out to her that a large segment of the sciecne and
> > achedemic community uses Fortran and that for the process of number
> > crunching it is more efficient and suited than C or C++.
> >
> > I need some statictics to shove in her face so as to put this issue to
> > rest for our project once and forever.
> >
> > Suggestions?
> >
> > Sincerely,
> >
> > Jim Klein
> > Optical Designer and Optical Software Writer (Fortran+Winteracter on
> > PC and LINUX).
> 
> I do not have stats but the comment from that person seems to be one from a
> fellow who has used C for too long and hasn't heard of Fortran 90/95.

My two cents:

I was at a meteorology conference recently (AMS in Seattle) and I went to a talk about
ensemble forecasting. The gist of the talk was that the speakers methods were simple to
implement even "in a horrible old language like fortran" (I paraphrase).

Even really smart people can say (or do!) stupid things sometimes. :o)

cheers,

paulv

-- 
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

"E. Robert Tisdale" wrote:
> 
> Greg Lindahl wrote:
> 
> > In any case, I think that "the department head" is missing the point:
> 
> What kind of department do you suppose s/he was head of?
> 
> > A programmer that is proficient in modern programming can quickly
> > learn Fortran. You miss it too, when you talk about recruiting people
> > who already know Fortran. If you're recruiting people so limited that
> > they can't learn something fairly simple, then you've got a huge
> > problem. And if the department is turning out students who can't
> > learn simple, new things...
> 
> I guess that's the attitude os a typical amateur programmer.
> Programming is a low level skill (like typing)
> that the recruit can "pick up" on their own
> in a few days (weeks, whatever).
> 
> For a professional programmer/software engineer,
> programming is a finely honed skill that requires
> years of study, practice and experience.
> 
> Yes.  A true professional programmer should be able
> to pick up Fortran in a very short amount of time.
> But professional programmers don't like to highlight
> their Fortran programming experience on their resumes
> because Fortran has traditionally been associated with
> poor programming practices and bad habits, I suppose.

What a load of hooey...Sorry but I could no longer contain myself.

"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote:

>
>Please understand that
>the distinction between professional and amateur programmers
>says no more about their expertize than
>the distinction between professional and amateur athletes.
>Olympic gold medalists, for example, are [supposedly] all amateurs.

Strongly agree

>But professional programmers generally have a whole set of concerns
>that amateur programmers need never consider.
>Not only must their code be correct and run fast and efficiently
>but it must also be usable by people who are not themselves programmers.
>It must be thoroughly tested and debugged before it is released for use.

Strongly disagree with this slant.  I find no increase in
quality of software written by "professionals" above that
written by "amateurs."  Often, the latter produce more reliable
software, if usually for simpler tasks.


-- 
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

Arjen Markus <arjen.markus@wldelft.nl> wrote:

> [ snip ]
> One practical problem that [in C] arose the other day:

> double x ; 
> fprintf( outfile, "%f\n", x ) ; /* Works without a problem */
> fscanf( infile, "%f", &x ) ; /* Causes a problem */

> Can you spot why?

Er, yes, your fscanf() call has the wrong format.  I agree that it's a
famous trap of C, but this is *not* a portability problem.  We're
drifting off-topic.

Greg Lindahl <lindahl@pbm.com> wrote:

> A programmer that is proficient in modern programming can quickly
> learn Fortran. You miss it too, when you talk about recruiting people
> who already know Fortran. If you're recruiting people so limited that
> they can't learn something fairly simple, then you've got a huge
> problem. And if the department is turning out students who can't
> learn simple, new things...

(Sorry about the vacuous post.  Let's try that again.)

Greg Lindahl <lindahl@pbm.com> wrote:

> In any case, I think that "the department head" is missing the point:
> A programmer that is proficient in modern programming can quickly
> learn Fortran. You miss it too, when you talk about recruiting people
> who already know Fortran. If you're recruiting people so limited that
> they can't learn something fairly simple, then you've got a huge
> problem. And if the department is turning out students who can't
> learn simple, new things...

I would agree for most languages, but Fortran is... peculiar.  Things
that your proficient programmer would take for granted in any language
are anywhere between convoluted and impossible to do in Fortran.  (I
can't come up with specific examples right now, but I'll start to take
notes.)  A programmer wanting to learn Fortran would do well to dig up
an excellent book first.

My pedigree:  first language was Fortran, probably 66, doing
numerical analysis.  Switched to Pascal and then C in the 80's,
later learned scripting languages like perl and Tcl, with even an
episode of Rexx.  Picked up OO from perl and learned part of C++.
I'm probably leaving languages out.  Coming back to Fortran now
because in my new job the rest of the team doesn't know anything else.
There's a mix of F77 and F90+, depending on the age of the
practitioners.  The Fortran is causing me more troubles than I've had
in years.

I guess F2003 is at least moving in the right direction.  In today's
world, interoperability with C is the key to everything.

In article <4014D1B0.E9A1824C@wldelft.nl>,
Arjen Markus  <arjen.markus@wldelft.nl> wrote:

>One practical problem that arose the other day:
>
>double x ; 
>fprintf( outfile, "%f\n", x ) ; /* Works without a problem */
>
>fscanf( infile, "%f", &x ) ; /* Causes a problem */
>
>Can you spot why?

This is a quality of implementation issue:

foo.c:6: warning: float format, double arg (arg 3)

Get a better compiler. Fortran has many similar issues.

-- greg

Arjen Markus wrote:

> My colleagues and I maintain a number of (for our company) rather
> large programs, user-interfaces, general-purpose libraries and
> so on, partly written in C, partly in Fortran. For the C programs
> we always use a small set of user-defined types that guarantee
> us that the reals and integers we use have well-known characteristics.
>
> It may not be strictly necessary (nowadays), but it would be very
> frustrating if we had not: imagine coming across a platform that
> all of a sudden uses 2-byte longs instead of 4-byte longs?

I ran into this a few years ago on a compiler project I inherited.
Much of the original code had been written in VAX C for VMS and the
programmers just "knew" that shorts were 2 bytes; ints, longs, and
pointers were 4 bytes (and could, therefore, be overlaid on each other
-- sigh); memory pages and disk block sizes were 512 bytes; etc.  These
assumptions actually didn't cause too many problems until I got to
implement it for AXP/OpenVMS which has 8-byte pointers (and MUCH larger
page sizes and no PC-relative addressing and ...) but the real fun came
with the "port" to AXP/Tru64 Unix with 8-byte pointers, 2-byte shorts,
4-byte ints, and 8-byte longs.  We ended up having to write a utility
that scanned all of our code (ran for an entire weekend) and replaced
all "long" declarations with typedef'ed declarations that could be
guaranteed through platform-specific header files to be 4 bytes long
for all supported platforms (we had a lot of common code).  We never
encountered a platform with 2-byte longs but I've heard some early
platforms had 2-byte ints which might have caused us other problems
had we encountered them.

The whole problem could have been avoided, or at least minimized, by
using standard-conforming code and taking care to isolate or
paramaterize any platform-specific dependencies.


Bob Lidral
l i d r a l  at  a l u m  dot  m i t  dot  e d u

Pierre Asselin wrote:
> (Sorry about the vacuous post.  Let's try that again.)
>
> Greg Lindahl <lindahl@pbm.com> wrote:
>
>> In any case, I think that "the department head" is missing the point:
>> A programmer that is proficient in modern programming can quickly
>> learn Fortran. You miss it too, when you talk about recruiting people
>> who already know Fortran. If you're recruiting people so limited that
>> they can't learn something fairly simple, then you've got a huge
>> problem. And if the department is turning out students who can't
>> learn simple, new things...
>
> I would agree for most languages, but Fortran is... peculiar.  Things
> that your proficient programmer would take for granted in any language
> are anywhere between convoluted and impossible to do in Fortran.  (I
> can't come up with specific examples right now, but I'll start to take
> notes.)  A programmer wanting to learn Fortran would do well to dig up
> an excellent book first.

This is a rather backward argument.  If you were talking about
C or C++, say, that would be a true statement: things that your
proficient programmer would take for granted in any language
are anywhere between convoluted and impossible to do in
C and/or C++.  Ordinary arrays are very convoluted in C,
for example - it's very difficult to use arrays without introducing
pointers (which are almost never really necessary or desirable).

Fortran is a much simpler language to learn.  Much of the worry
employers have about prospective employees not knowing
Fortran comes from their knowledge of how enormously long
the learning curves for C++ or Java are and the expectatipon
that those learning curves to be representative for Fortran as well.
Now, there is an unlearning curve for people that use badly designed
languages like C.  The pointer/array issue is a good example: C
programmers can't see arrays, they only see pointers and they
expect all languages to work as C does.

The new F2003 will be considerably harder to learn (for not much
additional benefit).  Fortran is becoming a "me too" language.  That's
probably not a good thing.

-- 
J. Giles

Arjen Markus wrote:

(snip)

> It may not be strictly necessary (nowadays), but it would be very 
> frustrating if we had not: imagine coming across a platform that 
> all of a sudden uses 2-byte longs instead of 4-byte longs?
> 
> One practical problem that arose the other day:
> 
> double x ; 
> fprintf( outfile, "%f\n", x ) ; /* Works without a problem */
> 
> fscanf( infile, "%f", &x ) ; /* Causes a problem */
> 
> Can you spot why?

(comp.lang.c added)

Yes, I see why.

There is a popular convention of using typedef's for standard
width types to simplify portable programming.  Though more
common for integer types, it could be done for floating point.

As specific examples, C now has a size_t type, and types such
as int32 and int64 are often used.   What printf and scanf
format should be used with these types?

As C compilers will combine adjacent string constants into
one, one could have preprocessor symbols for format strings,

size_t y;
fscanf(infile, SIZE_T_FORMAT, &y);

typedefs such as float64, and FLOAT_64_FORMAT defined symbol could
help the floating point case above.

-- glen

pa@see.signature.invalid (Pierre Asselin) writes:

> I would agree for most languages, but Fortran is... peculiar.  Things
> that your proficient programmer would take for granted in any language
> are anywhere between convoluted and impossible to do in Fortran.

I can't agree with that as something "peculiar" to Fortran.  I'd agree
that almost any language has some things that are easier in it and
other things that are harder.  That apples to Fortran, but it applies
no more and no less than to any other language.

There are things that I find easy in Fortran that are incredibly
convoluted in other languages, including all the ones you mentioned.
Yes, I've used every one that you mentioned (except for Rexx) and
*LOTS* of others.  Other things, yes, I find easier in some different
language.

I don't think specifics are in order here, as that will just turn this
into a language flame war, which I have no interest in.  I can write
down some specifics, but I'll resist.  I'll stick to the generalities.
Otherwse you'd counter with specific examples the other way and before
long there would be an argument about which list is bigger or more
significant or whether particular items were better one way or
another.  But that's my whole point - that there are advantages on all
sides of these questions.  If you see only one side, then that is a
shortcoming of your vision.  If you think that Fortran is really
unique in this regard, then I'm going to claim that you have a pretty
narrow viewpoint.

(...unless you are talking about Fortran 66/77.  In that case, I'd say
you had a bit more of a case, but you've still stated it too
specifically.  I'd agree that on the whole languages of the 50s, 60s
and early 70s are more difficult to work with than languages of today.
But Fortran 66/77 don't stand alone there either.)

> A programmer wanting to learn Fortran would do well to dig up
> an excellent book first.

Well that part I agree with.  I hope you don't think this is any
different from any of the other languages you named.  You recommend
someone trying C without first digging up an excellent book?  I sure
hope not!  Wow!  And neat as TCL is for some things (I use TCL/Tk for
a gui front end for one of my Fortran programs), I do find it full of
very subtle issues that took quite a lot of reading (and then a fair
amount of trial and error) to figure out.

I tend to disagree with almost every statement that claims that
language X is uniquely good/bad compared to all other languages.
The world isn't like that.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

David Ham wrote:

> Bob Lidral <l1dralspamba1t@comcast.net> writes:
> > [...]
> >
> > Compilers are good examples of tasks with characteristics that preclude
> > portability.  A compiler that generates code for an AXP platform is not
> > portable to a Pentium platform -- or, it might run on a Pentium platform
> > but won't produce code that will run on a Pentium.  Even a compiler that
> > generates code for a Pentium running Windows might run on a Linux
> > platform but won't produce output files usable by the Linux system.
>
> One word: gcc

Well, OK, but ...  I've worked on compilers and other large projects
that work on several different operating systems and machine
architectures and produce the same results on each (so that user
applications can be made portable).  In each case, we used one large
collection of source code from which we selected different subsets of
source files for each target operating system/machine architecture
platform -- or, depending on the project, selected the same source files
for each platform but used preprocessor directives and system header
files to select different code paths within those files.  It's arguable
whether the executables produced by compiling the sources with different
sets of source files or preprocessor options are, in fact, the same
programs -- after all, they come from different source code (after
preprocessing) and produce different output when run.  (For compilers,
the "same results" mentioned above refers to the results of executing
user-written code compiled by the compiler -- not the compiler output.)

Anyhow, while it's possible to write a compiler that is portable to a
certain extent, "porting" it to a new operating system or machine
architecture almost always requires writing new code.  The format or
structure of object files may be different; for a different machine
architecture, it's a good bet the instruction set will be different.
Such programs require a great deal of effort to "port", though once the
original platform-specific code has been written, it's possible to have
a set of sources that can be used to generate an executable for any
specific already-supported platform -- and it can even be designed to
support cross-compiling.  But it takes more effort (at least the first
time) than just recompiling the code with different preprocessor
switches -- unless, of course, the resulting object code is intended to
run on some sort of virtual machine (e.g., Java?).


Bob Lidral
l i d r a l  at  a l u m  dot  m i t  dot  e d u

Richard Heathfield <invalid@address.co.uk.invalid> scribbled the following
on comp.lang.c:
> glen herrmannsfeldt wrote:
>> Arjen Markus wrote:
>>> One practical problem that arose the other day:
>>> 
>>> double x ;
>>> fprintf( outfile, "%f\n", x ) ; /* Works without a problem */
>>> 
>>> fscanf( infile, "%f", &x ) ; /* Causes a problem */
>>> 
>>> Can you spot why?
>> 
>> (comp.lang.c added)
>> 
>> Yes, I see why.

> In case anyone doesn't, and at the risk of spoiling an insiders' 
> nod-and-a-wink exchange, I'll spell it out:

> The problem is a missing 'l' character from the format specifier in the 
> scanf call. It should be "%lf" rather than "%f". In printf, %f works for 
> doubles /and/ floats. In scanf, %f is for float, and %lf is for double. 
> Strange but true.

AFAIK this comes from the way the C type system works. The crucial
thing here to understand is "default type promotions", and the fact that
the arguments given to printf() are "normal" value types, but the
arguments given to scanf() are pointers to those types.
The "default type promotions" apply to "normal" value types, but not to
pointers to those types. When a prototype for printf() is in scope,
chars get promoted to ints and floats to doubles, so "%c" is really
expecting an int, not a char, and "%f" is really expecting a double,
not a float.
However, pointers to char don't get promoted to pointers to int, and
pointers to float don't get promoted to pointers to double. Thus, in
scanf(), "%f" really does expect (a pointer to) a float like it claims
to, unlike in printf(), and "%c" really does expect (a pointer to) a
char.
Hence this weird-looking asymmetry.

-- 
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Outside of a dog, a book is a man's best friend. Inside a dog, it's too dark
to read anyway."
   - Groucho Marx

glen herrmannsfeldt wrote:

> Arjen Markus wrote:
> 
>> 
>> One practical problem that arose the other day:
>> 
>> double x ;
>> fprintf( outfile, "%f\n", x ) ; /* Works without a problem */
>> 
>> fscanf( infile, "%f", &x ) ; /* Causes a problem */
>> 
>> Can you spot why?
> 
> (comp.lang.c added)
> 
> Yes, I see why.

In case anyone doesn't, and at the risk of spoiling an insiders' 
nod-and-a-wink exchange, I'll spell it out:

The problem is a missing 'l' character from the format specifier in the 
scanf call. It should be "%lf" rather than "%f". In printf, %f works for 
doubles /and/ floats. In scanf, %f is for float, and %lf is for double. 
Strange but true.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Joona I Palaste wrote:

> Richard Heathfield <invalid@address.co.uk.invalid> scribbled the following
> on comp.lang.c:
>> glen herrmannsfeldt wrote:
>>> Arjen Markus wrote:
>>>> One practical problem that arose the other day:
>>>> 
>>>> double x ;
>>>> fprintf( outfile, "%f\n", x ) ; /* Works without a problem */
>>>> 
>>>> fscanf( infile, "%f", &x ) ; /* Causes a problem */
>>>> 
>>>> Can you spot why?
>>> 
>>> (comp.lang.c added)
>>> 
>>> Yes, I see why.
> 
>> In case anyone doesn't, and at the risk of spoiling an insiders'
>> nod-and-a-wink exchange, I'll spell it out:
> 
>> The problem is a missing 'l' character from the format specifier in the
>> scanf call. It should be "%lf" rather than "%f". In printf, %f works for
>> doubles /and/ floats. In scanf, %f is for float, and %lf is for double.
>> Strange but true.
> 
> AFAIK this comes from the way the C type system works.

<long and, as far as I could tell, correct explanation snipped>

I'm glad /you/ had to type that lot in. :-)

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

"James Giles" wrote
>
> The new F2003 will be considerably harder to learn (for not much
> additional benefit).  Fortran is becoming a "me too" language.  That's
> probably not a good thing.

If all you want to do is perform mathematical transformations on arrays of
reals, the language can be much simpler.  And that just about sums up
traditional scientific programming.

In article <KjfRb.15416$L04.1876@bignews4.bellsouth.net>,
Charles Russell <STOPworworSPAM@bellsouth.net> wrote:

>If all you want to do is perform mathematical transformations on arrays of
>reals, the language can be much simpler.  And that just about sums up
>traditional scientific programming.

Unless your array bounds are not the ends of the array, which sums up
a large fraction of traditional scientific programming. But we already
had this flamewar several times.

-- greg

lindahl@pbm.com (Greg Lindahl) writes:

> In article <KjfRb.15416$L04.1876@bignews4.bellsouth.net>,
> Charles Russell <STOPworworSPAM@bellsouth.net> wrote:
>
>>If all you want to do is perform mathematical transformations on arrays of
>>reals, the language can be much simpler.  And that just about sums up
>>traditional scientific programming.
>
> Unless your array bounds are not the ends of the array, which sums up
> a large fraction of traditional scientific programming. But we already
> had this flamewar several times.

I don't recall those flame wars.  Thankfully.  :-)

But then that probably just shows that I effectively ignored
them.  No need to repeat them just for me.  I'd just ignore
them again.  No, I'm not actually interested.  :-)

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Joona I Palaste wrote:
> 
> Richard Heathfield <invalid@address.co.uk.invalid> scribbled the following
> on comp.lang.c:
> > glen herrmannsfeldt wrote:
> >> Arjen Markus wrote:
> >>> One practical problem that arose the other day:
> >>>
> >>> double x ;
> >>> fprintf( outfile, "%f\n", x ) ; /* Works without a problem */
> >>>
> >>> fscanf( infile, "%f", &x ) ; /* Causes a problem */
> >>>
> >>> Can you spot why?
> >>
> >> (comp.lang.c added)
> >>
> >> Yes, I see why.
> 
> > In case anyone doesn't, and at the risk of spoiling an insiders'
> > nod-and-a-wink exchange, I'll spell it out:
> 
> > The problem is a missing 'l' character from the format specifier in the
> > scanf call. It should be "%lf" rather than "%f". In printf, %f works for
> > doubles /and/ floats. In scanf, %f is for float, and %lf is for double.
> > Strange but true.
> 
> AFAIK this comes from the way the C type system works. The crucial
> thing here to understand is "default type promotions", and the fact that
> the arguments given to printf() are "normal" value types, but the
> arguments given to scanf() are pointers to those types.
> The "default type promotions" apply to "normal" value types, but not to
> pointers to those types. When a prototype for printf() is in scope,
> chars get promoted to ints and floats to doubles, so "%c" is really
> expecting an int, not a char, and "%f" is really expecting a double,
> not a float.
> However, pointers to char don't get promoted to pointers to int, and
> pointers to float don't get promoted to pointers to double. Thus, in
> scanf(), "%f" really does expect (a pointer to) a float like it claims
> to, unlike in printf(), and "%c" really does expect (a pointer to) a
> char.

It is not a case of pointers not getting promoted, it is a case of
the location to which they point having a type, which can hardly
be expanded on the fly.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Richard Heathfield wrote:

(snip)

> In case anyone doesn't, and at the risk of spoiling an insiders' 
> nod-and-a-wink exchange, I'll spell it out:

> The problem is a missing 'l' character from the format specifier in the 
> scanf call. It should be "%lf" rather than "%f". In printf, %f works for 
> doubles /and/ floats. In scanf, %f is for float, and %lf is for double. 

Yes, most of us know that.

But what is the correct format descriptor for size_t?

For int16, int32, int64, float32, float64, or any other typedef
for an existing type?

That was the original question, for some reason in comp.lang.fortran.

The whole idea behind typedefs such as size_t is that you don't
need to know the actual type for the specific implementation, but
you do to use the right format descriptor.

-- glen

Richard Maine wrote:

(snip)

> I can't agree with that as something "peculiar" to Fortran.  I'd agree
> that almost any language has some things that are easier in it and
> other things that are harder.  That apples to Fortran, but it applies
> no more and no less than to any other language.

Pretty much you can find peculiarities in any language.

I think, though, that the way multidimensional arrays are stored
in memory is peculiar of Fortran, and would be surprising to
anyone who has used enough other languages to notice a pattern.

I don't want to argue that it is wrong, any more than I like to
argue over big vs. little endian byte order.  (Even though I
think big-endian is much better than little-endian.)

-- glen

glen herrmannsfeldt wrote:
> I don't want to argue that it is wrong, any more than I like to
> argue over big vs. little endian byte order.  (Even though I
> think big-endian is much better than little-endian.)

The main reason to like big-endian is that I've never seen a
little-endian implementation that was fully consistent.
I've used big-endian implementations that were consistent.
Neither is inherently bad.  Same thing goes for array order.
And for the same reason: it mostly shouldn't matter and the
instances where it does matter should be getting fewer and
farther between as programming tends toward higher-level
concerns.

-- 
J. Giles

glen herrmannsfeldt wrote:
> But what is the correct format descriptor for size_t?

In C99, '%zu'.  In C89 one of the integer specifiers and a cast, e.g.

    size_t t;
    /* ... */
    printf("%u\n", (unsigned)t);

> For int16, int32, int64, float32, float64, or any other typedef
> for an existing type?

For int32_t &c. C99 provides corresponding format specifiers in the
form of macros, which expand to string literals containing appropriate
specifiers for the underlying types.  For example, in the following
code

   #include <inttypes.h>
   #include <stdio.h>

   int32_t i;
   // ...
   printf("i is " PRIdN "\n", i);

the printf call expands, after string concatenation, to

   printf("i is %ld\n", i);

if int32_t is an alias for signed long.

> The whole idea behind typedefs such as size_t is that you don't
> need to know the actual type for the specific implementation, but
> you do to use the right format descriptor.

Right.

Jeremy.

"James Giles" <jamesgiles@worldnet.att.net> writes:

> The main reason to like big-endian is that I've never seen a
> little-endian implementation that was fully consistent.

The main reason I like big-endian is that I'm big-endian...

which I'm sure could be humorously interpreted :-), but what
I mean is that when I write numbers, I write the most
significant digits first.  For decimal, it doesn't make
much difference because decimal digits don't correspond
directly to particular bits anyway (in the most common
representations - I don't often deal with things like
packed decimal).

But if I'm reading a hex dump of something, I have to remember
to swap the hex digits (in groups of 2) to deal with
little-endian, while for big-endian I just read them as is.

> Neither is inherently bad.

I agree with that.  Just what I tend to find easiest to deal with.
Other matters have far higher priority.  I didn't avoid moving from
Sun boxes to Linux because of the byte sex.  In fact, I don't ever
recall making a purchase decision based on byte sex.
Price/performance was a lot more important.  Fortunately, I don't
spend a lot of time studying hex dumps. Unfortunately, I do spend
some. :-(

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

"Greg Lindahl" wrote
>
> Unless your array bounds are not the ends of the array, which sums up
> a large fraction of traditional scientific programming. But we already
> had this flamewar several times.

My viewpoint was perhaps unclear.  I'm one of those who prefers a simple
language that is specialized for mathematical operations on floating point
arrays, designed to support libraries of interoperable math routines like
SLATEC, where the only I/O is via the error handler.  For those who want to
do something else, such a language would of course be quite inappropriate.

In article <kuhRb.830$qR3.439@bignews3.bellsouth.net>,
Charles Russell <STOPworworSPAM@bellsouth.net> wrote:

>My viewpoint was perhaps unclear.  I'm one of those who prefers a simple
>language that is specialized for mathematical operations on floating point
>arrays, designed to support libraries of interoperable math routines like
>SLATEC, where the only I/O is via the error handler.  For those who want to
>do something else, such a language would of course be quite inappropriate.

Ah. I thought you were comparing F200X with earlier versions. I see I
was confused.

-- greg

Pierre Asselin (aka Bruce) was almost, but not quite, entirely unlike tea:
> (Sorry about the vacuous post.  Let's try that again.)
> 
> Greg Lindahl <lindahl@pbm.com> wrote:
> 
>> In any case, I think that "the department head" is missing the point:
>> A programmer that is proficient in modern programming can quickly
>> learn Fortran. You miss it too, when you talk about recruiting people
>> who already know Fortran. If you're recruiting people so limited that
>> they can't learn something fairly simple, then you've got a huge
>> problem. And if the department is turning out students who can't
>> learn simple, new things...
> 
> I would agree for most languages, but Fortran is... peculiar.  Things
> that your proficient programmer would take for granted in any language
> are anywhere between convoluted and impossible to do in Fortran.  (I
> can't come up with specific examples right now, but I'll start to take
> notes.)  A programmer wanting to learn Fortran would do well to dig up
> an excellent book first.

Lack of any decent implementation of anything POSIX, such as popen()
(my pet beef for the time being) for the sake of portability. I mean,
who sane would ever want to port between windows and UNIX? Given that
POSIX exists on everything UNIX, I would at least like implementations
of POSIX to be standardised on UNIX fortran compilers. But because
they must remain portable with windows compilers, no one bothers to do
it properly.

character(LEN=something_fixed) (can you even use allocate with
strings?), and marking the end of string with white-spaces, instead of
doing something sane like null-terminated strings.

Until F2003, can't portably interoperate with C.

The whole deal with records in files and luns etc seems so 1960's. To
me, fds and reading using read, scanf, getc etc seem so much more
sane. The way one can't read an arbitrary line length from a file,
because recl wasn't set long enough was a solved problem with C in the
80's. Just allocate your own string, and read the requisite length
(sure, careless programmers will end up with buffer overflows, but
this is so elementary, any programmer worth their salt learnt it when
they were 16). If the string is still not long enough to fit the line,
read the next part of the line, and catenate the strings. Note, there
is no seeking involved anywhere, so one can read from pipes. Buffering
was also a solved problem in the 80's. Why then does the Intel fortran
compiler still do this sub-optimally?

I've got a few more, but can't really remember them for the time
being.

Note that my background is C, bash and perl. I rarely find I need to
deal in C anymore - I use perl for all my glue logic. I deal with F77
code, and as I work on it, I slowly translate it to more modern
looking F95 stuff. But I try to avoid doing absolutely anything
involving non-numeric stuff, and plug it into my perl code. Fortran's
just too much of a pain to do anything IO or text related.


-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
That [Tim-Tam] would be the Classic. Not to be confused with the
Chocolate, Chocolate, Chocolate, and Double Chocolate flavour.
(Personally, I prefer Cadbury's Doubles myself. Tim Tams don't taste
enough of chocolate.)  -- Faceless Man on ARK

Richard Maine wrote:
> "James Giles" <jamesgiles@worldnet.att.net> writes:
>
>> The main reason to like big-endian is that I've never seen a
>> little-endian implementation that was fully consistent.
....
> But if I'm reading a hex dump of something, I have to remember
> to swap the hex digits (in groups of 2) to deal with
> little-endian, while for big-endian I just read them as is.

Ah, but that's what I mean by little-endian not being fully consistent.
If the implementation were really consistent, the dump display would
be in exactly the order that's most natural to read (with the most
significant parts left and above the less significant parts) and the
addresses would increase up and to the left.  You wouldn't have
to mentally reverse anything but the address values themselves
(which would, I assume, become second nature if the form was
really consistent).

But, especially for character data, so-called little-endian
implementations tend to have big-endian storage order.  Hence
the need for the character portion of the dump to be displayed
in the reverse order from the numeric display.  And there are
usually other peculiarities.

-- 
J. Giles

TimC wrote:
....
> character(LEN=something_fixed) (can you even use allocate with
> strings?), and marking the end of string with white-spaces, instead of
> doing something sane like null-terminated strings.

The blanks don't mark the end of the string.  The length is mainteained
independently of the content.  Null trerminated strings are a *very*
poor design.  Should have been relegated to the scrap heap decades
ago.

> Until F2003, can't portably interoperate with C.

Thank heavens I almost never need to.

> The whole deal with records in files and luns etc seems so 1960's. To
> me, fds and reading using read, scanf, getc etc seem so much more
> sane. The way one can't read an arbitrary line length from a file,

Use non-advancing I/O.  Been in the standard for over a decade.

> because recl wasn't set long enough was a solved problem with C in the
> 80's. Just allocate your own string, and read the requisite length
> (sure, careless programmers will end up with buffer overflows, but
> this is so elementary, any programmer worth their salt learnt it when
> they were 16). [...]

Evidently there's a lot of wasted salt in the world: buffer overflows
remain one of the major causes of fyftem failure in both Windows and
UNIX style ststems.  Buffer overflow should be prevented by the
language itself.

> [...]        If the string is still not long enough to fit the line,
> read the next part of the line, and catenate the strings. [...]

Like non-advancing I/O.  Been in the Fortran language for over a decade.

> [...]                     Note, there
> is no seeking involved anywhere, so one can read from pipes. Buffering
> was also a solved problem in the 80's. [...]

Well, I've never seen a UNIX or Windows system that did buffering
particularly well.  Often I like to use memory mapped I/O to bypass
the buffers (assuming it's sanely implemented, it will do so).

> [...]                   But I try to avoid doing absolutely anything
> involving non-numeric stuff, and plug it into my perl code. Fortran's
> just too much of a pain to do anything IO or text related.

I always found Fortran's text better than C's by a lot.  Neither is
well designed as a text manipulation language.  Fortran's original
character type should have been (what are now called) varying
strings.  That would have eliminated any plausible C-advacacy.
There was a character string proposal in the LWG-Fortran report
in 1982 that was superior anything in C.  It could even still be
done, little has been added since then that's inconsistent with
that proposal.

-- 
J. Giles

James Giles (aka Bruce) was almost, but not quite, entirely unlike tea:
>> The whole deal with records in files and luns etc seems so 1960's. To
>> me, fds and reading using read, scanf, getc etc seem so much more
>> sane. The way one can't read an arbitrary line length from a file,
> 
> Use non-advancing I/O.  Been in the standard for over a decade.
.... 
>> [...]        If the string is still not long enough to fit the line,
>> read the next part of the line, and catenate the strings. [...]
> 
> Like non-advancing I/O.  Been in the Fortran language for over a decade.

I only have the Intel compiler to go on here, so maybe not a good
sample to draw on.

But the non-advancing IO is no good there. For writing, it doesn't
actually output to the terminal until a non-IO advancing IO write is
performed. It just concatenates to the buffer. Which means, we come
back to the issue of records.

The intel compiler will generate code that barfs if you try to output
many peices of text using non-advancing IO, without occasionally
writing a newline somewhere, because it fills the buffer. You have to
manually increase recl for STDOUT to something that will be safe. And
this is unsafe anyway, because maybe the stream could be infinitely
long.

Sure, quality of implementation issue, but if the quality of a
particular (major) implementation of the language is no good, and the
implementation is allowed by the standard, that says something about
the standard, I feel.

I forgot another issue before: having to say achar(10) or 13 instead
of just \n or \r like any other language.

Here again, I am only writing for unix. I don't care about windows,
but if I did, I could write a wrapper that translates "\n" to
"\r\n". If you are programming for windows, you can use "\r\n" to your
liking, and not care about "\n". One rarely ports between windows and
UNIX, so I don't feel this should be made by the language to be
deliberately hard to do, for the sake of a particular varierty of
portability that no one uses[1].

>Evidently there's a lot of wasted salt in the world: buffer overflows
>remain one of the major causes of fyftem failure in both Windows and
>UNIX style ststems.  Buffer overflow should be prevented by the
>language itself.

A language making something hard to stop people making mistakes is
another mistake of fortran. I tend to prefer power to hand
holding. The latter is what (standardized) Pascal is for.


[1] To me, portability means it will work on a solaris box equally
well to Linux or Cray or what have we. But these aren't going to work
straight away on doze anyway, because of the way doze treats
filenames, or anything else.


-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
FORTRAN is a good example of a language which is easier to parse
using ad hoc techniques.                -- D. Gries

"James Giles" <jamesgiles@worldnet.att.net> wrote in message news:<z6eRb.21158$6O4.540635@bgtnsc04-news.ops.worldnet.att.net>...

<SNIP>
 
> Fortran is a much simpler language to learn.  Much of the worry
> employers have about prospective employees not knowing
> Fortran comes from their knowledge of how enormously long
> the learning curves for C++ or Java are and the expectatipon
> that those learning curves to be representative for Fortran as well.
> Now, there is an unlearning curve for people that use badly designed
> languages like C.  The pointer/array issue is a good example: C
> programmers can't see arrays, they only see pointers and they
> expect all languages to work as C does.

<SNIP>

I think employers may be more concerned that their programmers will
not WANT to learn Fortran, since it is not a very marketable skill in
the software job market. I am not happy to say this about my favorite
language, but I am afraid it is true.

TimC wrote:
....
> I forgot another issue before: having to say achar(10) or 13 instead
> of just \n or \r like any other language.

Again, I oppose those anyway.  But, on the other hand, I have an
operator that does that (now that string length is allocatable).
So, if you write:

   aString = "Abc\n"

The value of the string will be 5 characters long and both the
backslash and the 'n' character will be in it.  On the other hand,
if you write:

   aString = .cstr. "Abc\n"

The value will be a string 5 characters long and the last two
will be (on an ASCII version of the implementation) a line-feed
and a null.

>> Evidently there's a lot of wasted salt in the world: buffer overflows
>> remain one of the major causes of fyftem failure in both Windows and
>> UNIX style ststems.  Buffer overflow should be prevented by the
>> language itself.
>
> A language making something hard to stop people making mistakes is
> another mistake of fortran. I tend to prefer power to hand
> holding. The latter is what (standardized) Pascal is for.

In this case, it's the language making something easier *and* safer.
It's also always (*always*) more efficient to directly keep track of
the length explicitly rather than using null termination.  Buffer overflow
is something that's been solved since the late fifties, and the solution,
for convenience, efficiency, and safety, is to have the programming
environment enforce it.

Power doesn't consist of having to always worry about irrelevant trivia.
A higher-level language that lets you express things clearly (and verifiably)
is always more powerful.

-- 
J. Giles

Richard Maine wrote:

(snip regarding endianness)

> But if I'm reading a hex dump of something, I have to remember
> to swap the hex digits (in groups of 2) to deal with
> little-endian, while for big-endian I just read them as is.

(snip)

> I agree with that.  Just what I tend to find easiest to deal with.
> Other matters have far higher priority.  I didn't avoid moving from
> Sun boxes to Linux because of the byte sex.  In fact, I don't ever
> recall making a purchase decision based on byte sex.
> Price/performance was a lot more important.  Fortunately, I don't
> spend a lot of time studying hex dumps. Unfortunately, I do spend
> some. :-(

That VAX/VMS DUMP program would print the ASCII values left to right,
and the hex values right to left.   Very strange, but it did make them
readable.

Another thing about little endian is that it can hide bugs in programs,
though some have called it an advantage.  If you pass a subroutine
argument by address, and the argument has the wrong size and is little
endian, you might not notice the wrong value.  If it is big endian,
it is almost sure that you will receive the wrong value.

Faster debugging.  And dumps are easier to read in the right order.

-- glen

James Giles (aka Bruce) was almost, but not quite, entirely unlike tea:
> Fortran is a much simpler language to learn.  Much of the worry
> employers have about prospective employees not knowing
> Fortran comes from their knowledge of how enormously long
> the learning curves for C++ or Java are and the expectatipon
> that those learning curves to be representative for Fortran as well.
> Now, there is an unlearning curve for people that use badly designed
> languages like C.  The pointer/array issue is a good example: C
> programmers can't see arrays, they only see pointers and they
> expect all languages to work as C does.

Not sure about the simpler part. I most definitely say it depends on
your background. My very first language was a dialect of Pascal (a
useful one - Turbo Pascal).

From there, moving to a proprietry teaching language, then C was easy
(a couple of weeks each). Then the scripting languages
(perl/bash). You very very quickly learn enough to be useful. You
slowly learn enough to not be dangerous. You everntually learn enough
to be *really* powerful.

Learning fortran enough to be useful also took a short amount of
time. I originally thought it was a hell of an ugly language, so tried
to stay away from it. But since my thesis involved trying to
understand someone else's f77, I had to use it :)

After 2 years, I think I know the language fairly well. I use a few
F90 features, but certainly not all. Hell, I still haven't used
modules or pointers. Since I am modifying old code (and even starting
the occasional program from scratch, but only small ones to process
code from other fortran programs, and programs that has evolved rather
than ever been designed), and any brand new code gets written in perl,
there is little scope to adopt more modern constructs in any fortran
that I use.

Funnily enough, I still think it is a hell of an ugly language, but I
realise it has some strengths.

But for someone that comes from a C background, the benefits you see
of Fortran, I see as drawbacks. The drawbacks you see of C, I see as
features.

Modules and OO and everything new in fortran seem more of a hack that
header files and the OO addons to C (i.e, C++), and that is really
saying a lot. But you are free to ignore me, since I have already said
I don't yet use modules, so am probably wrong :)

-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
But if I ever have a child, I will certainly be naming it "Sun
Microsystems".  -- Hipatia

In article <3064b51d.0401261803.ca5422@posting.google.com>,
 <beliavsky@aol.com> wrote:

>I think employers may be more concerned that their programmers will
>not WANT to learn Fortran, since it is not a very marketable skill in
>the software job market. I am not happy to say this about my favorite
>language, but I am afraid it is true.

And, as I mentioned before, it's a sign that they aren't very good
learners.

Or maybe they believe they'll catch cooties.

-- greg

TimC <tconnors@no.astro.spam.swin.accepted.edu.here.au> writes:

> But the non-advancing IO is no good there. For writing, it doesn't
> actually output to the terminal until a non-IO advancing IO write is
> performed.

The standard pretty specifically encourages implementations to do
non-advancing output differently than that (so it can be used for
prompting).  If the Intel compiler doesn't follow that recommendation,
I'd consider that a poor implementation decision.

> I forgot another issue before: having to say achar(10) or 13 instead
> of just \n or \r like any other language.

*ANY* other language?  The most effective critique I can make on the
narrowness of viewpoint reflected by that statement is to just let
the statement speak for itself.  If you think that is an accurate
statement, then I certain;y wouldn't want to argue with you about it.
(I wouldn't agree, but I wouldn't want to argue with you about it).

-- 
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

TimC wrote:
> 
> Funnily enough, I still think it is a hell of an ugly language, but I
> realise it has some strengths.

What's "ugly" wrt to a programming language?  I don't see how the term
applies.  (Granted, one can write shoddy code in any language, but I
don't see that as part of the language itself.)
 
> But for someone that comes from a C background, the benefits you see
> of Fortran, I see as drawbacks. The drawbacks you see of C, I see as
> features.

I think that statement simply reflects entirely that you're making a
judgement based from a C viewpoint rather than otherwise.  Also, it
appears you're primarily comparing F77 (and perhaps much earlier) code
to C where many of the F90/95 advantages in syntax aren't as apparent.  

Not taking advantage of modules in new code even if it's simply an
additional module/function in existing code seems to me to be simply
staying with the old simply for the sake of being able to say you don't
like it as much as anything.  Certainly the ability to manipulate entire
arrays w/o writing explicit loops is one major advantage of F90 over C
that makes the source code <much> more easily reflect the problem
domain.

In article <slrn-0.9.7.4-25909-26082-200401271317-tc@hexane.ssi.swin.edu.au>,
TimC  <tconnors@no.astro.spam.swin.accepted.edu.here.au> wrote:

>But for someone that comes from a C background, the benefits you see
>of Fortran, I see as drawbacks. The drawbacks you see of C, I see as
>features.

Indeed. I'm not bothered at all that I can't work around a broken I/O
library in Fortran without writing a few, trivial C wrapper functions.
Different tools for different jobs. And it's good to know how to use
them together.

You'll have to take my word for it that all the code that glues my
website together is better of written in Perl than C or C++.

-- greg

> Ah, but that's what I mean by little-endian not being fully consistent.
> If the implementation were really consistent, the dump display would
> be in exactly the order that's most natural to read (with the most
> significant parts left and above the less significant parts) and the
> addresses would increase up and to the left.  You wouldn't have
> to mentally reverse anything but the address values themselves
> (which would, I assume, become second nature if the form was
> really consistent).

Then VMS really is fully consistent little-endian - it does _all_ of
the above, including the bit about the addresses (if I understand you
correctly).

	Jan

Jan C. Vorbr�ggen wrote:
>> Ah, but that's what I mean by little-endian not being fully consistent.
>> If the implementation were really consistent, the dump display would
>> be in exactly the order that's most natural to read (with the most
>> significant parts left and above the less significant parts) and the
>> addresses would increase up and to the left.  You wouldn't have
>> to mentally reverse anything but the address values themselves
>> (which would, I assume, become second nature if the form was
>> really consistent).
>
> Then VMS really is fully consistent little-endian - it does _all_ of
> the above, including the bit about the addresses (if I understand you
> correctly).

It has been too long since I looked at VMS.  If the string "ABC" is
stored in memory with "C" at the smallest address and "A" at the
highest address, then that's consistent with little-endian.

-- 
J. Giles

Jan C. Vorbr�ggen wrote:
>> Ah, but that's what I mean by little-endian not being fully consistent.
>> If the implementation were really consistent, the dump display would
>> be in exactly the order that's most natural to read (with the most
>> significant parts left and above the less significant parts) and the
>> addresses would increase up and to the left.  You wouldn't have
>> to mentally reverse anything but the address values themselves
>> (which would, I assume, become second nature if the form was
>> really consistent).
>
> Then VMS really is fully consistent little-endian - it does _all_ of
> the above, including the bit about the addresses (if I understand you

It has been too long since I looked at VMS.  If the string "ABCDEFGH"
is stored in memory with "H" at the smallest address and "A" at the
highest address, then that's consistent with little-endian.  An eight
byte integer would similarly have the highest address correspond to
the most significant base-256 digit of the number.  Etc.  If that's
what VMS does, then it's consistent.

-- 
J. Giles

> A language making something hard to stop people making mistakes is
> another mistake of fortran. I tend to prefer power to hand
> holding.

I'm sure that, if you were working in a print shop, with that kind of
attitude your first day on the job you would remove the blade guards
and interlocks from the paper knife. 

On the second day, you'd be fired after having amputated some of your
fingers.

	Jan

> It has been too long since I looked at VMS.  If the string "ABCDEFGH"
> is stored in memory with "H" at the smallest address and "A" at the
> highest address, then that's consistent with little-endian.  An eight
> byte integer would similarly have the highest address correspond to
> the most significant base-256 digit of the number.  Etc.  If that's
> what VMS does, then it's consistent.

It does the latter, but not the former. I've never heard the suggestion
to store strings differently also. The usual argument about sorting or
searching them doesn't apply in practice - because of collating order
for one, multi-byte "characters" for a second, and thirdly because the
actual algorithms don't care about the byte order.

For the numerical side, it leads to the side-effect that you can "safely"
pass a smaller integer as an actual argument to a larger integer dummy
argument, an a single-precision fp to a double-precision dummy. This bad
practice of course breaks on big-endian systems.

	Jan

In article <7kia10lckagi2r7lfgloc7sc7plma2m7ik@4ax.com>, Michael Prager 
<Mike.Prager.indigo@noaa.gov> writes
>"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote:
>
>>
>>Please understand that
>>the distinction between professional and amateur programmers
>>says no more about their expertize than
>>the distinction between professional and amateur athletes.
>>Olympic gold medalists, for example, are [supposedly] all amateurs.
>
>Strongly agree
>
>>But professional programmers generally have a whole set of concerns
>>that amateur programmers need never consider.
>>Not only must their code be correct and run fast and efficiently
>>but it must also be usable by people who are not themselves programmers.
>>It must be thoroughly tested and debugged before it is released for use.
>
>Strongly disagree with this slant.  I find no increase in
>quality of software written by "professionals" above that
>written by "amateurs."  Often, the latter produce more reliable
>software, if usually for simpler tasks.
>
>
I think you missed the point, which wasn't about quality. If you're an 
"amateur" writing software for your own use, you can debug it using the 
actual data you are interested in, and use tested parts for real 
calculations before other parts are fully tested, because you know which 
they are. Similarly, you know which parts of the code will be used most 
often so be most speed-critical. For code written for a 3rd party, this 
isn't true. That's not to say that the code which is entirely debugged 
on test cases before being released is any better than the code which 
was debugged on-the-fly by its author while working with real data, it's 
just a different way of working which is required for "professionals" 
(where, like the OP, I'm using "professional" for those of us for whom 
the end product is the program, and "amateur" for those for whom it's 
the program's results, either of which may, but don't necessarily, imply 
"done on our own time").

Catherine.
-- 
Catherine Rees Lay
To email me, use my first name in front of the "at".

Jan C. Vorbr�ggen wrote:
>> It has been too long since I looked at VMS.  If the string "ABCDEFGH"
>> is stored in memory with "H" at the smallest address and "A" at the
>> highest address, then that's consistent with little-endian.  An eight
>> byte integer would similarly have the highest address correspond to
>> the most significant base-256 digit of the number.  Etc.  If that's
>> what VMS does, then it's consistent.
>
> It does the latter, but not the former. I've never heard the suggestion
> to store strings differently also. [...]

Well, the point is that storing strings *is* done differently.  That is, the
storage order for character strings is big-endian.  One of the tests of
consistent order in this thread has been a dump of memory.  If strings
are stored in big-endian, and numbers are stored in little-endian, then
the dump of a given block of memory will be displaying one or the
other type of data backwards.  As I said, it's a minor point, but it's
one reason that I prefer Big-endian: it's often done consistently.

> For the numerical side, it leads to the side-effect that you can "safely"
> pass a smaller integer as an actual argument to a larger integer dummy
> argument, an a single-precision fp to a double-precision dummy. This bad
> practice of course breaks on big-endian systems.

Breaks anyway for modern floating point.  The number of bits devoted to
the exponent parts vary between single and double.

-- 
J. Giles

Charles Russell <STOPworworSPAM@bellsouth.net> wrote:

> If all you want to do is perform mathematical transformations on arrays of
> reals, the language can be much simpler.  And that just about sums up
> traditional scientific programming.

Well, that's certainly one way to operate.  Write numerical routines
in F77, because it's easy to learn, well-supported and completely
stable.  Write absolutely everything else in some language X;
compile the F77 with F2003 compilers to guarantee interoperability
with C uniformly across platforms; if X .ne. C, use swig to generate
the boilerplate glue.

F77 is usually fine for deep number-crunching, but not always.  What
if you want to generate finite-element meshes, for example?  A bit of
F90 or later would come in handy, but in my experience this is where
things start falling apart.

"Jan C. Vorbr�ggen" <jvorbrueggen@mediasec.de> wrote in message
news:40164696.A42DF9BE@mediasec.de...
> > Ah, but that's what I mean by little-endian not being fully consistent.
> > If the implementation were really consistent, the dump display would
> > be in exactly the order that's most natural to read (with the most
> > significant parts left and above the less significant parts) and the
> > addresses would increase up and to the left.  You wouldn't have
> > to mentally reverse anything but the address values themselves
> > (which would, I assume, become second nature if the form was
> > really consistent).
>
> Then VMS really is fully consistent little-endian - it does _all_ of
> the above, including the bit about the addresses (if I understand you
> correctly).
>
> Jan
I could never get used to the logicality of floating point types being
stored in big-endian order, but with each pair of bytes swapped to
little-endian order.  SGI systems copied this, but the software fixed it up
when reading and writing binary files, for consistency with big-endian
systems.  Likewise, major Fortran compilers for Intel architecture now have
options to work with big-endian binary files.

> I could never get used to the logicality of floating point types being
> stored in big-endian order, but with each pair of bytes swapped to
> little-endian order.  

Yeah, the problem of the installed base, in this case PDP-11 FP format(s)...

> SGI systems copied this, but the software fixed it up when reading and > writing binary files, for consistency with big-endian systems. 

Why would they be doing that - the above was a PDP-11/VAX-11 special?

	Jan

Richard Maine <nospam@see.signature> wrote:

> I can't agree with that as something "peculiar" to Fortran.  I'd agree
> that almost any language has some things that are easier in it and
> other things that are harder.  That apples to Fortran, but it applies
> no more and no less than to any other language.

I know I'm not making a good case, it's a bit frustrating.  I guess
the big difference between Fortran and other compilable languages
is that Fortran is truly a high-level language.  It leaves a lot
of latitude to the implementation, including the latitude to optimize
the sh*t out of the binaries.

In my opinion, Fortran carries this high-level business a bit too
far.  Your program is supposed to run just fine on a Fortran
"processor", but it's as if you always get into trouble when you
try to run it on a physical computer, for reasons that I can help
but find "peculiar".  For example, we had a recent thread here on
the "recompilation cascade".  The cause?  Fortran modules (good
feature) do not separate interface from implementation (an
incomprehensibly bad design, to any programmer with experience in
anything else.)

Since the comparison with C is inevitable, let me go at it.  C was
targeted at microprocessors and it was a remarkable thing:  a
low-level language that could be used in a high-level way.  The
semantic gap between the language and the hardware was small, and
that is why experienced programmers can understand it.  I agree
that C hasn't aged well in that respect, the semantics are now
overspecified and get in the way of optimization.  Heck, nowadays
the semantic gap between *assembler* and the hardware is pretty
darn wide.  I hope the vendors decide to take advantage of the
"restrict" pointers and start shipping good optimizing compilers
already.

For whatever historical reasons, C is the portable language today,
and Fortran just ain't.  Every language has to interoperate with
C, and every other language already does.  This is why the
interoperability section of the 2003 draft standard are so critical.
Maybe the way of the future is to write only number-crunching
routines in Fortran and accept that applications will always be
written in some other language, relegating Fortran to a niche in
libraries.  That's a viable approach, but it's rather sad.

-- 
pa at panix dot com

Jan C. Vorbr�ggen <jvorbrueggen@mediasec.de> writes:

> For the numerical side, it leads to the side-effect that you can "safely"
> pass a smaller integer as an actual argument to a larger integer dummy
> argument, an a single-precision fp to a double-precision dummy. This bad
> practice of course breaks on big-endian systems.

I'm confused as to whether you consider this a good point or a
bad one.  (only half :-)).

It also breaks on little-endian ones - just in more subtle ways.
I'd rather get the egregiously wrong answer that forced me to track
down the bug because the erroneously passed fp value ended up
300 orders of magnitude off, rather than the subtly wrong one from
the error in the 7th decimal place.  Or the corruption of
adjacent memory locations.

There are many errors caused by getting slopy about types.  I
don't like things that encourage it.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

> I'd rather get the egregiously wrong answer that forced me to track
> down the bug because the erroneously passed fp value ended up
> 300 orders of magnitude off, rather than the subtly wrong one from
> the error in the 7th decimal place.  

While I generally agree, I think it's an interesting way to test the
sensitivity of your algorithm/model/... to the errors in the intitial
conditions, and so on.

Of course, add sufficient amounts of salt before consumption.

> Or the corruption of adjacent memory locations.

That cannot happen in such cases.

> There are many errors caused by getting slopy about types.  I
> don't like things that encourage it.

Very much agreed.

	Jan

> The cause?  Fortran modules (good feature) do not separate interface from
> implementation (an incomprehensibly bad design, to any programmer with
> experience in anything else.)

Then go argue with Stroustrup and the C++ standards committee about their
incomprehensibly bad design of including implementation in the interface
definition. It is just the same latitude that the Fortran standard allows
Fortran processors with module files. 

If we're bitching about this issue, it should be more along the lines that
current compilers do not include, as far as I can tell, inlineable procedures
in their module files, as they should.

	Jan

> C was targeted at microprocessors and it was a remarkable thing:  a
> low-level language that could be used in a high-level way.  The
> semantic gap between the language and the hardware was small, and
> that is why experienced programmers can understand it.  

I'm sure you'd find a lot of people that would argue that BLISS was and
is even better in this respect, although it has some idiosyncrasies of its
own.

C winning the language evolution/war has little to do with the (de)merits
of C itself, but much more with its role as the Unix implementation language,
and of course with the peculiar role Unix played in the development of
computer "science"/engineering in a particular, formative period in the US.
Look at Betamax vs VHS and other similar technical examples.

	Jan

Jan C. Vorbr�ggen <jvorbrueggen@mediasec.de> writes:

>> Or the corruption of adjacent memory locations.
>
> That cannot happen in such cases.

Really?

I'm thinking of the situations where you end up writing 8 bytes
of data to a variable only sized as 4 bytes, thus corrupting
adjacent variables.  I don't recall all the details of Vax argument
passing, but there are almost bound to be some situations where
argument kind mismatches will do that.  One could make a system
where this would never happen, but I'd be surprised if the Vax
did that.

Concievably might only be an issue for arguments used for output,
which would just mean that the unsuspecting user gets pulled in
deeper before getting caught if he/she is used to the mismatch
working ok for input arguments.

Are you telling me that, if the dumy argument is, say a 2-byte
integer, that passing 1-byte, 2-byte, and 4-byte integer actual
arguments always works without corruption, both for input
and output?  How's it do that?  Copy-in/out?  That could be
made to work, I suppose, but I didn't think that tended to be
the way of things.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

In article <40169326.8F602EF8@mediasec.de>,
Jan C. Vorbr�ggen  <jvorbrueggen@mediasec.de> wrote:
>> The cause?  Fortran modules (good feature) do not separate interface from
>> implementation (an incomprehensibly bad design, to any programmer with
>> experience in anything else.)
>
>Then go argue with Stroustrup and the C++ standards committee about their
>incomprehensibly bad design of including implementation in the interface
>definition. It is just the same latitude that the Fortran standard allows
>Fortran processors with module files. 

TWWWWWWWWEEEET! 15 yard penalty for roughing the poster!

Flaws in other languages are no excuse for flaws in Fortran. Producing
a mechanism which is incompatible with make is inexcusable in any
modern language.

>If we're bitching about this issue, it should be more along the lines that
>current compilers do not include, as far as I can tell, inlineable procedures
>in their module files, as they should.

Why? Compilers which do inter-procedural analysis can usually inline
anything into anything, and don't *need* to stick anything extra in
the module file. If anyone produced a compiler which only did IPA for
things in module files, it would be a pretty poor IPA compared to one
that can inline anything into anything.

-- greg

Pierre Asselin wrote:
> ...
> I know I'm not making a good case, it's a bit frustrating.  I guess
> the big difference between Fortran and other compilable languages
> is that Fortran is truly a high-level language.  It leaves a lot
> of latitude to the implementation, including the latitude to optimize
> the sh*t out of the binaries.

Before C came along, Fortran was considered "portable assembler" for
many tasks.  Some of us still consider it that.

> ....    C was
> targeted at microprocessors...

Actually it was targeted at the PDP-11, which in 1971 was not a
microprocessor.

>  ...
> For whatever historical reasons, C is the portable language today,
> and Fortran just ain't.

Both Fortran and C can be very portable - IFF the application developer
WRITES TO THE STANDARD.  Most portability problems I've seen are because
either the developer was ignorant of the Standard, defiant to the Standard,
or no Standard even existed (e.g., C/C++ until very recently).

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

Pierre Asselin wrote:
> I know I'm not making a good case, it's a bit frustrating....

So why do you care?  Nobody here is telling you that you shouldn't
use whatever tools you find best for your applications, whether
that includes Fortran or not.  You don't really have to justify
to us that there is something uniquely peculiar about Fortran
in order for us to think it reasonable for you to use other tools.
I already think it reasonable...a lot more reasonable than the
attempts to overgeneralize.

> the big difference between Fortran and other compilable languages
> is that Fortran is truly a high-level language.

So are some others.  My viewpoint is more that C is the "peculiar"
one here, though in a way that can be useful.  I find C peculiar
in that it isn't a very high-level language, but more of a
semiportable assembler.  But then, that's just as broad a generalization
as the ones you have made.  Neither yours or mine are really
accurate.

> For whatever historical reasons, C is the portable language today,
> and Fortran just ain't.

Now that's just baloney.  As Walter said:

Walter Spector <w6ws_xthisoutx@earthlink.net> writes:

> Both Fortran and C can be very portable...

We could trade all variants of portable/nonportable C/Fortran.
Many examples of all 4 combinations exist.  I won't bother.

This thread doesn't seem to be getting any more useful.  Though
it is staying polite, it isn't being constructive.  I'm going
to stick with my position that all the statements about one
language being inherently better/worse/peculiar/whatever
compared to all other languages are just unjustified generalizations.
I haven't seen anything close to a justification here and I don't
expect to because I don't think they exist.

Go ahead and use whatever you think appropriate - just don't think
that you have to find global justifications for your choice as
abstract properties of the language.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Jan C. Vorbr�ggen wrote:

>>It has been too long since I looked at VMS.  If the string "ABCDEFGH"
>>is stored in memory with "H" at the smallest address and "A" at the
>>highest address, then that's consistent with little-endian.  An eight
>>byte integer would similarly have the highest address correspond to
>>the most significant base-256 digit of the number.  Etc.  If that's
>>what VMS does, then it's consistent.

> It does the latter, but not the former. I've never heard the suggestion
> to store strings differently also. The usual argument about sorting or
> searching them doesn't apply in practice - because of collating order
> for one, multi-byte "characters" for a second, and thirdly because the
> actual algorithms don't care about the byte order.

It is common to alphabetize words with the first (leftmost) letter
most significant.  As more words have suffixes than prefixes, this
is most convenient for users.  It would be possible to write
dictionaries alphabetized based on the last letter, but people would
find it strange.  (Except possibly for crossword puzzle or scrabble
players.)

If character strings are stored in the same way as integers, you can
use integer instructions when sorting, which are often faster than
string compare instructions.

> For the numerical side, it leads to the side-effect that you can "safely"
> pass a smaller integer as an actual argument to a larger integer dummy
> argument, an a single-precision fp to a double-precision dummy. This bad
> practice of course breaks on big-endian systems.

I gave this reason previously in favor of big-endian.  It can cause
programs to seem to work correctly during debugging, and then fail
spectacularly during use.  Note that you can't pass a small integer
where a large integer is expected, as garbage will be stored in
the high order bits.  Those bits will be overwritten if the argument
is modified.   You can pass a large integer where a small
integer is expected, though.

(Well, there may have been systems with two and four byte integers
that only did two byte arithmetic even on four byte integers.)

On systems, such as S/360, where all indirect addresses contain a
displacement field the only savings is in computing the displacement.

-- glen

James Giles wrote:

(snip regarding big and little endian storage)

> Breaks anyway for modern floating point.  The number of bits devoted to
> the exponent parts vary between single and double.

The IBM hexadecimal based floating point, which still exists on new 
processors in addition to IEEE formats, uses a seven bit base 16
exponent for 32, 64, and 128 bit formats.   It is fairly readable
in a hex dump, as the hexadecimal point will align with the hex
digits in the dump.   Also, they are big endian.

-- glen

Catherine Rees Lay <spamtrap@polyhedron.org.uk> wrote:

>In article <7kia10lckagi2r7lfgloc7sc7plma2m7ik@4ax.com>, Michael Prager 

>>>But professional programmers generally have a whole set of concerns
>>>that amateur programmers need never consider.
>>>Not only must their code be correct and run fast and efficiently
>>>but it must also be usable by people who are not themselves programmers.
>>>It must be thoroughly tested and debugged before it is released for use.
>>
>>Strongly disagree with this slant.  I find no increase in
>>quality of software written by "professionals" above that
>>written by "amateurs."  Often, the latter produce more reliable
>>software, if usually for simpler tasks.
>>
>I think you missed the point, which wasn't about quality. If you're an 
>"amateur" writing software for your own use, you can debug it using the 
>actual data you are interested in, and use tested parts for real 
>calculations before other parts are fully tested, because you know which 
>they are. 
[snip]
>just a different way of working which is required for "professionals" 
>(where, like the OP, I'm using "professional" for those of us for whom 
>the end product is the program, and "amateur" for those for whom it's 
>the program's results, either of which may, but don't necessarily, imply 
>"done on our own time").

What I missed was the bizarre definition of "amateur" and
"professional."  I was using them in the customary sense, and
not to distinguish code written for a one-off task and code
written for reuse.


-- 
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

Richard Maine wrote:
(snip regarding portability and high/low level languages)

> So are some others.  My viewpoint is more that C is the "peculiar"
> one here, though in a way that can be useful.  I find C peculiar
> in that it isn't a very high-level language, but more of a
> semiportable assembler.  But then, that's just as broad a generalization
> as the ones you have made.  Neither yours or mine are really
> accurate.

Well, C more closely matches some low level machine characteristics.
I would much rather write bitmap graphics programs in C, for example.
Operating systems, compilers, device drivers, interrupt routines,
data compression programs, I believe are all easier to write in C.

I do know of one Fortran compiler (mostly) written in Fortran, but
that was written before C existed.

>>For whatever historical reasons, C is the portable language today,
>>and Fortran just ain't.

For number crunching, Fortran is probably about as portable, though
maybe a little more, than C.

Note, though, that some of the reason C is more portable is because
it has machine dependent construct, such as preprocessor macros
and typedef types that vary depending on the machine.  Well understood
systems for writing code that varies such characteristics between
machines, and programs actually keeping track of the sizeof() various
data structures.

Numerical programs may be dependent on the precision of the floating
point implementation, but normally not much else.

-- glen

In article <lgzRb.129179$5V2.657821@attbi_s53>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:

>Note, though, that some of the reason C is more portable is because
>it has machine dependent construct, such as preprocessor macros
>and typedef types that vary depending on the machine.  Well understood
>systems for writing code that varies such characteristics between
>machines, and programs actually keeping track of the sizeof() various
>data structures.

Many large F77 codes also use preprocessor macros, etc, to solve
interesting portability problems, and of course F90 has a buch of
features along those lines directly in the language. If you're going
to comment about how languages are used in practice, you ought to be
aware how they are actually used in practice. Or were you no longer
talking about anything relevant to this newsgroup?

-- greg

"Pierre Asselin" wrote

> Maybe the way of the future is to write only number-crunching
> routines in Fortran and accept that applications will always be
> written in some other language, relegating Fortran to a niche in
> libraries.

What's wrong with that?  Then fortran can be optimized for number crunching,
which is always going to be a niche, and won't require all the baggage of a
general-purpose programming language.

"Charles Russell" <STOPworworSPAM@bellsouth.net> writes:

> "Pierre Asselin" wrote
>
>> Maybe the way of the future is to write only number-crunching
>> routines in Fortran and accept that applications will always be
>> written in some other language, relegating Fortran to a niche in
>> libraries.
>
> What's wrong with that?  Then fortran can be optimized for number crunching,
> which is always going to be a niche, and won't require all the baggage of a
> general-purpose programming language.

Nothing is "wrong" with it.

Well, there is the problem that it isn't that clean to separate
number-crunching from other things.  F77 added character type because
just pages filled with numbers weren't good enough any more and
Hollerith mad doing a good job of character data too hard.  Most of my
personal number crunching apps have many times more lines of code
devoted to things like text manipulation than to actually crunching
the numbers.  It doesn't take much research to discover that my
situation is the norm today.

Yes, one can sometimes interface between multiple languages.  I do.
That does bring its own set of complications.  Plus, at times the
strict division doesn't work and you discover that there are parts
of the code too closely coupled for that to work well.

But in the end, the only thing "wrong" with it is that it just isn't
going to happen.  That's because there are people (me for one) who
want to do other things with the language.  You telling them that they
shouldn't do that isn't going to convince them; it sure doesn't
convince me.  There are enough of them to generate a viable
market that vendors are selling for.  And that's the real answer.

There is nothing "wrong" with asking for a language that has
absolutely nothing but number-crunching stuff in it.  You can
even ask for character type to be removed.  But I don't think you
are going to find the support to make it happen (even if you
leave character in).  I sure won't support it.

That doesn't mean it is "wrong".  I just don't think it has
measurable odds of happening because there isn't the market there
to support it.  Feel free to prove me wrong.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Greg Lindahl wrote:

> In article <lgzRb.129179$5V2.657821@attbi_s53>,
> glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:

> Many large F77 codes also use preprocessor macros, etc, to solve
> interesting portability problems, and of course F90 has a buch of
> features along those lines directly in the language. If you're going
> to comment about how languages are used in practice, you ought to be
> aware how they are actually used in practice. Or were you no longer
> talking about anything relevant to this newsgroup?

Well, it is probably more relevant to a C newsgroup, though it
wasn't posted there.

People write operating systems in C, and then use the preprocessor
to fix machine dependency problems.   If people don't write OS
in Fortran, then there is no need to fix those types of problems.

There could even be completely different code for different
systems, surrounded by #ifdef and #endif.   The result is then
called portable, even though it is completely different code
for different machines.

Have any Fortran compilers been written in Fortran in the last
20 years?  (That is a question, I don't know the answer.)

I know more about current practice in C than Fortran, but
that is mostly because of the types of programs tend to be
written in C.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Have any Fortran compilers been written in Fortran in the last
> 20 years?  (That is a question, I don't know the answer.)

I've been tempted.  With f90 or later it ought to be reasonably
doable.  But I already have a day job and writing a compiler
is pretty big for even a full time task, much less a hobby.

Maybe after I retire.  But odds are I'll find other things that
seem a better use of my time even then.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

glen herrmannsfeldt wrote:
....
> Well, C more closely matches some low level machine characteristics.
> I would much rather write bitmap graphics programs in C, for example.
> Operating systems, compilers, device drivers, interrupt routines,
> data compression programs, I believe are all easier to write in C.

C is actually very bad at those.  Such programs should be among the
most reliable software in the programming environment and C encourages
the production of unreliable code.  These problems are inherent to
C's design and have nothing to do with any comparison to another
language.

For example, even in system programming, it is seldom needed or
desirable to deal with raw pointers to anything.  Even within the
part of the system that manages and schedules the use of memory,
the need for raw pointers is narrow and readily isolated to a
small, carefully managed portion of the code.

Yes, Fortran was not designed to do such things.  Still, the basic
structure of Fortran (or Pascal, or Ada, ...) are better suited to the
tasks provided you include the features needed.  For such things,
the ability to deal with bit-resolution fields in structures is one
of the important features.  And yes, the occasional raw pointer.

-- 
J. Giles

In article <8uARb.127091$Rc4.982803@attbi_s54>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:

>People write operating systems in C, and then use the preprocessor
>to fix machine dependency problems.   If people don't write OS
>in Fortran, then there is no need to fix those types of problems.

Ah. So even if people, in practice, do use preprocessors with Fortran
to fix machine dependency problems in numerical programs, they don't
exist? *poof*? Kind of like Oliver Wendell Jones erasing his dad?

-- greg

Richard Maine wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>
>> Have any Fortran compilers been written in Fortran in the last
>> 20 years?  (That is a question, I don't know the answer.)
>
> I've been tempted.  With f90 or later it ought to be reasonably
> doable.  But I already have a day job and writing a compiler
> is pretty big for even a full time task, much less a hobby.
>
> Maybe after I retire.  But odds are I'll find other things that
> seem a better use of my time even then.

I've written a lot of preprocessors in Fortran.  The text manipulation
is more efficient and easier to use.  And, for preprocessors, I don't
need features lower-level than text manipulation.  For a compiler,
I'd really want bit-resolution integer KINDs, and a few other things.
I've maintained compilers and other software in both C and Fortran-like
languages.  Given the proper additional features, Fortran is better.

-- 
J. Giles

"James Giles" <jamesgiles@worldnet.att.net> writes:

> Richard Maine wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>
>>> Have any Fortran compilers been written in Fortran in the last
>>> 20 years?  (That is a question, I don't know the answer.)
>>
>> I've been tempted....
>
> I've written a lot of preprocessors in Fortran....

Yes.  Me too.  Dating from back in f66 days when I wrote my own
trivial include processor so that I'd have it wherever I went.  (In
those days, you couldn't assume there would be one or that you could
just pick up one off the "net").

A year or so ago, I needed a preprocessor to fix up a bunch of Fortran
code that used some nonstandard initialization syntax that didn't work
with the compiler I was using.

The nonstandard syntax had no functional reason - just pointlessly
nonstandard.  Of course, every procedure had a comment claiming to
conform to the Fortran standard, but I've mentioned that here before
(obviously there was a bureaucratic requirement that they have such
a comment, but no requirement that it actually be true).

I needed it to be automated so that the same fix could be easily done
if we got a revised version.  Thousands of lines of code with changes,
and the odds of getting the fixes ported back to the original code
were about zero.

Figuring that this sounded like the kind of text processing that
Perl was supposed to be good at, I went to a friend that I knew had
done a fair amount of Perl.  I've done a little Perl, but
not enough to call myself even up to the novice level.  The friend
had a Perl script for another Fortran source code conversion and
thought I could adapt that.  I looked at his Perl script and
realized that, heck, this wasn't that different in structure
from the way I'd write it in Fortran (with the aid of my usual
library of string processing procedures).

So I did it in Fortran.  Not because Fortran was necessarily better,
but because it didn't look substantially worse and, factoring in
my learning time, it was going to take me a lot less time to write
it from scratch in Fortran than to modify the Perl script.  (It
wasn't exactly a major job - 85 lines of code including comments
but excluding the library that was already written).

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

In article <oXxRb.128924$sv6.686944@attbi_s52>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>[snip]  It would be possible to write
>dictionaries alphabetized based on the last letter, but people would
>find it strange.  (Except possibly for crossword puzzle or scrabble
>players.)

My dictionary of that kind (sorry I can't quote author & title as it's
at home) is called a rhyming dictionary; I suspect its author was in 
the pre-crossword and pre-scrabble era; he thought he was writing it 
for poets. (At the end there's a long list of all the possible 
different ways to spell each sound in English)

John Harper, School of Mathematical and Computing Sciences, 
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

In article <slrn-0.9.7.4-7286-23602-200401271240-tc@hexane.ssi.swin.edu.au>,
>
>I only have the Intel compiler to go on here, so maybe not a good
>sample to draw on.
>
>But the non-advancing IO is no good there. For writing, it doesn't
>actually output to the terminal until a non-IO advancing IO write is
>performed. 

Isn't that what FLUSH in F2003 is for? If so we only have to wait a 
small number of years.


John Harper, School of Mathematical and Computing Sciences, 
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

Richard Maine wrote:
....
> So I did it in Fortran.  Not because Fortran was necessarily better,
> but because it didn't look substantially worse and, factoring in
> my learning time, it was going to take me a lot less time to write
> it from scratch in Fortran than to modify the Perl script.  (It
> wasn't exactly a major job - 85 lines of code including comments
> but excluding the library that was already written).

With one additional advantage (which maybe is not relevant
in the case you are describing) that the preprocessor will work
everywhere you port.  You wouldn't be using it anywhere that
doesn't have a Fortran implementation because it's generating
Fortran.  You might be using it somewhere that doesn't have
Perl.

-- 
J. Giles

harper@mcs.vuw.ac.nz (John Harper) writes:

> In article <slrn-0.9.7.4-7286-23602-200401271240-tc@hexane.ssi.swin.edu.au>,
>>
>>I only have the Intel compiler to go on here, so maybe not a good
>>sample to draw on.
>>
>>But the non-advancing IO is no good there. For writing, it doesn't
>>actually output to the terminal until a non-IO advancing IO write is
>>performed. 
>
> Isn't that what FLUSH in F2003 is for? If so we only have to wait a 
> small number of years.

Flush isn't guaranteed to do anything.  It standardizes the syntax
of requesting the compiler to do it, but its doesn't mandate that
the capability exist.  Turns into a quality of implementation
issue as to whether it actually does anything.

but then, as mentioned before in this thread, the standard already
explicitly recommends that nonadvancing I/O be implemented in a way
usable for prompting.

I don't see any fundamental difference here.  In both cases, it is up
to the compiler whether to actually implement it or not.  I'd say that
time and user pressure is likely to be a bigger factor in this than
the FLUSH statement of f2003.  Bitch at Intel if you don't think they
don't do it well (and you use their compiler).  I haven't actually
verified this behavior btw; I'm just going by comments posted here.
Don't just assume that because F2003 has FLUSH, things will
automatically change.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

"Richard Maine"  wrote

>  Most of my
> personal number crunching apps have many times more lines of code
> devoted to things like text manipulation than to actually crunching
> the numbers.

Back when I was using Fortran IV ( Hollerith strings) I complained to a real
programmer that I hated I/O.  He said I was in a tough spot since most code
was over half  I/O.  I took that as a personal challenge, and while I never
developed a style as clean as the SLATEC library, I have very little I/O.
(Now mostly list-directed.  I use format statements only when needed to
squeeze a lot of columns into a table.)  All I want in fortran is the
ability to read a data file and write an output file.

For text manipulation I prefer to use unix filters, which have high-level
operators for just that.  Sort of like the math libraries I use for number
crunching.

For anything else I use C.  (Getting data from a binary file into a fortran
array, or writing simple utilities. But I seldom need to do this.)

Richard Maine wrote:
> 
> Jan C. Vorbr�ggen <jvorbrueggen@mediasec.de> writes:
> 
> >> Or the corruption of adjacent memory locations.
> >
> > That cannot happen in such cases.
> 
> Really?
> 
> I'm thinking of the situations where you end up writing 8 bytes
> of data to a variable only sized as 4 bytes, thus corrupting
> adjacent variables.  I don't recall all the details of Vax argument
> passing, but there are almost bound to be some situations where
> argument kind mismatches will do that.  One could make a system
> where this would never happen, but I'd be surprised if the Vax
> did that.
> 
> Concievably might only be an issue for arguments used for output,
> which would just mean that the unsuspecting user gets pulled in
> deeper before getting caught if he/she is used to the mismatch
> working ok for input arguments.
> 
> Are you telling me that, if the dumy argument is, say a 2-byte
> integer, that passing 1-byte, 2-byte, and 4-byte integer actual
> arguments always works without corruption, both for input
> and output?  How's it do that?  Copy-in/out?  That could be
> made to work, I suppose, but I didn't think that tended to be
> the way of things.

I think the only cases he actually spoke of were for shorter actual
arguments than dummies, Richard.  I no longer remember enough of my VAX
time to have any clear recollection of what happened if you made the
mistake the other way.

John Harper wrote:
> 
> Isn't that what FLUSH in F2003 is for? If so we only have to wait a
> small number of years.

No need to wait, contact http://openwatcom.org, order the CD for $25,
and start flushing in a few days.

TimC wrote:
> 
> Until F2003, can't portably interoperate with C.

Probably a good thing too, until you answer a more pertinent question:
Can C (today) interoperate with itself (yesterdays)!?

btw, Fortran does extremely well in this regard; check the stats at
http://netlib.org/utk/misc/counts.html

Pierre Asselin wrote:
> 
> the "recompilation cascade".  The cause?  Fortran modules (good
> feature) do not separate interface from implementation (an
> incomprehensibly bad design, to any programmer with experience in
> anything else.)

What can I say, it's one of many (not so) fine points that a misguided
committee apparently missed in the ADA design scrap notes.

bv wrote:

> Pierre Asselin wrote:
> 
>>the "recompilation cascade".  The cause?  Fortran modules
>>(good feature) do not separate interface from implementation
>>(an incomprehensibly bad design,
>>  to any programmer with experience in anything else.)

Nonsense!
It is up to the programmer to separate interface from implementation
and both C++ and Fortran 90 allow for this.
Placing function and subroutine definitions in the module
facilitates inlining and provides more opportunities for optimization.

> What can I say, it's one of many (not so) fine points that a misguided
> committee apparently missed in the ADA design scrap notes.

You missed the point.
Separation of interface and implementation
is good for program development and maintenance
but it can easily become a performance killer.

Take a look at Todd Veldhuizen's Blitz++ package

	http://www.oonumerics.org/blitz/

Because virtually all of the code is C++ inline template classes,
It requires a long time to [re]compile
but the performance of the code emitted compares favorably
with the code emitted by the best Fortran 90 compilers.

In general,
you will need to recompile your code (Fortran 90 or whatever)
each time that you make changes in order to get the best performance.

Pierre Asselin wrote:
> 
> Arjen Markus <arjen.markus@wldelft.nl> wrote:
> 
> > [ snip ]
> > One practical problem that [in C] arose the other day:
> 
> > double x ;
> > fprintf( outfile, "%f\n", x ) ; /* Works without a problem */
> > fscanf( infile, "%f", &x ) ; /* Causes a problem */
> 
> > Can you spot why?
> 
> Er, yes, your fscanf() call has the wrong format.  I agree that it's a
> famous trap of C, but this is *not* a portability problem.  We're
> drifting off-topic.

Well, the effect is - but you are right, I later realised it is a 
very general trap in C. 

Regards,

Arjen

Bob Lidral wrote:
> 

> It's certainly possible to write portable code in C and, once over the
> learning curve, even easier in C++.  Since the Fortran 77 standard, it
> has even been possible to write portable code in Fortran.
> 
> If you're seeing a difference in portability between Fortran and C code,
> there's a good chance that's the result of differences in age.  Old
> Fortran programs that have been ported to several different platforms
> for 20 or 30 years may have had all of the non-portable code removed or
> made portable.  Wait until the C programs are 20 or 30 years old and
> have been ported to and used on as many different platforms before
> commenting on comparative portability.
> 

But many of the UNIX utilities _are_ in fact 20 or 30 years old.
So, with these in hand, one could answer that question.

Regards,

Arjen

Greg Lindahl wrote:
> 
> In article <4014D1B0.E9A1824C@wldelft.nl>,
> Arjen Markus  <arjen.markus@wldelft.nl> wrote:
> 
> >One practical problem that arose the other day:
> >
> >double x ;
> >fprintf( outfile, "%f\n", x ) ; /* Works without a problem */
> >
> >fscanf( infile, "%f", &x ) ; /* Causes a problem */
> >
> >Can you spot why?
> 
> This is a quality of implementation issue:
> 
> foo.c:6: warning: float format, double arg (arg 3)
> 
> Get a better compiler. Fortran has many similar issues.
> 
> -- greg

Yes, it was the wrong example. I mentioned it, because
it was foremost on my mind ;). I could look up the
general aspect of the C language responsible for this,
not in conjunction with fscanf() but with the promotion
of floats to doubles in a completely unrelated section
of the K&R book. 

Regards,

Arjen

In article <m3n089rt13.fsf@altair.dfrc.nasa.gov>, Richard Maine 
<nospam@see.signature> writes
>glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>
>> Have any Fortran compilers been written in Fortran in the last
>> 20 years?  (That is a question, I don't know the answer.)
>
>I've been tempted.  With f90 or later it ought to be reasonably
>doable.  But I already have a day job and writing a compiler
>is pretty big for even a full time task, much less a hobby.
>
>Maybe after I retire.  But odds are I'll find other things that
>seem a better use of my time even then.
>
I have been told that Salford's ftn77 was/is written and developed using 
itself. I don't know if this was exclusively, mostly or only some of it. 
Original version may have been more than 20 years ago, certainly it was 
still being upgraded much less than 10 years ago.

Catherine.
-- 
Catherine Rees Lay
To email me, use my first name in front of the "at".

> I think the only cases he actually spoke of were for shorter actual
> arguments than dummies, Richard.  

Yes, that was what I was thinking about.

> I no longer remember enough of my VAX time to have any clear recollection
> of what happened if you made the mistake the other way.

The argument list usually contained a list of addresses to the actual
arguments (no register-based argument passing), unless you explicitly
passed an argument by value. When you then overwrote with a larger-sized
item, the usual unpredictable stuff would occur - unless it was a constant
argument, in which case you trigger an access violation.

	Jan

> If character strings are stored in the same way as integers, you can
> use integer instructions when sorting, which are often faster than
> string compare instructions.

That's why I wrote

> > and thirdly because the actual algorithms don't care about the byte order.

	Jan

> Flaws in other languages are no excuse for flaws in Fortran. 

The sarcasm should have shown you that I don't consider it a flaw. If
at all, the flaw is in the concept of seperate compilation - and without
that, one wouldn't need module files anyway.

> Producing a mechanism which is incompatible with make is inexcusable 
> in any modern language.

Make is a crutch, pure and simple, for ill-designed development systems.
There are much better solutions around, but as usual with Unix-derived
crap, it won out.

> Why? Compilers which do inter-procedural analysis can usually inline
> anything into anything, and don't *need* to stick anything extra in
> the module file.

There's again that issue of seperate compilation. And, in this case, of
using pre-packaged libraries of which source isn't available. It is 
precisely this issue the implementation part inside a C++ header file 
is addressing, and for which the module files need to contain much than
just a representation of the interfaces.

	Jan

> I do know of one Fortran compiler (mostly) written in Fortran, but
> that was written before C existed.

Then I know of at least one more that definitely existed after C came
into being - mid-to-late 80s - and it even had a substantial market
share, being supplied by that quintessential three-letter company.

	Jan

> > I've written a lot of preprocessors in Fortran....
> Yes.  Me too.  Dating from back in f66 days when I wrote my own
> trivial include processor so that I'd have it wherever I went.  (In
> those days, you couldn't assume there would be one or that you could
> just pick up one off the "net").

....or that monster called YPATCHY, developed at CERN, that did a lot more
- in part, it also was a change-management and revision-control system,
with conflict resolution and all that. Started off in some form of pre-F77
Fortran, and available on any machine a high-energy physicist would consider
using - i.e., anything on the market.

	Jan

> > Have any Fortran compilers been written in Fortran in the last
> > 20 years?  (That is a question, I don't know the answer.)

Yes, as I've mentioned in another follow-up.

> I've been tempted.  With f90 or later it ought to be reasonably doable. 

That one was a F77 compiler, and AFAIK it compiled itself.

	Jan

> Most of my personal number crunching apps have many times more lines
> of code devoted to things like text manipulation than to actually
> crunching the numbers. 

....and that doesn't include all the code in, for instance, Tcl/Tk you
are making use of to display the results, control a run, etc. 

I'd guesstimate that maybe 1% or so of all code in a large simulation is
in the model code, the rest is HMI. That's why people like MATLAB, IDL,
and company - they come with those 99% in ready-to-use form, so you can
concentrate on the "real" work.

	Jan

Jan C. Vorbr?ggen <jvorbrueggen@mediasec.de> wrote:
> > The cause?  Fortran modules (good feature) do not separate interface from
> > implementation (an incomprehensibly bad design, to any programmer with
> > experience in anything else.)

> Then go argue with Stroustrup and the C++ standards committee about their
> incomprehensibly bad design of including implementation in the interface
> definition. It is just the same latitude that the Fortran standard allows
> Fortran processors with module files. 

Look, I'm not saying we should take the kitchen sink out of C++, fill
it with scrap metal and stuff the lot into Fortran.  How about
stealing just the good ideas?


> If we're bitching about this issue, it should be more along the lines that
> current compilers do not include, as far as I can tell, inlineable procedures
> in their module files, as they should.

I don't have a problem with precompiled inline procedures (thunks?).
I do have a problem with interface specs not separated from
implementation *because it screws up code development and
maintenance*.  The recompilation cascade is just a symptom.

I see from other posts that Jan opposes separate compilation.  Is that
a widely held position among vendors?

-- 
pa at panix dot com

Richard Maine <nospam@see.signature> wrote:
> Pierre Asselin wrote:
> > I know I'm not making a good case, it's a bit frustrating....

> So why do you care?  Nobody here is telling you that you shouldn't
> use whatever tools you find best for your applications, whether
> that includes Fortran or not.

I know, it not that big a deal.  I have to use Fortran because that's
what the rest of the team knows.  We do number crunching so it should
be a slam-dunk, right?  Well, it's not a slam-dunk.  I'm just trying
to tell the c.l.f community that something's wrong.  I can't pin it
down, but I know something is wrong.

All right, here's another tack.  If a bright student contemplating
a scientific career with lots of numerical analysis asked you for
advice on what language to learn, what yould you say?  Fortran?

Why learn Fortran?  because the compilers optimize better and the
binaries scream.  However, in today's world the kid *will* have to
learn another language to do a good job.

Now Robert Tisdale tells us that Blitz++ also screams
(http://www.oonumerics.org/blitz/).  Writing (or reading) C++
templates is, shall we say, challenging, but using them is not
going to be that hard.  If Blitz++ works, Fortran loses the one
advantage it has over, oh, C++.  If C++ can do do the deep number
crunching, but also plug right into a portable GUI with OpenGL
support (http://www.fltk.org/), make any OS calls needed (extern
"C"), handle platform idiosyncracies (judicious #ifdef), interface
to scripting languages (extern "C" + swig) and make you more
employable, what is the point of learning Fortran?

Bah, now I'm starting an advocacy thread.  To the newsgroup:  downplay
the advocacy, but:  aren't you worried?

--
pa at panix dot com

Jan C. Vorbr�ggen <jvorbrueggen@mediasec.de> writes:

>> I think the only cases he actually spoke of were for shorter actual
>> arguments than dummies, Richard.  
>
> Yes, that was what I was thinking about.

Then I'd think you would overwrite the memory after the actual when you
had an output one.

But I wasn't bothering to work out exactly which case caused which
class of error - just that there were errors of this nature inherent
in the scheme.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Arjen Markus wrote:

> Bob Lidral wrote:
> >
>
> > It's certainly possible to write portable code in C and, once over the
> > learning curve, even easier in C++.  Since the Fortran 77 standard, it
> > has even been possible to write portable code in Fortran.
> >
> > If you're seeing a difference in portability between Fortran and C code,
> > there's a good chance that's the result of differences in age.  Old
> > Fortran programs that have been ported to several different platforms
> > for 20 or 30 years may have had all of the non-portable code removed or
> > made portable.  Wait until the C programs are 20 or 30 years old and
> > have been ported to and used on as many different platforms before
> > commenting on comparative portability.
> >
>
> But many of the UNIX utilities _are_ in fact 20 or 30 years old.
> So, with these in hand, one could answer that question.

Yes, but ...

Guess I left myself somewhat open for that one, sort ot.

I don't happen to have any statistics on the portability of UNIX
utilities written in C vs. the portability of those same or similar UNIX
utilities written in Fortran :-).  It's entirely possible those UNIX
utilities written in C _are_ as portable as (or more so than) various
20- or 30-year-old Fortran programs that have been ported a lot; I just
don't have the data.  OTOH, I _have_ written portable code in C and have
read portable C code written by others so I know it's possible.  I guess
I should have specified comparing code written in the two languages that
performs similar tasks -- that would have been more relevant.  Oh, well
-- guess I'll have to learn to be more precise.

You may note that earlier in my quoted post, I wrote:

> Portability, for programs written in any language, depends on four
> things:
>
>   1. characteristics of the task,
>   2. suitability of the programming language to the task,
>
and

> Compilers are good examples of tasks with characteristics that preclude
> portability.
>

Operating systems are also good examples of such tasks.  It is perhaps
interesting that Unix and Linux each run on more different platforms
than any operating system written in Fortran of which I'm aware.  (Not
sure whether that's a tribute to the portability of C or to the loyalty
of the UNIX and Linux communities or to the intensity of general desire
to escape from Windows. :-))  Feel free to provide counterexamples :-).

I'd better quit before I feed a comparative language or comparative
operating system flame war.


Bob Lidral
l i d r a l  at  a l u m  dot  m i t  dot  e d u

"Arjen Markus" wrote

..  Wait until the C programs are 20 or 30 years old and
> > have been ported to and used on as many different platforms before
> > commenting on comparative portability.
> >
>
> But many of the UNIX utilities _are_ in fact 20 or 30 years old.
> So, with these in hand, one could answer that question.

But were they ported without having to modify the source code, as would be
common for fortran?  Even simple unix utilities are usually too full of
system calls to port easily between different operating systems, e.g. unix
and MS-DOS.

> Look, I'm not saying we should take the kitchen sink out of C++, fill
> it with scrap metal and stuff the lot into Fortran.  How about
> stealing just the good ideas?

You were proposing the C/C++ mechanism for seperating interface from 
implementation. I pointed out that at least the C++ mechanism does not
do that, and for exactly the same reason Fortran module files do not do
that.

> I see from other posts that Jan opposes separate compilation. 

I'm not sure I unequivocally oppose seperate compilation. But it has
a lot of consequences, some of which have been mentioned here, and it
is an engineering tradeoff of whether you want this or one of the 
alternative solutions. But it should be a concious decision, not just
dogma.

	Jan

In article <bv8iis$8bm$1@reader2.panix.com>,
Pierre Asselin <pa@see.signature.invalid> wrote:

>All right, here's another tack.  If a bright student contemplating
>a scientific career with lots of numerical analysis asked you for
>advice on what language to learn, what yould you say?  Fortran?

I'd say "learn several". The only reason this kind of situation is
hard is when you want to recommend only one language. But even though
I prefer reverse-polish calculators, I still know how to use algebraic
calculators.

>Bah, now I'm starting an advocacy thread.  To the newsgroup:  downplay
>the advocacy, but:  aren't you worried?

See the archive for many examples of this thread -- why do you think
it's a new idea? Normally it generates a lot more heat than light.

-- greg

Jan C. Vorbr�ggen wrote:

>>I do know of one Fortran compiler (mostly) written in Fortran, but
>>that was written before C existed.

> Then I know of at least one more that definitely existed after C came
> into being - mid-to-late 80s - and it even had a substantial market
> share, being supplied by that quintessential three-letter company.

Well, the Fortran H and H extended compilers are some Fortran and
some assembler, I don't know the fractions of each.

I don't know so much about VS Fortran, though.

-- glen

lindahl@pbm.com (Greg Lindahl) writes:

> In article <bv8iis$8bm$1@reader2.panix.com>,
> Pierre Asselin <pa@see.signature.invalid> wrote:
>
>>All right, here's another tack.  If a bright student contemplating
>>a scientific career with lots of numerical analysis asked you for
>>advice on what language to learn, what yould you say?  Fortran?
>
> I'd say "learn several".

Me too.  Oh, and tell them to learn several human languages while
on the subject, partly for the same reasons.  (no :-))

And yes, if they have to learn one, after discouraging them from
that limitation, I'd say Fortran.  My biggest reason isn't any of
the ones you mentioned.  More exactly the opposite of your apparent
viewpoint.  I'd say to learn Fortran because I think it is easier
and more natural; it is for me.

(Of course, this doesn't mean I think Fortran is perfect and has
everything right either; that would be a very different question.)

I'm aware that you don't agree with me on this.  I'm also aware that
you aren't alone.  Neither am I.  I'll not try to convince you that
I'm right.  That way lies pointless flame wars.  I only hope that you
realize that different people do see it differently and that this
doesn't mean any of them are wrong.

It is one of those unanswerable "religious" questions.  There doesn't
exist a single right answer for everyone.  If you think that there is
always a right answer to that, then you've made the most critical
mistake already.  That part I am adamant on.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

In article <m3smhzkfob.fsf@altair.dfrc.nasa.gov>,
Richard Maine  <nospam@see.signature> wrote:

>> I'd say "learn several".
[...]
>And yes, if they have to learn one, after discouraging them from
>that limitation, I'd say Fortran.  My biggest reason isn't any of
>the ones you mentioned.  More exactly the opposite of your apparent
>viewpoint.  I'd say to learn Fortran because I think it is easier
>and more natural; it is for me.

I don't think you understood my viewpoint. I'd refuse to answer if
they only want one, because that's only the right answer if wherever
they're working is a religious center for exactly one language. The
typical situation today is going to be a mix of Fortran (may be all
77, might be mixed 77/90) and C (may be some C++) and often something
additional related to interactive graphics (IDL/PV-Wave, matlab,
mongo, insert a zillion possibilities here.)

I'd agree (with your religious take) that for the average scientific
programmer, learning Fortran isn't going to be so bad. My experience
is that it takes a long time to correctly understand C/C++ pointers,
and that issue simply doesn't arise in Fortran. Insomuch as I complain
about things that I don't like in F90, I'm complaining about features
that I think make F90 harder to learn, or features that people think
should always be used, when sometimes they're just broken (array
syntax vs. do loops).

-- greg

Bob Lidral wrote:
....
> Operating systems are also good examples of such tasks.  It is perhaps
> interesting that Unix and Linux each run on more different platforms
> than any operating system written in Fortran of which I'm aware.  (Not
> sure whether that's a tribute to the portability of C or to the loyalty
> of the UNIX and Linux communities or to the intensity of general desire
> to escape from Windows. :-))  Feel free to provide counterexamples :-).

Well, Windows is written in C++ (a decision that no less than Bill
Gates himself has characterized as the single worst technical decision
the company ever made).  The problem is that I don't see much
difference in fklavor between UNIX and Windows.  Both are
bloated, arcane, insecure, unreliable, slow, and hard to learn.
If windows out-bloats or out-arcanes UNIX it also outnumbers
it.  Neither is as good as alternatives that used to exist before
those two took over the world.  People working on genuinely
secure systems have already made it clear that it can't be done
campatibly with either UNIX or Windows - those systems carry
their security flaws with their specifications, not just from
weaknesses in their implementations.

As I've pointed out, I believe much of the lack of reliability of
systems is directly tracable to C: a large percentage of bug in
modern systems still turns out to be buffer overruns.  C also
tend to require more lines of code to do similar tasks than other
languages - hence one of the causes of bloat.  C is not a very
good choice as a system development language.  Many Pascal
extensions used experimentally in the 70's would have been
better choices.

Comparing C to Fortran for system development (or compilers)
is a little unfair since Fortran was not designed for such things
and even long-time proponents don't claim that it's adequate
for such activities without extensions.  Still, system-level
code would probebly be smaller, clearer, and less buggy in
a properly extended Fortran.

-- 
J. Giles

In article <qDXRb.29839$6O4.785341@bgtnsc04-news.ops.worldnet.att.net>,
James Giles <jamesgiles@worldnet.att.net> wrote:

> The problem is that I don't see much
> difference in fklavor between UNIX and Windows.

I suspect there would be wide agreement with this point, but not in
the sense that you meant.

-- g

glen herrmannsfeldt wrote:
> =

> Jan C. Vorbr=FCggen wrote:
> =

> >>I do know of one Fortran compiler (mostly) written in Fortran, but
> >>that was written before C existed.
> =

> > Then I know of at least one more that definitely existed after C came=

> > into being - mid-to-late 80s - and it even had a substantial market
> > share, being supplied by that quintessential three-letter company.
> =

> Well, the Fortran H and H extended compilers are some Fortran and
> some assembler, I don't know the fractions of each.
> =

> I don't know so much about VS Fortran, though.

Well, it's rock solid and still plugging along.  That's about all I
know.  There were queries here and direct to some users from IBM about
updating it to F90 a few years back.  I guess there wasn't enough
interest.  But maybe they were waiting for Z/VM to mature.

> =

> -- glen


-- =


Gary Scott
mailto:garyscottNOSPAM@ev1.net

Fortran Library
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

James Giles (aka Bruce) was almost, but not quite, entirely unlike tea:
> Bob Lidral wrote:
> ...
>> Operating systems are also good examples of such tasks.  It is perhaps
>> interesting that Unix and Linux each run on more different platforms
>> than any operating system written in Fortran of which I'm aware.  (Not
>> sure whether that's a tribute to the portability of C or to the loyalty
>> of the UNIX and Linux communities or to the intensity of general desire
>> to escape from Windows. :-))  Feel free to provide counterexamples :-).
> 
> Well, Windows is written in C++ (a decision that no less than Bill
> Gates himself has characterized as the single worst technical decision
> the company ever made).  The problem is that I don't see much

If I were cynical, I would probably say he said that for some
marketing reason. You know, touting the benfits he would have faced if
programming winders in C$ or .net, or the latest thing he pulled out
of his backside.

-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
I'm not a procrastinator! I'm temporally challenged!

"Jan C. Vorbr�ggen" wrote:
> 
> I'd guesstimate that maybe 1% or so of all code in a large simulation is
> in the model code, the rest is HMI. That's why people like MATLAB, IDL,
> and company - they come with those 99% in ready-to-use form, so you can
> concentrate on the "real" work.

Now, correlate your phantom "guesstimate with the post that appeared
early in this thread:

"The spacecraft orbit determination program suite at JPL has been under
continuous development in Fortran (Fortran, Fortran II, Fortran IV,
Fortran 66, Fortran 77, Fortran 90, Fortran 95) since 1957 or so.  It's
about six million lines now. Maintenance costs are about six work years
per year."
			-- Van Snyder


btw, brush up on your Kalman filtering which I'd like to use if you'd be
so kind to leave the poster IDs in place.

TimC wrote:
> James Giles (aka Bruce) was almost, but not quite, entirely unlike tea:
....
>> Well, Windows is written in C++ (a decision that no less than Bill
>> Gates himself has characterized as the single worst technical decision
>> the company ever made).  The problem is that I don't see much
>
> If I were cynical, I would probably say he said that for some
> marketing reason. You know, touting the benfits he would have faced if
> programming winders in C$ or .net, or the latest thing he pulled out
> of his backside.

Well, regardless of his motivations, his remarks were spot-on.
C++ encourages bloated, buggy, slow code that's difficult to
read and maintain.

-- 
J. Giles

Bob Lidral wrote:
> 

> Yes, but ...
> 
> Guess I left myself somewhat open for that one, sort ot.

Do not worry, if all postings here were epistemologically sound
and without any open ends, what would be the fun? We would have
little or nothing to discuss :).

> 
> I don't happen to have any statistics on the portability of UNIX
> utilities written in C vs. the portability of those same or similar UNIX
> utilities written in Fortran :-).  It's entirely possible those UNIX
> utilities written in C _are_ as portable as (or more so than) various
> 20- or 30-year-old Fortran programs that have been ported a lot; I just
> don't have the data.  OTOH, I _have_ written portable code in C and have
> read portable C code written by others so I know it's possible.  I guess
> I should have specified comparing code written in the two languages that
> performs similar tasks -- that would have been more relevant.  Oh, well
> -- guess I'll have to learn to be more precise.
> 

Unfortunately, I have none either. The only thing I do know, is that
when I read a number of classical papers on early C programming a couple
of years ago, I noticed that the style of programming was completely
different
from what I had learned. 

So, apart from portability issues, a lot has to do with learning to 
program in the language, developing the proper idioms.

> You may note that earlier in my quoted post, I wrote:
> 
> > Portability, for programs written in any language, depends on four
> > things:
> >
> >   1. characteristics of the task,
> >   2. suitability of the programming language to the task,
> >
> and
> 
> > Compilers are good examples of tasks with characteristics that preclude
> > portability.
> >

Yes, I read that and found it a good overview. 

I know of no publication that covers the subject - in most cases 
people will concentrate on one or perhaps two programming languages
and in many cases the emphasis is not so much on portability but
on many aspects of the language. 

> 
> Operating systems are also good examples of such tasks.  It is perhaps
> interesting that Unix and Linux each run on more different platforms
> than any operating system written in Fortran of which I'm aware.  (Not
> sure whether that's a tribute to the portability of C or to the loyalty
> of the UNIX and Linux communities or to the intensity of general desire
> to escape from Windows. :-))  Feel free to provide counterexamples :-).
> 

Hm, an important aspect that you do not mention here is that the source
code for UNIX was available to whomever wanted it (enough). That made 
it quite different from all other proprietary OS's.

> I'd better quit before I feed a comparative language or comparative
> operating system flame war.
> 

I have no intention to do so either.

The best (or at least most extensive) book on the subject that I 
know is: Concepts of programming languages by Robert Sebesta.
He has some points about Fortran wrong, but he gives a well-written
overview.

Regards,

Arjen

Charles Russell wrote:
> 
> "Arjen Markus" wrote
> 
> .  Wait until the C programs are 20 or 30 years old and
> > > have been ported to and used on as many different platforms before
> > > commenting on comparative portability.
> > >
> >
> > But many of the UNIX utilities _are_ in fact 20 or 30 years old.
> > So, with these in hand, one could answer that question.
> 
> But were they ported without having to modify the source code, as would be
> common for fortran?  Even simple unix utilities are usually too full of
> system calls to port easily between different operating systems, e.g. unix
> and MS-DOS.

I do not know - I think that apart from system calls, there were more
problems,
as the first versions of C did not have a well-defined set of header
files 
to work with for instance. (Header files still remain a PITA).

I merely wanted to set the record straight :)

Regards,

Arjen

> Hm, an important aspect that you do not mention here is that the source
> code for UNIX was available to whomever wanted it (enough). That made
> it quite different from all other proprietary OS's.

I've literally spent nights reading VMS's source code (on microfiche).
I'm sure MVS and VM/CMS source code was similarly available to licensed
installations - it was quite usual to implement little bits and pieces
of local extensions to those OSs.

Now, that doesn't allow you to type "make Linux" and re-compile the OS
for your personal use. But it does allow you insight into what and how
it works, in pretty gory detail.

Winwoes - now, that is another matter.

	Jan

> I don't know so much about VS Fortran, though.

I believe that's the one I've been talking about. It's the MVS/VM F77
compiler from around 1985, isn't it?

	Jan

  Hi,

  I am physicist and like problem (specific) oriented approach.
  I don't need any GUI, advanced scripts etc., just reliable
  numbers on input and output and fast execution. It waste of
  time to learning C++ hieroglyphs for me. The natural choice
  is Fortran because it has FORmula TRANslation origin.

  Regards,
  B52


Pierre Asselin wrote:
> Richard Maine <nospam@see.signature> wrote:
> 
>>Pierre Asselin wrote:
>>
>>>I know I'm not making a good case, it's a bit frustrating....
> 
> 
>>So why do you care?  Nobody here is telling you that you shouldn't
>>use whatever tools you find best for your applications, whether
>>that includes Fortran or not.
> 
> 
> I know, it not that big a deal.  I have to use Fortran because that's
> what the rest of the team knows.  We do number crunching so it should
> be a slam-dunk, right?  Well, it's not a slam-dunk.  I'm just trying
> to tell the c.l.f community that something's wrong.  I can't pin it
> down, but I know something is wrong.
> 
> All right, here's another tack.  If a bright student contemplating
> a scientific career with lots of numerical analysis asked you for
> advice on what language to learn, what yould you say?  Fortran?
> 
> Why learn Fortran?  because the compilers optimize better and the
> binaries scream.  However, in today's world the kid *will* have to
> learn another language to do a good job.
> 
> Now Robert Tisdale tells us that Blitz++ also screams
> (http://www.oonumerics.org/blitz/).  Writing (or reading) C++
> templates is, shall we say, challenging, but using them is not
> going to be that hard.  If Blitz++ works, Fortran loses the one
> advantage it has over, oh, C++.  If C++ can do do the deep number
> crunching, but also plug right into a portable GUI with OpenGL
> support (http://www.fltk.org/), make any OS calls needed (extern
> "C"), handle platform idiosyncracies (judicious #ifdef), interface
> to scripting languages (extern "C" + swig) and make you more
> employable, what is the point of learning Fortran?
> 
> Bah, now I'm starting an advocacy thread.  To the newsgroup:  downplay
> the advocacy, but:  aren't you worried?
> 
> --
> pa at panix dot com

> Why learn Fortran?  because the compilers optimize better and the
> binaries scream.  

No, that is a secondary reason. It's easier to write and to understand.
Let me tell you a war story pertinent to the subject.

When I wrote 187.facerec, a part of SPEC CPU2000, I translated one of the 
most complicated parts from the IDL version almost directly (which works
because the numerical part of IDL is a pre-F90 version of F90 with some
peculiarities because it runs in an interpreter), and it worked on the first
try. Later on, I wanted to understand how good compilers are in generating
code for the construct I had used - and which I find to be a very natural
expression of the functionality needed - so I translated this piece into
the equivalent loops. Although I had already done that once before (in
another Fortran-like [hah!] language, occam2), it took me several tries
to get right - all those little off-by-one errors, you know - and the
performance improvement was small (another story). The original code is
a single statement broken, for readability, into three lines:

	    FCTemp = FCImage
	&     * (CSHIFT(CSHIFT(Kernel (:, :, Level),ShiftRow,1),ShiftCol,2)
	&     - DC * Kernel (:, :, Level))

Somebody familiar with the problem domain, image processing, will take
at most a few minutes to understand what this does.

Here's the F77/C/C+-equivalent, taking 20 statements in 32 lines: 

		If (ShiftRow < 0) ShiftRow = RowLen + ShiftRow
		If (ShiftCol < 0) ShiftCol = ColLen + ShiftCol
		RowOffset = RowLen - ShiftRow
		ColOffset = ColLen - ShiftCol
		Do Col = 1, ShiftCol
			Do Row = 1, ShiftRow
				FCTemp (Row, Col) = 
	&		       FCImage (Row, Col) * 
	&		       (Kernel (Row+RowOffset, Col+ColOffset, Level) - 
	&		        DC * Kernel (Row, Col, Level))
			End Do
			Do Row = ShiftRow+1, RowLen
				FCTemp (Row, Col) = 
	&		       FCImage (Row, Col) * 
	&		       (Kernel (Row-ShiftRow, Col+ColOffset, Level) -
	&		        DC * Kernel (Row, Col, Level))
			End Do
		End Do
		Do Col = ShiftCol+1, ColLen
			Do Row = 1, ShiftRow
				FCTemp (Row, Col) = 
	&		       FCImage (Row, Col) * 
	&		       (Kernel (Row+RowOffset, Col-ShiftCol, Level) -
	&		        DC * Kernel (Row, Col, Level))
			End Do
			Do Row = ShiftRow+1, RowLen
				FCTemp (Row, Col) = 
	&		       FCImage (Row, Col) * 
	&		       (Kernel (Row-ShiftRow, Col-ShiftCol, Level) -
	&		        DC * Kernel (Row, Col, Level))
			End Do
		End Do

QED.

	Jan

> However, in today's world the kid *will* have to learn another language
> to do a good job.

Yes, several. It used to be called a "well-rounded education".
 
> but also plug right into a portable GUI with OpenGL support 

Also available for Fortran.

> make any OS calls needed 

Also available for Fortran.

> handle platform idiosyncracies 

Also available for Fortran.

> interface to scripting languages 

Also available for Fortran.

> and make you more employable

Ah yes. That certainly seems true nowadays.

	Jan

> "The spacecraft orbit determination program suite at JPL has been under
> continuous development in Fortran (Fortran, Fortran II, Fortran IV,
> Fortran 66, Fortran 77, Fortran 90, Fortran 95) since 1957 or so.  It's
> about six million lines now. Maintenance costs are about six work years
> per year."
>                         -- Van Snyder

And you think all that is model code? Really?

> btw, brush up on your Kalman filtering which I'd like to use if you'd be
> so kind to leave the poster IDs in place.

You're not using a threaded newsreader?

	Jan

"Arjen Markus" wrote

>  I think that apart from system calls, there were more
> problems,
> as the first versions of C did not have a well-defined set of header
> files
> to work with for instance. (Header files still remain a PITA).
>

C++ test programs that I installed only two or three years ago no longer
run, I think because of changes in the runtime library organization in the
C++ standard that have filtered through to the version of gcc that is
currently distributed with cygwin.  Terrible that that should require
changes in the source code.l

"B52B@pl" <B52B@pl.pl.pl> wrote
>
>   I am physicist and like problem (specific) oriented approach.
>   I don't need any GUI, advanced scripts etc., just reliable
>   numbers on input and output and fast execution. It waste of
>   time to learning C++ hieroglyphs for me. The natural choice
>   is Fortran because it has FORmula TRANslation origin.

An accountant friend once told me, "Everything I ever wanted to do with a
computer I can do with Lotus.  Learning anything else would just be wasting
my time."

f77 is my Lotus.

Charles Russell wrote:
> 
> "Arjen Markus" wrote
> 
> >  I think that apart from system calls, there were more
> > problems,
> > as the first versions of C did not have a well-defined set of header
> > files
> > to work with for instance. (Header files still remain a PITA).
> >
> 
> C++ test programs that I installed only two or three years ago no longer
> run, I think because of changes in the runtime library organization in the
> C++ standard that have filtered through to the version of gcc that is
> currently distributed with cygwin.  Terrible that that should require
> changes in the source code.l

That seems to be a more than general problem with C++...

On the other hand: I was happily surprised to see a ten-year old
executable
run fine on Windows 98 (it was written in FORTRAN 77, including a now 
extinct graphics library, compiled and linked under DOS - before anyone
had heard of Windows, well MS Windows 1.0 may have seen the light in the
same era). 

Regards,

Arjen

In article <4018CFF9.A1681ED4@mediasec.de>,
Jan C. Vorbr�ggen  <jvorbrueggen@mediasec.de> wrote:

>	    FCTemp = FCImage
>	&     * (CSHIFT(CSHIFT(Kernel (:, :, Level),ShiftRow,1),ShiftCol,2)
>	&     - DC * Kernel (:, :, Level))
>
>Somebody familiar with the problem domain, image processing, will take
>at most a few minutes to understand what this does.

I figured out the loops a lot faster.

>QED.

If you say so.

And yes, I've done a lot of image processing, radio-band very long
baseline interferometry.

-- greg

In article <4017D95E.750DE1F7@comcast.net>,
Bob Lidral  <l1dralspamba1t@comcast.net> wrote:
>
>Operating systems are also good examples of such tasks.  It is perhaps
>interesting that Unix and Linux each run on more different platforms
>than any operating system written in Fortran of which I'm aware.  (Not
>sure whether that's a tribute to the portability of C or to the loyalty
>of the UNIX and Linux communities or to the intensity of general desire
>to escape from Windows. :-))  Feel free to provide counterexamples :-).

Some people will be glad to see Bill Gates has been given an honorary 
knighthood because they wish to see his company suffer the same fate as 
Sir Clive Sinclair's: after all he was also a knight heading a computer 
company:-)

>I'd better quit before I feed a comparative language or comparative
>operating system flame war.

So had I.

John Harper, School of Mathematical and Computing Sciences, 
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

> I figured out the loops a lot faster.

You did? Well, nothing like being surprised first thing in the morning
before coffee.

Let's leave it at that.

	Jan

In article <401A103F.8BC46020@mediasec.de>,
Jan C. Vorbr�ggen  <jvorbrueggen@mediasec.de> wrote:

>You did? Well, nothing like being surprised first thing in the morning
>before coffee.
>
>Let's leave it at that.

No, no, we have to disagree again. I drink Coke in the morning.

-- greg

Greg Lindahl wrote:
| In article <401A103F.8BC46020@mediasec.de>,
| Jan C. Vorbr�ggen  <jvorbrueggen@mediasec.de> wrote:
|
|| You did? Well, nothing like being surprised first thing in the morning
|| before coffee.
||
|| Let's leave it at that.
|
| No, no, we have to disagree again. I drink Coke in the morning.

That kinda explains it >:).

--
 Jugoslav
___________
www.geocities.com/jdujic

Arjen Markus wrote:

> Bob Lidral wrote:
> >
> > [...]
>
> Unfortunately, I have none either. The only thing I do know, is that
> when I read a number of classical papers on early C programming a couple
> of years ago, I noticed that the style of programming was completely
> different
> from what I had learned.
>
> So, apart from portability issues, a lot has to do with learning to
> program in the language, developing the proper idioms.

Not sure how old the "classical papers" were, but there have been a few
changes in C from the original language.  The first version most people
learned was K&R (from Kernighan & Ritchie, the authors of "The C
Programming Language").  While it was a great book for learning the
language, it was not exactly a complete language specification.  Where
the book was incomplete or ambiguous, different compilers implemented
features differently yet still consistently with the book. There was a
subsequent ANSI standard and a second edition of K&R that specified
the language more completely, removed several ambiguities, and added new
features.  Among other things, this specified a consistent use for
"extern", added function prototypes, and added a mechanism for
specifying a variable number of arguments to a function.  These changes
from K&R C to ANSI C made standard-conforming C source more portable and
were roughly equivalent in flavor to the kinds of changes in Fortran
between the 1966 and 1977 standards.
>
> [...]
> The best (or at least most extensive) book on the subject that I
> know is: Concepts of programming languages by Robert Sebesta.
> He has some points about Fortran wrong, but he gives a well-written
> overview.

Thanks for the tip.  The book is a little pricey so I'll have to wait
until my bank account gets a little bigger but I'll try to check it out
some day.


Bob Lidral
l i d r a l  at  a l u m  dot  m i t  dot  e d u

James Giles wrote:

> Bob Lidral wrote:
> ...
> > Operating systems are also good examples of such tasks.  It is perhaps
> > interesting that Unix and Linux each run on more different platforms
> > than any operating system written in Fortran of which I'm aware.  (Not
> > sure whether that's a tribute to the portability of C or to the loyalty
> > of the UNIX and Linux communities or to the intensity of general desire
> > to escape from Windows. :-))  Feel free to provide counterexamples :-).
>
> Well, Windows is written in C++ (a decision that no less than Bill
> Gates himself has characterized as the single worst technical decision
> the company ever made).  The problem is that I don't see much
> difference in fklavor between UNIX and Windows.  Both are
> bloated, arcane, insecure, unreliable, slow, and hard to learn.

First time I can recall anyone characterizing Unix as "bloated".  In
what sense: size of source code, size of compiled code, drain on
resources, excess of features and utilities?  There are also quite a few
differences between Unix and Windows.  One significant difference is
that Unix had multi-processing decades before Windows.  Having learned
to use several operating systems (Multics; NOS, NOS/BE, and their
predecessors; IBM OS/360; several flavors of Unix and Linux; Windows;
and a couple of flavors of VMS) and to maintain several of those, I
found Unix one of the easiest to learn -- and it was not my first, so
I'm not suffering from that prejudicial influence.  I guess I'm
curious how well you know Unix and what your preferred system is.

> If windows out-bloats or out-arcanes UNIX it also outnumbers
> it.  Neither is as good as alternatives that used to exist before
> those two took over the world.  People working on genuinely
> secure systems have already made it clear that it can't be done
> campatibly with either UNIX or Windows - those systems carry
> their security flaws with their specifications, not just from
> weaknesses in their implementations.

Not sure what this has to do with the original issue of the relative
portability of programs written in Fortran vs. those written in C.
Also, although Windows may outnumber Unix, Linux, and BSD in units sold,
it certainly doesn't outnumber any one of them in number of
architectures on which it has been successfully implemented -- a number
more relevant to the issue of portability.  Though in the case of
Windows, certainly one of the reasons it hasn't been ported anywhere is
that Microsoft doesn't want to do it and no one else has a license to
the source code.

> As I've pointed out, I believe much of the lack of reliability of
> systems is directly tracable to C: a large percentage of bug in
> modern systems still turns out to be buffer overruns.  C also
> tend to require more lines of code to do similar tasks than other
> languages - hence one of the causes of bloat.  C is not a very
> good choice as a system development language.  Many Pascal
> extensions used experimentally in the 70's would have been
> better choices.

Again, not exactly a portability issue and Pascal is not a good example
of a language useful for writing portable programs.  I'm a little
curious how buffer overruns are either unavoidable in C or unique to it.
It might be possible to avoid buffer overruns in Pascal using subrange
types for array indices, but it's not clear how many compilers would
implement the corresponding checks and, of those, how efficiently those
checks could and would be implemented.

Pascal always was a pretty useless language for writing large programs.
Essentially little more than a toy, it was designed to provide as few
features as possible in order to use as a first language for teaching
only those techniques and methods regarded as blessed somehow by the
Disciples of St. Nik (and, apparently more important, to prevent
students from ever encountering techniques which St. Nik might not
approve).

Its proponents claimed one of its most essential strengths was its
strong typing, yet the definition of this "feature" precluded separate
compilations unless it was defeated or bypassed.  Strong typing could
also be bypassed fairly easily using variant records (unions) making the
code even more difficult to read.  There was no way to write library
routines in Pascal (without extending the language).  The language
definition was incredibly sloppy, replete with incomplete specifications
especially wrt limits and sizes.  Every incomplete part of the
specification left the implementation details up to the whim and
convenience of the implementor so that it was impossible, for example,
to write any program using sets on a universe of more than 4 or 5 items
with any hope that it might be portable.  In fact, one of several major
disappointments (to me) was that, although it was possible
to declare something to be a set of character, it was impossible to have
such a set contain the character ";" (semi-colon) in one of the earliest
implementations (CDC CYBER) thus precluding the use of such sets to
implement a parser.  Maybe I'm naive, but that seemed to me an obvious
place to use sets (except, of course, for the nearly useless definition
of the "case" statement that would have made any such use extremely
awkward and inherently error-prone).

Any Pascal subroutine or function that accepted an array as an argument
could only accept one size of array so that, for example, if you had a
subroutine that sorted a 100-element array, you'd have to write a
separate subroutine to sort a 101-element array (at least until Version
3 -- sometime in the early 1980s?).  The "case" statement had no "else"
(again, it took more than a decade for proponents even to realize [or
maybe just to admit] that was a deficiency); the "if" statement had no
"endif" (so that it suffered from the same dangling-else problem as C
and several other languages of that time except, curiously, Algol 68
with which Wirth should have been familiar).  There were no varying-
length character strings or anything else that might be useful for
writing error-processing routines.

When I was a TA and later on various jobs, I had to read lots and lots
of really bad source code (students never came in for help with
programs that already worked and employers never asked us to debug code
that worked :-)).  I was always amazed that the languages designed for
readability and maintainability could be used to write the ugliest and
most unreadable code.  The two worst examples I encountered were COBOL
(I don't usually admit to any experience in this area -- especially on
resumes :-)) and Pascal.  COBOL, with its use of English words rather
than symbols to "improve" readability frequently obscures algorithms
with excess verbosity.  Pascal with its desperate need to restrict
programmer flexibility instead leads programmers -- especially beginners
-- to write horribly unreadable code attempting to twist their thinking
in some non-intuitive way because Pascal lacked any reasonable
mechanisms for the intuitive approach or, in some cases, for any
approach.

C certainly has its own problems but, unlike Pascal, at least it's a
real language useful for something.  Pascal never had any hope of
evolving into anything useful and it was difficult to port even simple
student programs between different implementation.

> Comparing C to Fortran for system development (or compilers)
> is a little unfair since Fortran was not designed for such things
> and even long-time proponents don't claim that it's adequate
> for such activities without extensions.  Still, system-level
> code would probebly be smaller, clearer, and less buggy in
> a properly extended Fortran.

Evidently, you missed my smiley; perhaps I should have used more of
them.  And I'll even agree that any standard-conforming implementation
of Fortran 77 or later would probably be a better choice than any
implementation of any version of Pascal for system-level code.  But
that's even more unfair: Pascal was designed only to be a first language
for teaching programming to beginning students and restricting their
choices to "good" programming practices.  That Pascal was tortured and
perverted in attempts to implement solutions to real problems, with
varying degrees of success, is more a testament to the stubborn
blindness of its proponents in the face of numerous counter-examples
than to any inherent suitability.

I suggest your last statement is a little unfair.  With sufficient time
and effort, it's likely many languages could be extended to provide
concise and efficient mechanisms for any problem domain (though I
wouldn't want to try that with RPG, APL, LISP, or even SNOBOL for
system-level code :-)).  Assuming such unspecified extensions were
properly designed and implemented, the resulting language could almost
certainly be used to write shorter, clearer, and less buggy code.  It
might even be possible to extend Pascal with enough time and effort.
So, yes, if there were a language perfectly designed for implementing
system-level code, then that language would be better than any less-
perfect language (including C); I believe that's called a "tautology".
And if I had a place to stand and a lever long enough ... :-)  If your
point is that Fortran could be so extended but C could not, then I
disagree in the absence of any supporting examples.  If I wanted to
start a flame-war, I might even suggest C++ _is_ that extended version
of C (that _was_ intended as a joke).

Note also that perceived code clarity depends a lot on the reader's
familiarity with the source language, with the programming idioms used,
and, for the same source code and reader, can change over time --
either for the better and for the worse.


Bob Lidral
l i d r a l  at  a l u m  dot  m i t  dot  e d u

"Bob Lidral" <l1dralspamba1t@comcast.net> wrote in message
news:401CB2B9.E931FD56@comcast.net...
> Not sure what this has to do with the original issue of the relative
> portability of programs written in Fortran vs. those written in C.
> Also, although Windows may outnumber Unix, Linux, and BSD in units sold,
> it certainly doesn't outnumber any one of them in number of
> architectures on which it has been successfully implemented -- a number
> more relevant to the issue of portability.  Though in the case of
> Windows, certainly one of the reasons it hasn't been ported anywhere is
> that Microsoft doesn't want to do it and no one else has a license to
> the source code.
>
Windows currently supports 4 architectures that I am aware of, one not a
production release, one a cut down form. Cygwin (including IMHO the best f77
for Windows) runs on only one of those architectures, due to the lack of a
consistent API to support fork() emulation.  Variety and quality of Fortran
compilers for these Windows versions is competitive with those other
languages.  More Fortran compilers have been implemented without fully
coming to terms with Microsoft than with (CLR byte code support etc), but
they all support portability better than those other languages.
Traditionally, linux and BSD have encouraged a large number of free
installations which don't show up in the sales figures.

Bob Lidral wrote:
[snipped various non-Pascal related pieces] 
| Again, not exactly a portability issue and Pascal is not a good example
| of a language useful for writing portable programs.  
| 
| Pascal always was a pretty useless language for writing large programs.
| students from ever encountering techniques which St. Nik might not
| approve).
| 
| Its proponents claimed one of its most essential strengths was its
| strong typing, yet the definition of this "feature" precluded separate
| compilations unless it was defeated or bypassed.  
|
| There was no way to write library
| routines in Pascal (without extending the language).  The language
| definition was incredibly sloppy, replete with incomplete specifications
| especially wrt limits and sizes.  
| 
| Any Pascal subroutine or function that accepted an array as an argument
| could only accept one size of array so that, for example, if you had a
| subroutine that sorted a 100-element array, you'd have to write a
| separate subroutine to sort a 101-element array (at least until Version
| 3 -- sometime in the early 1980s?).  The "case" statement had no "else"
| (again, it took more than a decade for proponents even to realize [or
| maybe just to admit] that was a deficiency); the "if" statement had no
| "endif" There were no varying-length character strings or anything else 
| that might be useful for writing error-processing routines.
|
| That Pascal was tortured and perverted in attempts to implement solutions 
| to real problems, with varying degrees of success, is more a testament 
| to the stubborn blindness of its proponents in the face of numerous 
| counter-examples than to any inherent suitability.

Huh... you should've posted that in a pascal newsgroup >;).

The main keeper of Pascal nowadays is Borland with their Delphi variant
of the language (formerly known as Object Pascal). Speaking as 1) hobbyist
OO programmer 2) only occasional Delphi luser and 3) a programmer with
no formal CS education, I must say that I think they did a good job in
extending the language. There are several features I very like:

- Concept of Units, quite similar with F90 Modules, but avoiding the
  potential "compiling cascade" problem (the price is that you have
  to redeclare the routine interfaces in unit header, but the compiler 
  checks whether they match the implementation)
- IMVHO very nice object model, with proper inheritance rules, and
  an appropriate set of keywords (inherited, override, virtual, 
  reintroduce, abstract, dynamic etc.), and, as a Good Thing (TM), 
  no multiple inheritance.
- Good typecasting model with compile-time checkable feasibility
- Variable-length strings and arrays
- Support for C-style pointers (just in case you wanna toy with fire)
- etc.

Of course, it keeps the ugly and confusing syntax with non-intuitive
rules regarding begin, end and use of semicolons, commas and dots,
but I'm not saying it's perfect, and, being just an occasional user
I'm (trying) not advocating it. But my point is, languages evolve,
and your comments seem to address what was the Pascal in 70s.

I render your comments in the same way as if someone would come
preaching in c.l.f. that Fortran is a bloated and arcane language
due to GOTO spaghettis, silly fixed-form code, three-way IFs,
absence of dynamic allocation, Hollerith syntax for characters, etc.

-- 
 Jugoslav
___________
www.geocities.com/jdujic

Bob Lidral wrote:
> 
> Arjen Markus wrote:
> 
> 
> Not sure how old the "classical papers" were, but there have been a few
> changes in C from the original language.  


Papers by Andrew Koenig, Henry Spencer, ... 

> >
> > [...]
> > The best (or at least most extensive) book on the subject that I
> > know is: Concepts of programming languages by Robert Sebesta.
> > He has some points about Fortran wrong, but he gives a well-written
> > overview.
> 
> Thanks for the tip.  The book is a little pricey so I'll have to wait
> until my bank account gets a little bigger but I'll try to check it out
> some day.
> 

I have a very extensive library next door. It is easy and cheap for me
to borrow such books :)

Regards,

Arjen

Jugoslav Dujic wrote:

> Bob Lidral wrote:
> [snipped various non-Pascal related pieces]
> | [snipped various Pascal-related pieces]
>
> Huh... you should've posted that in a pascal newsgroup >;).

You're probably half-right -- except that I believe I'm already treading
dangerously close to a flame-war.  Inasmuch as I was replying to a post
by James Giles concerning relative portability of programs written in C
and Fortran in which he introduced the subject of Pascal, it seemed
reasonable to comment on Pascal as well.  OTOH, my "comments" may have
strayed a little too far into the realm of advocacy (or, in this case,
anti-advocacy).  In the '70s and early '80s, I endured a few too many
Disciples of St. Nik regularly and repeatedly bombarding me with
unsolicited idiotic double-think such as: one must write GOTO-less
Fortran (1966 standard), assembly language, and MIX algorithms and
Pascal is a useful, high-level, portable language that is easy to use
for any programming problem in any domain.  Had I been able to avoid
them or had they shut up after the first dozen or so utterances of such
drivel, I probably wouldn't have minded so much, but several of them
were professors, co-workers, or even friends so there was no diplomatic
way to avoid them -- even changing the subject or refusing to argue the
points didn't seem to reduce their unrelenting, often irrelevant to
current discussion, repetitive, spontaneous pro-Pascal rants.  So, I
apologize for my excessive anti-Pascal zeal in this newsgroup and offer
this as an explanation.

> The main keeper of Pascal nowadays is Borland with their Delphi variant
> of the language (formerly known as Object Pascal). Speaking as 1) hobbyist
> OO programmer 2) only occasional Delphi luser and 3) a programmer with
> no formal CS education, I must say that I think they did a good job in
> extending the language. There are several features I very like:
>
> - Concept of Units, quite similar with F90 Modules, but avoiding the
>   potential "compiling cascade" problem (the price is that you have
>   to redeclare the routine interfaces in unit header, but the compiler
>   checks whether they match the implementation)
> - IMVHO very nice object model, with proper inheritance rules, and
>   an appropriate set of keywords (inherited, override, virtual,
>   reintroduce, abstract, dynamic etc.), and, as a Good Thing (TM),
>   no multiple inheritance.
> - Good typecasting model with compile-time checkable feasibility
> - Variable-length strings and arrays
> - Support for C-style pointers (just in case you wanna toy with fire)
> - etc.
>
> Of course, it keeps the ugly and confusing syntax with non-intuitive
> rules regarding begin, end and use of semicolons, commas and dots,
> but I'm not saying it's perfect, and, being just an occasional user
> I'm (trying) not advocating it. But my point is, languages evolve,
> and your comments seem to address what was the Pascal in 70s.

Absolutely correct.  My reply was to James Giles's assertions:

> As I've pointed out, I believe much of the lack of reliability of
> systems is directly tracable to C: a large percentage of bug in
> modern systems still turns out to be buffer overruns.  C also
> tend to require more lines of code to do similar tasks than other
> languages - hence one of the causes of bloat.  C is not a very
> good choice as a system development language.  Many Pascal
> extensions used experimentally in the 70's would have been
> better choices.
>
Inasmuch as his comments considered extensions for Pascal in the '70s,
my reply addressed the state of the language during that time-frame.

> I render your comments in the same way as if someone would come
> preaching in c.l.f. that Fortran is a bloated and arcane language
> due to GOTO spaghettis, silly fixed-form code, three-way IFs,
> absence of dynamic allocation, Hollerith syntax for characters, etc.

Fair enough.  However, the Pascal you describe with support for separate
compilations, OO extensions, strings, and variable-length arrays
(function arguments?) is a vastly different language from the Pascal
designed by Niklaus Wirth -- though perhaps a few (certainly not all) of
those extensions were under consideration in the '70s.  It also differs
from the Pascal of the '70s by significantly more than the Fortran 1978
standard (called Fortran 77 but not finished quite on time) differs from
the 1966 standard.  The Fortran 77 standard was extremely disappointing
in that it barely added to the standard the most important features
already included as extensions by almost all of the vendors (though, of
course, with widely-varying syntax) -- in fact the original proposed
version (March, 1976) didn't even include if-then-else.

Since the original comment by Mr. Giles explicitly referred to the state
of Pascal in the '70s, I thought my comments were appropriate to that
version of the language -- if not, perhaps, appropriate in length or to
this newsgroup.  I'm not really interested in continuing this discussion
topic (I had quite enough of people trying to preach the virtues of
Pascal to me with religious zeal in the '70s and early '80s to last me
a lifetime) but if you wish to do so, I suggest we move it out of this
newsgroup to private email.  However, if you do wish to discuss the
relative portability of Fortran, C, and Pascal by email, I suggest you
treat all three languages similarly; that is either compare Fortran 66
and Fortran 77 with C and the Pascal of the '70s or compare Fortran
90/95 with C++ and Borland's current OO Pascal.


Bob Lidral
l i d r a l  at  a l u m  dot  m i t  dot  e d u

Bob Lidral wrote:
....
> Absolutely correct.  My reply was to James Giles's assertions:
>
>> As I've pointed out, I believe much of the lack of reliability of
>> systems is directly tracable to C: a large percentage of bug in
>> modern systems still turns out to be buffer overruns.  C also
>> tend to require more lines of code to do similar tasks than other
>> languages - hence one of the causes of bloat.  C is not a very
>> good choice as a system development language.  Many Pascal
>> extensions used experimentally in the 70's would have been
>> better choices.
>>
> Inasmuch as his comments considered extensions for Pascal in the '70s,
> my reply addressed the state of the language during that time-frame.

And, inasmuch as my comments referred to *extensions* of Pascal,
your reply was not really relevant.  And, my remarks were not
specifically about Pascal, except as an example of a missed
opportunity within the industry to get a better implementation
language than what became de-facto standard.

C can't be extended out of its poor design.  It has *lots* of features
already - they're just badly designed.  For example, just to get rid
of all unnecessary uses of pointers would take a major redesign.
C's syntax is worse (by a lot) than Pascal's, or Fortran's, or Ada's, or....
In fact, with respect to nearly all the objectively known (from
productivity experiments) language design principles, C adopts the
worst (or in a few cases the second worst) alternative means of
designing the feature into the language.

I once went through the C standard document highlighting passages
that I needed to frequently reference.  The yellow highlighter was used
to mark any mentions of badly designed features.  There were few
pages without some yellow passages.  I can't think of another language
about which that would be true - or many for which the exercise would
even suggest itself.

The first compiler I wrote was a C compiler in the late 70's.  It
was just an educational exercise.  I wrote it in Pascal. (It was
not part of a class, I just wanted to learn compiler construction,
Pascal, and C.)   I came away with a grudging respect for Pascal.
Some of its rules were inconvenient (like the strict order required
of declarations).  But it was well defined and was later legible.
I came away with an extreme dislike for C.  Every feature had to
be implemented twice: first as I thought it was supposed to work,
and second in the (not as well thought out) way it was really
supposed to work according to the C specification (K&R - there
was no standard in those days).

Since then I've done maintenence on compilers written in C, extended
flavors of Fortran, assembly, and a few other languages.  I've worked
on other system software as well (in a variety of languages).  C remains
the language I consider least well suited to the needs of a system
programmer.  It's syntax is poor - it tends to be illegible even to
experts.  There are lots of unnecessarily easy to make errors that
are hard to find (pointer errors, like buffer overruns for example,
are chief among them).

-- 
J. Giles

"Jan C. Vorbr�ggen" wrote:
> 
> > "The spacecraft orbit determination program suite at JPL has been under
> > continuous development in Fortran (Fortran, Fortran II, Fortran IV,
> > Fortran 66, Fortran 77, Fortran 90, Fortran 95) since 1957 or so.  It's
> > about six million lines now. Maintenance costs are about six work years
> > per year."
> >                         -- Van Snyder
> 
> And you think all that is model code? Really?

Why don't you ask the OP? Whatever the actual model percentage may be,
I'm 100% certain that your "guesstimate" of 1% is so far off base that
it won't even be funny!

"James Giles" <jamesgiles@worldnet.att.net> wrote in message news:<rozTb.163160$6y6.3195631@bgtnsc05-news.ops.worldnet.att.net>...

> C can't be extended out of its poor design.  It has *lots* of features
> already - they're just badly designed.  For example, just to get rid
> of all unnecessary uses of pointers would take a major redesign.
> C's syntax is worse (by a lot) than Pascal's, or Fortran's, or Ada's, or....
> In fact, with respect to nearly all the objectively known (from
> productivity experiments) language design principles, C adopts the
> worst (or in a few cases the second worst) alternative means of
> designing the feature into the language.

What are the books, papers, or web sites describing these
"productivity experiments"? I am curious. Les Hatton has done research
on the occurrence of defects in large C and Fortran 66 and 77
programs, and he did not find Fortran to be superior. Quoting page 16
of his paper "The T-Experiments: Errors in
Scientific Software", available at
http://www.leshatton.org/Documents/Texp_ICSE297.pdf ,

"Commercially released C and Fortran software are provably full of
statically detectable faults, irrespective of the existence of any
quality system, level of criticality, or application area. In fact,
there are about 8 serious faults per 1000 executable lines in C which
are statically detectable in commercially released code and about 12
per 1000 executable lines in Fortran. This is almost certainly true
for other languages also. If a language contains a hole, programmers
will fall into it. All languages contain holes."

I don't know a C++ vs. Fortran 95 comparison would turn out.

Pascal critics will enjoy Kernighan's essay "Why Pascal is Not My
Favorite Programming Language" at
http://www.lysator.liu.se/c/bwk-on-pascal.html .

> Les Hatton has done researchon the occurrence of defects in large C and
> Fortran 66 and 77 programs, and he did not find Fortran to be superior.
> Quoting page 16 of his paper "The T-Experiments: Errors in Scientific
> Software", available at http://www.leshatton.org/Documents/Texp_ICSE297.pdf 
> 
> "Commercially released C and Fortran software are provably full of
> statically detectable faults, irrespective of the existence of any
> quality system, level of criticality, or application area. In fact,
> there are about 8 serious faults per 1000 executable lines in C which
> are statically detectable in commercially released code and about 12
> per 1000 executable lines in Fortran. 

I also read the paper. I see two problems with it: One, most of the Fortran
errors he found in F77 code are interface problems - those should go away
with F90 et seq. Two, it's unclear whether some or even most of these
formal errors are in fact relevant to program correctness. That, of course,
is not statically detectable.

The actual scatter in results for different implementations of superficially
the same application he has observed in some other experiments give more 
pause for thought, although he has selected some of the more complicated
processing pipelines I have seen. One could also view this, at least in
part, as a problem of missing (formalized) specification.

	Jan

Jan C. Vorbr�ggen wrote:
>> Les Hatton has done researchon the occurrence of defects in large C and
>> Fortran 66 and 77 programs, and he did not find Fortran to be superior.
>> Quoting page 16 of his paper "The T-Experiments: Errors in Scientific
>> Software", available at
>> http://www.leshatton.org/Documents/Texp_ICSE297.pdf
>>
>> "Commercially released C and Fortran software are provably full of
>> statically detectable faults, irrespective of the existence of any
>> quality system, level of criticality, or application area. In fact,
>> there are about 8 serious faults per 1000 executable lines in C which
>> are statically detectable in commercially released code and about 12
>> per 1000 executable lines in Fortran.
>
> I also read the paper. I see two problems with it: One, most of the
> Fortran errors he found in F77 code are interface problems - those
> should go away with F90 et seq. Two, it's unclear whether some
> or even most of these formal errors are in fact relevant to program
> correctness. That, of course, is not statically detectable.

Also, he's comparing ISO C (89) to Fortran 77.  The corresponding
languages should actually be K&R C vs. F77 or ISO C to F90.

There is also some doubt as to his method of determining when
programs are performing similar tasks.  He claims, for example,
that Fortran programs have about 2.5 times as many lines of code
as C programs for similar tasks. That is about the exact reverse
of common observation when comparing programs actually intended
to have *identical* function.  When old Fortran code is converted
to C, the C code is invariably longer (by about a factor of 2 or so).
Mileage may vary for small samples, but big "production" codes
invariably all follow this pattern.

It's interesting that he found 119 features of ISO C that are officially
standard but undefined.

Good experimental comparisons of language features are (as far as
I can find) all old.  Try 70's issues of Journal of Man-Machine
Interaction, or CACM, or IEEE Transactions on Software Engineering.
An early survey of results of such studies (many were made after that,
but they seemed to slow after the end of the 70's) was "Language Design
for Programming Reliability", IEEE Transactions on Software Engineering,
vol. se-1, no. 2, June 1975, pp.179-191.

-- 
J. Giles

"Jan C. Vorbr�ggen" wrote:
> 
> in the model code, the rest is HMI. That's why people like MATLAB, IDL,
> and company - they come with those 99% in ready-to-use form, so you can
> concentrate on the "real" work.

This must be coming from a 99% vacuum head! Say, you have a simulation
requiring periodic suspension to modify certain parameters. In a PRO sim
environment, it'd be a one liner, like

	if(sched(t_chg)) call suspend

With your Matlab/Simulink combo, and all that 99% ready-to-use widgets,
you're in for a rude awakening. See attached, then start looking for a
hole to hide...

--
Dr.B.Voh
------------------------------------------------------
Applied Algorithms    http://sdynamix.com

 

> #define S_FUNCTION_LEVEL 2
> #define S_FUNCTION_NAME  sf_timeout
> 
> #include "simstruc.h"
> 
> /*====================*
>  * S-function methods *
>  *====================*/
> 
> /* Function: mdlInitializeSizes ===============================================
>  * Abstract:
>  *    The sizes information is used by Simulink to determine the S-function
>  *    block's characteristics (number of inputs, outputs, states, etc.).
>  */
> static void mdlInitializeSizes(SimStruct *S)
> {
>     /* sf_timeout has one parameter: number of seconds until time-out */
>     ssSetNumSFcnParams(S, 1);  /* Number of expected parameters */
>     if (ssGetNumSFcnParams(S) == ssGetSFcnParamsCount(S)) {
>         if (mxIsEmpty(    ssGetSFcnParam(S,0) ) ||
>             mxIsSparse(   ssGetSFcnParam(S,0) ) ||
>             mxIsComplex(  ssGetSFcnParam(S,0) ) ||
>             !mxIsNumeric( ssGetSFcnParam(S,0) ) ||
>             mxGetNumberOfElements( ssGetSFcnParam(S,0) ) > 1 )
>             ssSetErrorStatus(S, "Parameter must be a real scalar");
>     } else {
>         /* Return if number of expected != number of actual parameters */
>         return;
>     }
> 
>     ssSetNumContStates(S, 0);
>     ssSetNumDiscStates(S, 0);
> 
>     if (!ssSetNumInputPorts(S, 0)) return;
> 
>     if (!ssSetNumOutputPorts(S, 0)) return;
> 
>     ssSetNumSampleTimes(S, 1);
>     ssSetNumRWork(S, 1);  /* time-out time stamp will be stored in RWork */
>     ssSetNumIWork(S, 0);
>     ssSetNumPWork(S, 0);
>     ssSetNumModes(S, 0);
>     ssSetNumNonsampledZCs(S, 0);
> 
>     ssSetOptions(S, 0);
> }
> 
> /* Function: mdlInitializeSampleTimes =========================================
>  * Abstract:
>  *    This function is used to specify the sample time(s) for your
>  *    S-function. You must register the same number of sample times as
>  *    specified in ssSetNumSampleTimes.
>  */
> static void mdlInitializeSampleTimes(SimStruct *S)
> {
>     ssSetSampleTime(S, 0, CONTINUOUS_SAMPLE_TIME);
>     ssSetOffsetTime(S, 0, 0.0);
> }
> 
> #undef MDL_INITIALIZE_CONDITIONS   /* Change to #undef to remove function */
> 
> #define MDL_START  /* Change to #undef to remove function */
> #if defined(MDL_START)
>   /* Function: mdlStart =======================================================
>    * Abstract:
>    *    This function is called once at start of model execution. If you
>    *    have states that should be initialized once, this is the place
>    *    to do it.
>    */
>   static void mdlStart(SimStruct *S)
>   {
>       mxArray *now[1];
>       real_T *endTime = ssGetRWork(S);
>       real_T duration = mxGetScalar(ssGetSFcnParam(S,0));
> 
>       /* Get the current time stamp */
>       mexCallMATLAB(1, now, 0, NULL, "now");
> 
>       /* Calculate the time-out time stamp */
>       *endTime = mxGetScalar(now[0]) + duration/(24*60*60);
> 
>       mxDestroyArray(now[0]);
>   }
> #endif /*  MDL_START */
> 
> /* Function: mdlOutputs =======================================================
>  * Abstract:
>  *    In this function, you compute the outputs of your S-function
>  *    block. Generally outputs are placed in the output vector, ssGetY(S).
>  */
> static void mdlOutputs(SimStruct *S, int_T tid)
> {
> }
> 
> #define MDL_UPDATE  /* Change to #undef to remove function */
> #if defined(MDL_UPDATE)
>   /* Function: mdlUpdate ======================================================
>    * Abstract:
>    *    This function is called once for every major integration time step.
>    *    Discrete states are typically updated here, but this function is useful
>    *    for performing any tasks that should only take place once per
>    *    integration step.
>    */
>   static void mdlUpdate(SimStruct *S, int_T tid)
>   {
>       mxArray *now[1];
>       real_T *endTime = ssGetRWork(S);
> 
>       /* Get the current time stamp */
>       mexCallMATLAB(1, now, 0, NULL, "now");
> 
>       /* Request a stop when the time-out time is reached */
>       if (mxGetScalar(now[0]) >= *endTime)
>           ssSetStopRequested(S, 1);
> 
>       mxDestroyArray(now[0]);
>   }
> #endif /* MDL_UPDATE */
> 
> #undef MDL_DERIVATIVES  /* Change to #undef to remove function */
> 
> /* Function: mdlTerminate =====================================================
>  * Abstract:
>  *    In this function, you should perform any actions that are necessary
>  *    at the termination of a simulation.  For example, if memory was
>  *    allocated in mdlStart, this is the place to free it.
>  */
> static void mdlTerminate(SimStruct *S)
> {
> }
> 
> /*======================================================*
>  * See sfuntmpl.doc for the optional S-function methods *
>  *======================================================*/
> 
> /*=============================*
>  * Required S-function trailer *
>  *=============================*/
> 
> #ifdef  MATLAB_MEX_FILE    /* Is this file being compiled as a MEX-file? */
> #include "simulink.c"      /* MEX-file interface mechanism */
> #else
> #include "cg_sfun.h"       /* Code generation registration function */
> #endif