A petition to J3 apropos FORTRAN's future
Matthew
Ken Plotkin
Amusing.
So, as long as Fortran is available, the petitioner's favorite
language doesn't stand a chance of being noticed or adopted.
Paul van Delst
Since this (really) has absolutely nothing to do with Fortran, it's off topic for this
newsgroup, so apologies in advance.
Apart from the fact that whoever started the petition has waaaay too much time on their
hands, the whole idea behind it is downright unamerican! (More choice! Let the market
decide! Health care for all! Oops, scratch that last one) :o)
Then again, the petition originator apparently thinks promotion of ignorance is a valid
educational tool which, as far as I can tell, is also supported by school boards across
the US (more so in some places than others). So maybe it is quintessentially american?
cheers,
paulv
p.s. I guess the petition sponsor is also against the automobile industry what with
current internal combustion engines only being "incremental refinements of old ones". Oh
well, there goes the economy. :o(
Richard Maine
Here's what I wrote about this on the Fortran 90 mailing list:
I mostly think it is a bunch of uninformed whining not worth
replying to in detail... so I won't. As someone else said, what
does "retire Fortran" mean? Particularly as it is allegedly
addressed at J3. Is J3 supposed to send a goon squad after everyone
that continues using the language?
And whatever it means, what purpose would this allegedly achieve?
Stopping other people from getting work done? I see nobody forcing
the author to use Fortran. I'm always very leery of people who go
on crusades whose sole purpose is to force other people to do or
not do something that has no obvious effect on the crusader... but
I veer dangerously close to current US political issues here. :-(
No, I see nothing here worth discussing. My disagreements with the
material aside, this is nothing put a publicly posted whine. And I note
that it has no options for discussion or anything - just sign your
name or not. If the author actually thinks this has any constructive
use, then I'd say he is as misinformed about matters other than just
Fortran.
--
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
Dan Tex1
>From: for...@hotmail.com (Matthew)
>Date: 2/19/04 8:27 PM Pacific Standard Time
>Message-id: <f61ad277.0402...@posting.google.com>
>
>www.fortranstatement.com
It would be interesting to see what language the author of the web page
believes should replace Fortran. Add to that a list of the features which make
the other language more appropriate for numerical work.
The same information from the "others" who have their "statements" posted on
the web page would be interesting to see. Those who have claimed a defect or
"less than desirable" feature of fortran can show us how their language of
choice handles the stated situation better.
Dan :-)
sama
>
> www.fortranstatement.com
>
You make a number of valid points, but you're also way off in between
those points. J3 is raping Fortran precisely because of inertia while
they are fully aware that their copy-cat featuritis would not have a
snowball's chance in hell if it had to stand on its own.
By the same token, Fortran legacy, is fortunately the counterweight
forcing J3 hacks to 100% backward compatibility. Without it, any new
concoction is DOA, and they know it. So, relax, papa Fortran ain't
retiring just yet.
" >
> for...@hotmail.com (Matthew) writes:
> Here's what I wrote about this on the Fortran 90 mailing list:
>
> I mostly think it is a bunch of uninformed whining not worth
> replying to in detail... so I won't. As someone else said, what
> does "retire Fortran" mean? Particularly as it is allegedly
> addressed at J3. Is J3 supposed to send a goon squad after everyone
> that continues using the language?
No - we should demand a license fee; the amount of $ 699 per
installation springs to mind.
[ oops, wrong fight, sorry ;-) ]
--
Toon Moene - mailto:to...@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)
Tabon
on "keeping Fortran alive", "hiring Fortran", "Teaching Fortran in
Universirties", or something like that. Then all Fortraners can
explain their point of view about why they like Fortran and what they
expect from J3, Why it should be kept "hired" etc. One can also add
"success stories section", "donation to Free Software Project",
"Asking j3 members going faster" etc.
I think you got the idea: a public-pro-Fortran-discussion
froum-website (unforunately I cannot set it up myself but I would sign
the petition, I have few success stories and I need features to ask
from j3 and compiler vendors ...)
Fortran Library site or Fortran Market (are you volunteer?)
Tabon
Andy Nelson
> I suggest somebody to setup an opposite website and ask for petition
> on "keeping Fortran alive", "hiring Fortran", "Teaching Fortran in
> Universirties", or something like that. Then all Fortraners can
> explain their point of view about why they like Fortran and what they
> expect from J3, Why it should be kept "hired" etc. One can also add
> "success stories section", "donation to Free Software Project",
> "Asking j3 members going faster" etc.
I'm only being about 1/2 ironic when I say that this exists
already,
The forum is called comp.lang.fortran
It also has another benefit that you didn't mention above
that many folk come here and get their questions answered
about `is this a bug in my code' and `what am I doing wrong
here' etc. You can come here and lurk and learn a lot,
or come and post and learn too. This being usenet, there
are also those who come just to make noise as well, but
generally the discussions are some of the highest level
of signal to noise of any of the groups I've ever read.
Quite useful, all things considered.
Andy
--
Andy Nelson School of Mathematics
an...@maths.ed.ac.uk University of Edinburgh
http://maths.ed.ac.uk/~andy Edinburgh Scotland EH9 3JZ U. K.
Ken Plotkin
>I suggest somebody to setup an opposite website and ask for petition
>on "keeping Fortran alive", "hiring Fortran", "Teaching Fortran in
>Universirties", or something like that. Then all Fortraners can
[snip]
That's silly. The original post was a troll. The petition web site
is infrastructure for the troll. Did you follow the link back to his
home site? Clearly a person with varied interests, an odd sense of
humor, and a bit more free time than he knows what to do with. Kind
of unusual. Most trollers don't get that elaborate, and they don't
identify themselves.
I think Toon's line about a $699 license fee, while meant to be funny,
points to Fortran's aliveness. That's what Fortran users do. My
employer buys Fortran for every computer that needs it. I've bought
Fortran myself for personal use. The majority of posters here seem to
use commercial, paid-for Fortran compilers.
Checkbooks speak louder than any prank petition.
"Don't feed the trolls" posts do feed the trolls, so I regret my
action as a feeder. But more important than not feeding them is to
make sure we don't take them seriously.
Ken Plotkin
Gary L. Scott
My ISP(Fortran Library) won't let me host anything fancy without
charging me a bunch of extra money (even though my prior ISP had no such
restrictions at a cheaper price (at least initially it was cheaper)).
Since I have 3 other similar sites, I don't really want to spend any
more or at the moment have any extra time to set it up. I was looking
into automating the site submittals and adding a forum, but the ISP
won't allow me to run a database and if the hit rate exceeds some
nebulous value (I can't seem to pin this down but the support people
always bring this up when I ask if I can do something on this account)
they imply that they might charge me extra or suspend my account. It
currently averages around 3000/month (hits) and peaks at around
5000/month occasionally, which amazes me actually. The most annoying
part is that the site traffic logs keep filling up the disk space
allocation very fast and the counter macro then can't write/recreate the
counter data file. I've thought of changing ISPs again, but gee, all
that work.
Actually, if someone else would like to help with the maintenance
(incorporation of user requests/submissions), I'd welcome the help (It's
all manual, edited with Netscape 4/6/7). I'm WAY behind.
Maybe someday...when I retire...or get rich...I'll make a better site.
I did start developing a new one with Adobe GoLive, but I ran into the
above ISP restrictions.
>
> Tabon
--
Gary Scott
mailto:garysco...@ev1.net
Fortran Library
http://www.fortranlib.com
Support the GNU Fortran G95 Project: http://g95.sourceforge.net
Gary L. Scott
>
> Tabon <no...@hotmail.com> wrote:
> > I suggest somebody to setup an opposite website and ask for petition
> > on "keeping Fortran alive", "hiring Fortran", "Teaching Fortran in
> > Universirties", or something like that. Then all Fortraners can
> > explain their point of view about why they like Fortran and what they
> > expect from J3, Why it should be kept "hired" etc. One can also add
> > "success stories section", "donation to Free Software Project",
> > "Asking j3 members going faster" etc.
>
> I'm only being about 1/2 ironic when I say that this exists
> already,
>
> The forum is called comp.lang.fortran
>
> It also has another benefit that you didn't mention above
> that many folk come here and get their questions answered
> about `is this a bug in my code' and `what am I doing wrong
> here' etc. You can come here and lurk and learn a lot,
> or come and post and learn too. This being usenet, there
> are also those who come just to make noise as well, but
> generally the discussions are some of the highest level
> of signal to noise of any of the groups I've ever read.
Worst signal to noise ratio...I vote for any of the COMP.OS.OS2 news
groups...what absolute trash.
>
> Quite useful, all things considered.
>
> Andy
>
> --
> Andy Nelson School of Mathematics
> an...@maths.ed.ac.uk University of Edinburgh
> http://maths.ed.ac.uk/~andy Edinburgh Scotland EH9 3JZ U. K.
Matthew
mine nor is it my web site. I think the author's true intent is to
force J3 to make it a better language, rather than an amalgam of
poorly-designed (to say nothing of poorly implemented) 'advanced'
features (I'm reminded of the line from the Invader Zim cartoons: It's
not stupid! It's advaaaanced!) I think there are valid complaints
about Fortran, some of which have been echoed here, and that maybe if
we were a bit more proactive, such as the author of this site, we
might get something combining the best aspects of high-performance
scientific computing and software engineering. As it stands, I don't
think I would make that claim for Fortran as it stands now, even
though it is my language of choice and I've been using it for almost
20 years.
On another note, I find it interesting that a number of signers of
this this petition are from Colorado. One ventures to guess that the
numerical weather prediction/climate science groups in in the area
have major issues with Fortran as well, even though it is their stock
in trade.
Gary L. Scott
I observe mostly hyperbole in the commentary at the site, rather than
well thought out arguments. There is far more in favor of Ada over C++
in my opinion, yet Ada is clearly dying. Why don't they put up a site
promoting Ada instead of anti-promoting Fortran? Seems more worthwhile.
Duane Bozarth
>
> ...I think the author's true intent is to
> force J3 to make it a better language, rather than an amalgam of
> poorly-designed (to say nothing of poorly implemented) 'advanced'
> features (I'm reminded of the line from the Invader Zim cartoons: It's
> not stupid! It's advaaaanced!) I think there are valid complaints
> about Fortran, some of which have been echoed here, and that maybe if
> we were a bit more proactive, such as the author of this site, we
> might get something combining the best aspects of high-performance
> scientific computing and software engineering. As it stands, I don't
> think I would make that claim for Fortran as it stands now, even
> though it is my language of choice and I've been using it for almost
> 20 years.
I don't see this site will have any positive influence to accomplish the
goal(s) you've outlined--if that were the purpose, it seems to me to
much more productive to get fully involved and prepare/promote/defend
proposals that do those things as you (editorial, not personal) see most
fitting. Proposing fixes by abandoning it entirely or simply
criticizing w/o viable alternatives the existing/proposed standards does
nothing constructive imo.
beli...@aol.com
> Tabon <no...@hotmail.com> wrote:
> > I suggest somebody to setup an opposite website and ask for petition
> > on "keeping Fortran alive", "hiring Fortran", "Teaching Fortran in
> > Universirties", or something like that. Then all Fortraners can
> > explain their point of view about why they like Fortran and what they
> > expect from J3, Why it should be kept "hired" etc. One can also add
> > "success stories section", "donation to Free Software Project",
> > "Asking j3 members going faster" etc.
>
> I'm only being about 1/2 ironic when I say that this exists
> already,
>
> The forum is called comp.lang.fortran
>
> It also has another benefit that you didn't mention above
> that many folk come here and get their questions answered
> about `is this a bug in my code' and `what am I doing wrong
> here' etc. You can come here and lurk and learn a lot,
> or come and post and learn too. This being usenet, there
> are also those who come just to make noise as well, but
> generally the discussions are some of the highest level
> of signal to noise of any of the groups I've ever read.
>
> Quite useful, all things considered.
>
> Andy
I agree with Tabon's suggestion to build a Fortran advocacy site, but
I think that SHOWING what Fortran can do is better than just TELLING
people Fortran is good (and MUCH better than telling them
C++/Matlab/Java are bad). People could post profiles explaining where
they work, what they use Fortran for, and why they use Fortran for
that part of their work. They could provide links to personal sites
with their code and results, where feasible. I agree with Andy Nelson
that comp.lang.fortran is informative, but people usually do not use
it to describe their work in detail, except when they have a problem!
Fortran continues to suffer from a negative network effect. Very few
Fortran books are found in bookstores (but there are plenty of good
books on Amazon), and it gets little exposure in the IT media. Many
programmers and their managers think "nobody still uses it" and thus
do not consider it for projects it is suited to.
Since there are many Fortran programmers on c.l.f. using the plethora
of compilers on Linux, may I suggest that someone submit an article to
Linux Journal http://www.linuxjournal.com comparing the compilers or
discussing Fortran 95 in general? The fact that Intel's Linux compiler
is free for noncommercial use could be highlighted. The progress of
the G95 project could be discussed, and there should definitely be an
article published when G95 is complete. My Linux Fortran experience
consists of a "hello world" program using g77 on Suse 9.0. so I'm not
qualified to write the article. Linux Magazine at
http://www.linux-mag.com/ should also be considered -- they had an
article in the June 2003 issue covering an application of F90.
Other possible outlets for articles on Fortran are
Computers in Science and Engineering, http://www.computer.org/cise/ ,
Dr. Dobb's Journal http://www.ddj.com , and ClusterWorld (devoted to
high-performance parallel computing)
http://www.clusterworld.com/issues.shtml . I know the first two have
had articles where Fortran was mentioned, sometimes unfairly :).
There are enough good books on the Fortran 95 language. What I do not
see are recent introductory books on numerical methods in Fortran,
which would be used as college textbooks for introductory courses
given to engineering and science majors. Search Amazon for "numerical
methods Matlab" and you find many recent textbooks, and there a few
hits for "numerical methods C++". Search for "numerical methods
Fortran" and you get old books featuring Fortran 77 and Fortran IV,
none using Fortran 90 or 95. Of course, most Fortran textbooks cover
some numerical methods -- by law, it must be shown how to do Gaussian
elimination in Fortran :). But the main focus is on the Fortran
language, as it should be.
Publishers might not be receptive to a "Numerical Methods in Fortran
95" textbook, because Matlab dominates that niche. But a numerical
methods book covering BOTH Matlab and Fortran 95 might work. I think
it is important to teach students a language they will have access to
after college, without spending close to $2000 for a commercial Matlab
license!
Dan Tex1
>From: for...@hotmail.com (Matthew)
>Date: 2/21/04 11:05 AM Pacific Standard Time
>Message-id: <f61ad277.04022...@posting.google.com>
I saw a few problems with the website and it's petition:
It was essentially "non-constructive". It didn't advocate making Fortran
better. It didn't suggest a viable replacement language either. It was very
ambiguous about it's goal ( other than, that Fortran should be declared dead ).
I wasn't sure if it was advocating the death of Fortran so that C++ or Ada or
Java or some other pre-existing language could take it's place or because it
was hoped that someone, somewhere would invent a brand new
scientific/numerically oriented language to take it's place.
If there is a pre-existing language that should take Fortran's place... that
needs to be suggested and logically backed up somehow. As for hoping for a
"new" language, that's just ideallistic dreaming.
Now... on to some of the posted statements on the website. Most of them were
both irrelevant and even highly ignorant. If you're going to post statements
from people advocating the death of Fortran ( as reason's for the needed death
), you at least have to have people who know a LOT more about what they are
talking about. I'm no Fortran expert and I had no problem seeing the lack of
logic and understanding in most of the posted statements.
Dan :-)
Dr Ivan D. Reid
wrote in <403780D5...@ev1.net>:
> Worst signal to noise ratio...I vote for any of the COMP.OS.OS2 news
> groups...what absolute trash.
You haven't read uk.rec.motorcycles then! Even if a thread starts
up about motorcycles (and they are rare), they're usually off-topic within
three posts. Great place to find non-motorcycling info, tho'...
--
Ivan Reid, Electronic & Computer Engineering, ___ CMS Collaboration,
Brunel University. Ivan...@brunel.ac.uk Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
Greg Lindahl
Matthew <for...@hotmail.com> wrote:
> On another note, I find it interesting that a number of signers of
> this this petition are from Colorado. One ventures to guess that the
> numerical weather prediction/climate science groups in in the area
> have major issues with Fortran as well, even though it is their stock
> in trade.
Every community that heavily uses Fortran has at least some issues
with it, and often a vocal minority that really doesn't like it.
But, in that field, it's the only game in town.
-- greg
Gary L. Scott
I certainly have issues with it. But I have issues with Ada, C, C++,
Pascal, Jovial, >>>PERL<<<, REXX, HTML, Script/GML, IBM JCL, VOS CL,
DCL, APL, Java. Almost every programming "language" has some particular
feature that I really like or really don't like about it. I've used and
become familiar with enough different languages that I think I see a lot
of the warts (certainly not in a sophisticated way, it isn't my area of
expertise). Fortran 95 really isn't that bad in comparison. But I
would change only a tiny number of things and add only a tiny number of
things, all but two extremely small and the largest one potentially
highly isolated if implemented my way (bit string data type with robust
data type support (implemented in software where hardware does not
support). I think we finally need a variable length string data type,
but I'm not quite happy with the VS module implementation. Well, now
that I think of it, I would add some features to aid "system"
programming and multi-threading, but I would not push too hard for
those. Unfortunately, I don't see any others expressing any interest at
all in any of the things I'm interested in, so I'm not holding my
breath. But then, I'm also not abandoning Fortran because of it.
>
> But, in that field, it's the only game in town.
>
> -- greg
James Giles
...
> [...] Fortran 95 really isn't that bad in comparison. But I
> would change only a tiny number of things and add only a tiny number of
> things, all but two extremely small and the largest one potentially
> highly isolated if implemented my way (bit string data type with robust
> data type support (implemented in software where hardware does not
> support). I think we finally need a variable length string data type,
> but I'm not quite happy with the VS module implementation. Well, now
> that I think of it, I would add some features to aid "system"
> programming and multi-threading, but I would not push too hard for
> those. Unfortunately, I don't see any others expressing any interest at
> all in any of the things I'm interested in, so I'm not holding my
> breath. But then, I'm also not abandoning Fortran because of it.
I'm interested in all that stuff, plus a simple form of generic
programming. I don't think the language needs many features to
aid in "system" programming beyond those you mentioned. Bit
types (string or not) being the most important. Bit-resolution KINDs
of integers would be sufficient. I/O not tied to any record structure
would also be useful for writing things like compilers and loaders
(most Fortran implementations already have such things, and the
need for them as well as their characteristics would probably
be platform specific anyway - so maybe standardizing such I/O
is meaningless). Other things, such as memory mapped devices or
access to specialized instructions, would definitely be platform
specific and not within the scope of a language standard at all.
Of course, your definition of "system" programming may be different
than mine. My definition is that the language has all the capabilities to
access the basic features of the hardware. You may believe that the
ability to interoperate with C (or some similar language) is part of
the definition of "system" programming.
--
J. Giles
Ken Plotkin
>I agree with Tabon's suggestion to build a Fortran advocacy site, but
>I think that SHOWING what Fortran can do is better than just TELLING
>people Fortran is good (and MUCH better than telling them
>C++/Matlab/Java are bad). People could post profiles explaining where
>they work, what they use Fortran for, and why they use Fortran for
[snip]
Can the site include a page on water, pointing out the benefit of
drinking clean water rather than raw sewage?
The original post and petition are a troll. There is no need to
respond to it, other than perhaps discuss its artistic merits relative
to other trolls. Maybe a zinger or two about the troller's personal
pharmaceutical and hygeinic habits. But it is NOT something that
needs a counter attack.
>Fortran continues to suffer from a negative network effect. Very few
>Fortran books are found in bookstores (but there are plenty of good
>books on Amazon), and it gets little exposure in the IT media. Many
>programmers and their managers think "nobody still uses it" and thus
>do not consider it for projects it is suited to.
F*** them. Their loss.
I work in a modestly competitive industry. I *love* it when I see the
competition screwing up.
Ken Plotkin
Gary L. Scott
I've never quite understood the overall value or method of
implementation of a bit kind. How do you envision that being
implemented? One of my needs is to be able to create "packed" data
types...meaning a 1 bit flag followed by an 11 bit real value followed
by a 24 bit unsigned integer followed by ... packed to the nearest bit
in memory (must do my own padding if needed of course). In addition, I
want to be able to specify/define MSB/LSB, mantissa/exponent bit
subfields, and range limits and have the compiler keep track and to
generate "software" error conditions for overflows, etc. I have (or had
if I can't get some of them off that 9-track tape) routines for doing
all those things, it really doesn't seem like a major task to me to
implement something very useful.
>
> Of course, your definition of "system" programming may be different
> than mine. My definition is that the language has all the capabilities to
> access the basic features of the hardware. You may believe that the
> ability to interoperate with C (or some similar language) is part of
> the definition of "system" programming.
I personally don't view C interoperability to be the final answer to
system programming in Fortran. I see it as very valuable though.
>
> --
> J. Giles
James Giles
> James Giles wrote:
...
> I've never quite understood the overall value or method of
> implementation of a bit kind. How do you envision that being
> implemented? One of my needs is to be able to create "packed" data
> types...meaning a 1 bit flag followed by an 11 bit real value followed
> by a 24 bit unsigned integer followed by ... packed to the nearest bit
Exactly what I have in mind. Try the following possible syntax
to describe the internal packing of IEEE floats:
Type aReal
integer(one_bit) :: sign
integer(eight_bits) :: exponent
integer(twenty_three_bits) :: significand
End type aReal
That's all packed into 32-bits. It requires bit resolution KINDs.
Using an UNSIGNED integer in this instance would be good too.
This is much easier than having to remember how much to shift
or which bits to extract in a bit substring. You just have names
for the relevant components.
I don't know what an 11 bit real is, but if you'll give an example
we could discuss it.
>> Of course, your definition of "system" programming may be different
>> than mine. My definition is that the language has all the capabilities
>> to access the basic features of the hardware. You may believe that the
>> ability to interoperate with C (or some similar language) is part of
>> the definition of "system" programming.
>
> I personally don't view C interoperability to be the final answer to
> system programming in Fortran. I see it as very valuable though.
It's only even relevant as long as systems are written in C derived
languages. Since that's a mistake anyway, I look forward to the day
when systems are available that aren't written in C, and even systems
for which there are no C implementations present.
--
J. Giles
beli...@aol.com
<SNIP>
> Can the site include a page on water, pointing out the benefit of
> drinking clean water rather than raw sewage?
Yes. The U.S. Geological Survey writes much of its water resource
software in Fortran -- see http://water.usgs.gov/software/ .
>
> The original post and petition are a troll. There is no need to
> respond to it, other than perhaps discuss its artistic merits relative
> to other trolls. Maybe a zinger or two about the troller's personal
> pharmaceutical and hygeinic habits. But it is NOT something that
> needs a counter attack.
I had the idea for a site where people discuss how they use Fortran in
their work before this thread started. Such a site would not need to
refer to the anti-fortran petition to make sense.
> >Fortran continues to suffer from a negative network effect. Very few
> >Fortran books are found in bookstores (but there are plenty of good
> >books on Amazon), and it gets little exposure in the IT media. Many
> >programmers and their managers think "nobody still uses it" and thus
> >do not consider it for projects it is suited to.
>
> F*** them. Their loss.
It could be your loss too, if your manager tells you rewrite all your
code in C++ because of the perception I described above. Academics and
others who put their code in the public domain would like to see their
work widely used. It is society's loss when the best tool for a job is
not even considered.
Duane Bozarth
>
> Worst signal to noise ratio...I vote for any of the COMP.OS.OS2 news
> groups...what absolute trash.
Well, for the last month or so, Timmy's been absent so they've actually
been pretty much on topic...
Gary L. Scott
>
> Gary L. Scott wrote:
> > James Giles wrote:
> ...
> > I've never quite understood the overall value or method of
> > implementation of a bit kind. How do you envision that being
> > implemented? One of my needs is to be able to create "packed" data
> > types...meaning a 1 bit flag followed by an 11 bit real value followed
> > by a 24 bit unsigned integer followed by ... packed to the nearest bit
> > in memory (must do my own padding if needed of course). [...]
>
> Exactly what I have in mind. Try the following possible syntax
> to describe the internal packing of IEEE floats:
>
> Type aReal
> integer(one_bit) :: sign
> integer(eight_bits) :: exponent
> integer(twenty_three_bits) :: significand
> End type aReal
>
> That's all packed into 32-bits. It requires bit resolution KINDs.
> Using an UNSIGNED integer in this instance would be good too.
> This is much easier than having to remember how much to shift
> or which bits to extract in a bit substring. You just have names
> for the relevant components.
That's sort of what I want. But I think we can do (and I need) much
more. Something like:
http://www.fortranlib.com/bitstring.txt
Of course there are some obvious issues with this, but if the above is
all I can get, it's a start. I can live with some rules like "you can't
put the sign bit in the middle" if that doesn't make sense (I've never
personally ran across any definitions with sign bit not at the most
significant bit position, but maybe they exist).
>
> I don't know what an 11 bit real is, but if you'll give an example
> we could discuss it.
Problem is we define our own data types, which bits are the exponent,
whether the bit order is from left to right or right to left (depending
on what the receiving system requires or the transmitting system
provides), total number of bits in the "real" value. We have full
flexibility to define these since we must pack them into a serial data
stream as efficiently as possible. We of course use the true signal
range (be it a radar target return or TOS estimate) and encode it the
most efficient way in terms of bandwidth utilization, precision, and
signal range required. I could give you an example of an 11 bit real,
but next time it might be a 13 bit real. I'm looking for a truely
imaginitive and flexible bit <string> data type (not that I'm an expert
on imaginitive and flexible or that I'm even coherent much of the
time.).
Calculations are of course performed using native types, so my bit data
type is more or less just a container to hold the final value by using
normal assignment syntax to assign the results to the components of the
bit string/object similar to the way you do above. I would never
directly manipulate the sign, exponent, mantissa, etc. parts of the
definition, I would simply assign from an internal real type to the
appropriate bit string/object real component and type conversion would
be performed by the compiler (with appropriate error
detection/reporting). That's probably too much huh?
>
> >> Of course, your definition of "system" programming may be different
> >> than mine. My definition is that the language has all the capabilities
> >> to access the basic features of the hardware. You may believe that the
> >> ability to interoperate with C (or some similar language) is part of
> >> the definition of "system" programming.
> >
> > I personally don't view C interoperability to be the final answer to
> > system programming in Fortran. I see it as very valuable though.
>
> It's only even relevant as long as systems are written in C derived
> languages. Since that's a mistake anyway, I look forward to the day
> when systems are available that aren't written in C, and even systems
> for which there are no C implementations present.
>
> --
> J. Giles
Greg Chien
> Try the following possible syntax
> to describe the internal packing of IEEE floats:
>
> Type aReal
> integer(one_bit) :: sign
> integer(eight_bits) :: exponent
> integer(twenty_three_bits) :: significand
> End type aReal
>
> That's all packed into 32-bits. It requires bit resolution KINDs.
> Using an UNSIGNED integer in this instance would be good too.
Having been using the following since 1978 K&R C (ref. p. 137):
struct {
unsigned sign : 1;
unsigned exponent : 8;
unsigned significand : 23;
} a Real;
But, K&R stated (warned) that "Fields are assigned right-to-left on the
PDP-11, left-to-right on other machines." Fortran's bit model (from right
to left) is good for each field, but does it guarantee binary portability
when the 32 bit typed value is written into files, transferred across the
wire, etc.?
> It's only even relevant as long as systems are written in C derived
> languages. Since that's a mistake anyway, I look forward to the day
> when systems are available that aren't written in C, and even systems
> for which there are no C implementations present.
You are hitting an area (system programming) where C really shines.
Wonder how many Fortran compilers or their run-time library are written in
C or its derivatives. There was a time when systems were built in
Fortran, but wishing it to come back seems to have a very slim chance. I
wouldn't hold my breath ;-)
--
Best Regards,
Greg Chien
e-mail: remove n.o.S.p.a.m.
http://protodesign-inc.com
Ken Plotkin
>I had the idea for a site where people discuss how they use Fortran in
>their work before this thread started. Such a site would not need to
>refer to the anti-fortran petition to make sense.
Doesn't this newsgroup serve that purpose? Don't the web sites of the
makers of Fortran compilers promote the language?
>It could be your loss too, if your manager tells you rewrite all your
>code in C++ because of the perception I described above. Academics and
>others who put their code in the public domain would like to see their
>work widely used. It is society's loss when the best tool for a job is
>not even considered.
That is part of the evolution and (in the long run) deterioration of
societies.
Ken Plotkin
Athanasios Migdalas
>> Andy
>
> Since there are many Fortran programmers on c.l.f. using the plethora
> of compilers on Linux, may I suggest that someone submit an article to
> Linux Journal http://www.linuxjournal.com comparing the compilers or
> discussing Fortran 95 in general? The fact that Intel's Linux compiler
> is free for noncommercial use could be highlighted. The progress of
> the G95 project could be discussed, and there should definitely be an
> article published when G95 is complete. My Linux Fortran experience
> consists of a "hello world" program using g77 on Suse 9.0. so I'm not
> qualified to write the article. Linux Magazine at
> http://www.linux-mag.com/ should also be considered -- they had an
> article in the June 2003 issue covering an application of F90.
>
The UK journal <<Linux Format>> has this month several pages devoted to
Fortran.
/Sakis
James Giles
...
> But, K&R stated (warned) that "Fields are assigned right-to-left on the
> PDP-11, left-to-right on other machines." Fortran's bit model (from
> right to left) is good for each field, but does it guarantee binary
> portability when the 32 bit typed value is written into files,
> transferred across the wire, etc.?
I was giving an example of how to define packed, bit-resolution
structures, not necessarily how to portably describe IEEE floats.
On machines with different addressing, such things are obviously
platform dependent. Being able to specify bit-resolution fields
is a necessary first step.
...
> You are hitting an area (system programming) where C really shines.
Well, it's a area where C dimly glows. C was always a very bad
choice for a system programming language. The system is the one
software component of your programming environment that every
user of the platform depends on. For no other bit of software is
it as important to be completely reliable and legible. It must be
as easy as possible to verify the correctness of code. The last
thing you want to use is the most pitfall-ridden, arcane, peculiar
and illegible language you can find.
I'd like to see a time when C (and other C derived languages) are
gone for good. There have been languages designed specifically
for system development that are actually pretty good.
--
J. Giles
Greg Chien
> There have been languages designed specifically
> for system development that are actually pretty good.
What are they? How come they are not popular?
Gary L. Scott
>
> "James Giles" wrote
> > There have been languages designed specifically
> > for system development that are actually pretty good.
>
> What are they? How come they are not popular?
Ada? Jovial? Popularity doesn't imply good for what they're used for.
But these two are used precisely for lots of system programming in
defense. Of course, we've now given in to the "cheap labor" syndrome
where the plethora of C programmers is starting to hold down salaries
because "good" programmers are now a dime a dozen. If not for the
security (and logistics) issues, I'd expect many companies to try to
outsource these software jobs overseas...
>
> --
> Best Regards,
> Greg Chien
> e-mail: remove n.o.S.p.a.m.
> http://protodesign-inc.com
James Giles
> "James Giles" wrote
>> There have been languages designed specifically
>> for system development that are actually pretty good.
>
> What are they? How come they are not popular?
Turing+ (or was it Turing pro) was one. I understand
they have since added OOP to it. The others are only
in the dim recesses of my mind at the moment and I'd
have to do some research to get their names.
Not that Turing was perfect either. There were several
things they did that were later shown to be bad in productivity
experiments: run-on comments of the /* ...*/ variety, run-on
statements that could wrap across the end of line without a
continuation character, case-sensitive identifiers, nested
scopes with automatic host association, etc. And, they
did some things I don't personally care for, but can find
no objective evidence against. It was designed during
Pascal's 15 minutes of fame and it's remarkable how many
of Pascal's failings they avoided. But, it was uniformly
better than C in nearly every respect in which they differ.
As for popularity: I've never noticed any correlation
between quality and popularity in programming tools.
Not in languages, not in operating systems, not anywhere.
I have theories why that might be so, but no evidence.
--
J. Giles
bv
>
> I suggest somebody to setup an opposite website and ask for petition
> on "keeping Fortran alive", "hiring Fortran", "Teaching Fortran in
No need, site's already there -- http//netlib.org -- and is driving the
computing wanabes nuts. Imagine, a zero promoed site drawing more hits
than mega budget MSN has customers. I hear, it's driving Gates wild
(wonder why CVF lost VS license)!?
Greg Chien
> As for popularity: I've never noticed any correlation
> between quality and popularity in programming tools.
> Not in languages, not in operating systems, not anywhere.
> I have theories why that might be so, but no evidence.
I haven't found direct correlation between quality and popularity, either.
However, I am a believer of natural selection. Quality programming tools
shall be tested/proven by some population, not just kept within a elite
group of users. In addition, I believe one of the Fortran standardization
efforts is to gain popularity.
Regarding Fortran 2003 advocacy, I think the best way to counter the
petition is to contribute your spare time to getting a standard conforming
compiler up and running, not being side-tracked by these nay-sayers.
Gary L. Scott
So is this just too wacky? Too overboard (knowing that I'm not fully
versed in floating point issues and that it needs more work)? It seems
to me like just a small number of functions to implement it.
Gary L. Scott
Lahey has gone quite a ways in that respect, in fact they jumped the gun
on a few features that were later removed. They haven't decided yet
whether to leave them in or not.
>
> --
> Best Regards,
> Greg Chien
> e-mail: remove n.o.S.p.a.m.
> http://protodesign-inc.com
James Giles
...
> I haven't found direct correlation between quality and popularity,
Natural selection is a complex process. It's not "survival
of the fittest". As I recall, even Darwin later regretted
the implications of that phrase (like there's some kind of
inevitability about it).
It's really "survival of the adequate". Unless the pressures
are really strong, "adequate" can be pretty mediocre. That's
how "punctuated equilibrium" works. In the good times
(which can be short, or last a thousand generations) lots of
genetic diversity can build up. Much of that diversity is for
non-optimal characteristics, but since there's little pressure
on that aspect of the species, these feature remain. Then,
climate changes, mountains rise, a volcano or new sea blocks
traditional routes of migrations, whatever ... the pressure
is on. That's when large changes in the species occur.
Those features that individually were not decisive before
are now paramount. The survivors have a concentrated
set of features that might previously have been rare and
spread out. They may have eliminated lots of features
that were previously common. The species is significantly
different. So much so, that it may be permanently distinct
from those parts of the old species that were spared the
emergency.
Back to languages:
As long as non-programmer managers can mandate language
use, or ivory tower professors can decide what languages
are taught, or government agencies can specify language and
system on an agency-wide scale, the competitive pressure
on language design remains low. I'm not sure what kind of
emergency would spur rapid change. The only rapid changes
I've seen in the industry were fads (or the result of those very
factors that are currently stultifying: like government mandates),
and not correlated to language quality.
--
J. Giles
J. F. Cornwall
> Ken Plotkin <kplo...@nospam-cox.net> wrote in message news:<vstf30l9u1lvsrki4...@4ax.com>...
>
> <SNIP>
>
>>Can the site include a page on water, pointing out the benefit of
>>drinking clean water rather than raw sewage?
>
>
> Yes. The U.S. Geological Survey writes much of its water resource
> software in Fortran -- see http://water.usgs.gov/software/ .
>
Yes, but much of our software is still written in F77 style with none of
the modern features... Some programs are hopefully written in more
modern dialects, but the programs I deal with are still in 77.
Jim Cornwall
Greg Lindahl
To be fair, you shouldn't count a noxious troll (like Dave Frank in
comp.lang.pl1) against a newsgroup -- it's not their fault.
-- greg
Dan Nagle
On Sun, 22 Feb 2004 23:17:14 GMT, "Greg Chien"
<gch...@n.o.S.p.a.m.protodesign-inc.com> wrote:
>"James Giles" wrote
>> There have been languages designed specifically
>> for system development that are actually pretty good.
>
>What are they? How come they are not popular?
Because they weren't given away for free with the source code
to universities for years, from the 1970s henceforward?
Because they weren't the basis for a significant 1980's
programming language research project?
Note that there's a good deal of luck in Natural Selection.
Also note that Sexual Selection is part of the process, too. :-)
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
Greg Chien
> It's really "survival of the adequate". Unless the pressures
> are really strong, "adequate" can be pretty mediocre.
To summarize: "Mediocrity rules!" How sad :-(
Now, who's going to devise a grand marketing plan for F2003? For starter,
I think the name should be changed to F2X. Perhaps, we should keep
"F2003" because, um..., it sounds MEDIOCRE. ;-)
Les
"Greg Chien" <gch...@n.o.S.p.a.m.protodesign-inc.com> wrote in message
news:62o_b.380086$xy6.2073902@attbi_s02...
> "James Giles" wrote
> > It's really "survival of the adequate". Unless the pressures
> > are really strong, "adequate" can be pretty mediocre.
> [snip]
>
> To summarize: "Mediocrity rules!" How sad :-(
>
> Now, who's going to devise a grand marketing plan for F2003? For starter,
> I think the name should be changed to F2X. Perhaps, we should keep
> "F2003" because, um..., it sounds MEDIOCRE. ;-)
>
So to be *really* modern perhaps it should be called F++ or F#
;-)
Les
Rich Townsend
> "Greg Chien" <gch...@n.o.S.p.a.m.protodesign-inc.com> wrote in message
> news:62o_b.380086$xy6.2073902@attbi_s02...
>
>>"James Giles" wrote
>>
>>>It's really "survival of the adequate". Unless the pressures
>>>are really strong, "adequate" can be pretty mediocre.
>>
>>[snip]
>>
>>To summarize: "Mediocrity rules!" How sad :-(
>>
>>Now, who's going to devise a grand marketing plan for F2003? For starter,
>>I think the name should be changed to F2X. Perhaps, we should keep
>>"F2003" because, um..., it sounds MEDIOCRE. ;-)
>>
>
>
> So to be *really* modern perhaps it should be called F++ or F#
Or even F2XP...
Rich
Greg Chien
> "Greg Chien" wrote
> > Now, who's going to devise a grand marketing plan for F2003?
> > For starter, I think the name should be changed to F2X.
>
2X (two times) is greater than ++ or ++++ (#) :-)
Richard Maine
> ...they are fully aware...
Ah. We have here another mind reader. Always good to see
people with such absolute certainty that they know exactly
what others are thinking. Even better when one can smear
a whole group of people at once. Shall we have racial
characterizations next? I got the silly misimpression
that J3 had multiple members with different thoughts and
opinions, sometimes disagreeing with each other quite
vehemently. I even thought that one of the reasons for
having committees for standards was to help bring in multiple
viewpoints. But I'm evidently too close to see things with
this poster's obvious objective clarity.
Or do tirades like that tell us more about the poster
than the target?
--
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
James Giles
> "James Giles" wrote
>> It's really "survival of the adequate". Unless the pressures
>> are really strong, "adequate" can be pretty mediocre.
> [snip]
>
> To summarize: "Mediocrity rules!" How sad :-(
>
> Now, who's going to devise a grand marketing plan for F2003? For
> starter, I think the name should be changed to F2X. Perhaps, we should
> keep "F2003" because, um..., it sounds MEDIOCRE. ;-)
I still like F2kV. kiloVolts sounds powerful.
--
J. Giles
Gerry Thomas
"Les" <l.neilson@ace_programmer_cad.co.uk> wrote in message
news:403a2150$0$17855$fa0f...@lovejoy.zen.co.uk...
>
> "Greg Chien" <gch...@n.o.S.p.a.m.protodesign-inc.com> wrote in message
> news:62o_b.380086$xy6.2073902@attbi_s02...
> > "James Giles" wrote
> > > It's really "survival of the adequate". Unless the pressures
> > > are really strong, "adequate" can be pretty mediocre.
> > [snip]
> >
> > To summarize: "Mediocrity rules!" How sad :-(
> >
> > Now, who's going to devise a grand marketing plan for F2003? For
starter,
> > I think the name should be changed to F2X. Perhaps, we should keep
> > "F2003" because, um..., it sounds MEDIOCRE. ;-)
> >
>
> So to be *really* modern perhaps it should be called F++ or F#
>
F# is gone to the dogs
http://developers.slashdot.org/article.pl?sid=02/06/08/0324233&tid=156
--
Ciao,
Gerry T.
______
"Visual Fortran is part of the Microsoft family of Visual Tools." -- In
DIGITAL Visual Fortran, Getting Started, 1998.
Greg Lindahl
Les <l.neilson@ace_programmer_cad.co.uk> wrote:
>So to be *really* modern perhaps it should be called F++ or F#
There's already been F--: a parallel extension that's much stupider,
but far more practical, than HPF.
But, alas, it's now renamed Co-Array Fortran.
Stupid. Fast. Yum.
-- greg
Toon Moene
> So to be *really* modern perhaps it should be called F++ or F#
I vote for "C minor". [ OK, I had to look it up: TA TA TA DOOO ]
--
Toon Moene - mailto:to...@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)
analyst41
Very Interesting. FORTRAN has always been the ugly duckling once the
discipline of Computer Science was born. I assume that prior to
fortran 77, only spaghetti code was possible in fortran - so much so
that pre-fortran77 Fortran is practically synonymous with spaghetti.
In my understaning is right, the three failed Fortran-killers -
ALGOL,PASCAL and PL/I were designed specifically to remedy Fortran's
perceived deficiencies.
The question is why was Fortran rendered dead (or near-dead) by C (and
its descendants) in the commercial domain during a time frame starting
in the the late 1970s and culminating sometime in the early 1990s ?
I think irrational fads of managers cannot explain it completely.
Fortran stopped addressing real needs that arose in 1980s. The
community allowed a fatal split in interests to develop -
academic/government/non-profit users versus commercial users.
Commercial users needed "dirty" things like database APIs, command
line args, ability to process large files as byte-streams - and the
non-profit guys pulled the sheets right over their head and said "I'm
alright Jack".
FInally, after the overwhelming mass of commercial users had defected
to C TO KEEP THEIR JOBS - the horror called f90 is unleashed on the
world, STILL WITHOUT what commercial users wanted. To add sheer
idiocy to injury, Fortran now wants to be "Object Oriented".
I can see why Object orientation might be helpful for GUIs, after all
GUI programming is tedious, brain-numbing stuff with things that are
very similar and some kind of coding method that can put down an
ellipse or put down a circle without having to duplicate code could be
useful to the wretches doing GUI coding.
"Object-Orientation for quantitative coding" - I don't see how one
could get any dumber.
Think of this
Minimizing a convex function, minimizing a linear function (both
convex and concave) and minimizing a concave function subject to
constraints - are for all practical purposes unrelated problems.
What good is it to define a "class" or whatever of fucntions by their
concavity/convexity and try to develop generic algortihms.
And finally, the oft-quoted advantage of "generic programming" that
you don't need to duplicate code for sorting real numbers and for
sorting integers - is this trivial gain worth increasing the
compiler's complexity ?
I am CERTAIN that f90-f95-f2003 are all deader than dodoes - just
about all the wrong features of f77 were "improved" until a bloated
obscenity was unleashed on the public - and finally somebody has
declared that the emperor has no clothes.
Richard Maine
> I assume that prior to
> fortran 77, only spaghetti code was possible in fortran - so much so
> that pre-fortran77 Fortran is practically synonymous with spaghetti.
That assumption is supported neither by facts nor logic. Innumerable
counter-examples exist, as should be expected.
Good programming style has much more to do with the programmer
than with the language. A sufficiently good programmer can produce
well-designed code in pretty much any language. A sufficiently bad
programmer can make a mess in any language. Examples of both abound
in all languages. Language characteristics can facilitate or hinder
good style, perhaps quite strongly, but they do not determine it.
It is hard for me to write the above without sounding trite because
these things are all so well-accepted as to constitute cliches.
Claims that language choice is the determining element to good style
are pretty much nonstarters in any serious or reasoned discussion.
They are more in the domain of usenet flame wars. But then, I suppose....
E. Robert Tisdale
> The question is why was Fortran rendered dead (or near-dead)
> by C (and its descendants) in the commercial domain
> during a time frame starting in the the late 1970s
> and culminating sometime in the early 1990s?
Because C compilers were bundled with UNIX operating systems.
UNIX users and administrators were obliged to learn C
so that they could maintain their UNIX operating systems.
K&R expected programmers to use Fortran for numerical applications
but Fortran compilers were expensive options that C programmers
could not afford so they wrote everything in C instead.
> I think irrational fads of managers cannot explain it completely.
> Fortran stopped addressing real needs that arose in 1980s.
> The community allowed a fatal split in interests to develop -
> academic/government/non-profit users versus commercial users.
> Commercial users needed "dirty" things like database APIs,
> command line arguments, ability to process large files as byte-streams -
> and the non-profit guys pulled the sheets right over their head
> and said "I'm alright Jack".
No. The problem is that Fortran settled into a profitable
"special purpose computing" niche -- numerical programming --
and neglected all of the features
that a "general purpose programming" language requires.
The *fatal* flaw in Fortran 77
was the failure to standardize free storage management.
There is no practical way to write portable Fortran 77 programs
that can allocate the required memory at run time.
This means that every user must also be a Fortran 77 programmer
who can modify the code to allocate memory "statically"
and recompile the program.
> Finally, after the overwhelming mass of commercial users had defected
> to C TO KEEP THEIR JOBS - the horror called f90 is unleashed
> on the world, STILL WITHOUT what commercial users wanted.
> To add sheer idiocy to injury,
> Fortran now wants to be "Object Oriented".
But Object Oriented Fortran is certainly what "commercial users" want.
> I can see why Object orientation might be helpful for GUIs, after all
> GUI programming is tedious, brain-numbing stuff with things that are
> very similar and some kind of coding method that can put down an
> ellipse or put down a circle without having to duplicate code
> could be useful to the wretches doing GUI coding.
But what if your application needs a GUI?
Practically speaking, you are forced to use another language --
Java, C++, C, etc.
And, if you already know Java, C++ or C, why would you learn Fortran
just to write the numerical kernel for your application program?
> "Object-Orientation for quantitative coding" -
> I don't see how one could get any dumber.
And that's your problem. You don't see.
>
> Think of this
>
> Minimizing a convex function, minimizing a linear function (both
> convex and concave) and minimizing a concave function subject to
> constraints - are for all practical purposes unrelated problems.
>
> What good is it to define a "class" or whatever of functions
> by their concavity/convexity and try to develop generic algorithms.
>
> And finally, the oft-quoted advantage of "generic programming"
> that you don't need to duplicate code
> for sorting real numbers and for sorting integers -
> Is this trivial gain worth increasing the compiler's complexity?
All of the immediately above is blither.
The first Object Oriented Computer Programming Language (Simula)
was designed specifically for numerical simulation.
> I am CERTAIN that f90-f95-f2003 are all deader than dodos -
> just about all the wrong features of f77 were "improved"
> until a bloated obscenity was unleashed on the public -
> and finally somebody has declared that the emperor has no clothes.
It appears that you have been sucked into the myth that
"a simpler computer programming language will make problems simpler."
It will not.
Large, complicated problems are more easily solved
by computer programming languages with large complicated feature sets.
You should expect computer programming languages to get more complicated
as the problems that we try to solve get more complicated.
analyst41
> anal...@hotmail.com (analyst41) writes:
>
> > I assume that prior to
> > fortran 77, only spaghetti code was possible in fortran - so much so
> > that pre-fortran77 Fortran is practically synonymous with spaghetti.
>
> That assumption is supported neither by facts nor logic. Innumerable
> counter-examples exist, as should be expected.
Please be so kind as to furnish ONE example of non-trivial Fortran
code written in the 1960s that you would consider "good" code.
Dan Nagle
It's called f03 because 2003 was the year when
the technical contents were fixed. Typos etc only
have been changed (or proposed to be changed) after then.
The name was set by a WG5 vote: I don't believe marketing
was a factor.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
Greg Chien
> It's called f03 because 2003 was the year when
> the technical contents were fixed. Typos etc only
> have been changed (or proposed to be changed) after then.
I thought it was F2003? F03 has the year-2000 problem :-)
> The name was set by a WG5 vote: I don't believe marketing
> was a factor.
That could be the problem ;-)
Richard Maine
> Please be so kind as to furnish ONE example of non-trivial Fortran
> code written in the 1960s that you would consider "good" code.
No thanks. I don't keep lots of codes from that era or citations to
support such points handy. If I had a handy sample, I wouldn't want
to waste the time to analyze and place it in appropriate context.
I'll save my time for more worthwhile pursuits than trying to disabuse
people of their prejudices. If you want to persist in such a
viewpoint, I don't see why I should waste my time in trying to
convince you, which wouldn't work anyway. But don't expect to be
taken very seriously in much of anything.
beli...@aol.com
informative and detailed rebuttal -- see
http://www.fortranstatement.com/Site/responses.html . An FAQ has also
been added.
Ken Plotkin
wrote:
>Please be so kind as to furnish ONE example of non-trivial Fortran
>code written in the 1960s that you would consider "good" code.
Was the IBM Scientific Subroutine library written in the 1960s? Or
was that 1950s?
I thought it was a very good package. The routines were readily
available, worked, and if they didn't quite meet your needs could be
easily adapted.
Results count.
Ken Plotkin
Richard Maine
Yes. There were a few routines from the SSP that I used for a
long time. (I think it must have been Scientific Subroutine
Package or some such, because I'd swear I recall the abbreviation
being SSP.)
--
Richard Maine
email: my last name at domain
domain: sumertriangle dot net
Helge Avlesen
why do you find it stupid? I just briefly remember a seminar some
years ago with a very enthusiastic guy from SGI that was talking about
F--. you could e.g. copy an array from process N to M by saying
something like
f(:,:)[M] = f(:,:)[N]
or broadcast a scalar B with a simple
C[:]=B.
this would be possible on both distributed and shared memory type
systems, and looks like real syntactic sugar for someone used to
playing/fighting with MPI, OpenMP etc. but since then (97? 98?)
nothing but silence. so, is there a good reason for this? could be
interesting if someone could elaborate.
getting something like this into fortran compilers, and support
e.g. clusters out of the box, would really leapfrog javas thread
support.
--
Helge
Dan Nagle
<snip>
> and looks like real syntactic sugar for someone used to
>playing/fighting with MPI, OpenMP etc. but since then (97? 98?)
>nothing but silence. so, is there a good reason for this? could be
>interesting if someone could elaborate.
There's the Co-array Fortran web site,
http://www.co-array.org/
which has been active since '97 or '98 or so.
>getting something like this into fortran compilers, and support
>e.g. clusters out of the box, would really leapfrog javas thread
>support.
The rub is getting support from compilers.
A compiler vendor will tell you "I already have to support:
1. our old proprietary parallelization directives, and
2. OpenMP, and
3. be certain my compiler works with MPI & PVM, and
4. HPF, and
5. parallel cetera"
for parallelization. (Where any of the above might be due
to one Very Important Customer who won't convert to Something Else.)
Why _must_ I support a new parallelization scheme?
This is where standardization enters the picture--
it gives Co-arrays an "Official" reason to expect that it will be
worth the cost of implementing it.
Kevin G. Rhoads
>on crusades whose sole purpose is to force other people to do or
>not do something that has no obvious effect on the crusader...
Yes!
Greg Lindahl
Helge Avlesen <av...@ii.uib.no> wrote:
>| Stupid. Fast. Yum.
>
>why do you find it stupid?
I think you misinterpreted my use of the word. I am a fan of Co-Array
Fortran.
> but since then (97? 98?) nothing but silence.
There's been a lot of progress recently. A group at Rice is building a
CAF-to-Fortran translator using the Open64 compiler suite. The companion
language UPC is also getting attention. Both of them require either
shared memory or a Really Really Fast interconnect to work well.
-- greg
Greg Lindahl
Dan Nagle <dna...@erols.com> wrote:
>This is where standardization enters the picture--
>it gives Co-arrays an "Official" reason to expect that it will be
>worth the cost of implementing it.
HPF was a standard, and it lost money for everyone who touched it.
Standardizing something doesn't automatically make it good.
-- greg
Helge Avlesen
| There's been a lot of progress recently. A group at Rice is building a
| CAF-to-Fortran translator using the Open64 compiler suite. The companion
| language UPC is also getting attention. Both of them require either
| shared memory or a Really Really Fast interconnect to work well.
very cool. looked at http://www.emsl.pnl.gov/docs/parsoft/armci/
their caf is already on par with hand coded MPI over myrinet on the
NAS benchmarks :)
--
Helge
Dan Nagle
On Wed, 25 Feb 2004 18:57:00 GMT, lin...@pbm.com (Greg Lindahl)
wrote:
<snip>
>
>HPF was a standard, and it lost money for everyone who touched it.
>
>Standardizing something doesn't automatically make it good.
>
>-- greg
HPF was never part of the ISO Fortran standard,
even though f95 added some HPF features.
The distinction of "Official" versus ad hoc standards
is important, for example, in what may be specified in a contract
for the purchase, say, of a large amount of hardware
(which would be worth enough money to spur the development
of a compiler).
Different vendors of "standard" HPF actually supported
different subsets of the standard, to the great detriment of HPF.
analyst41
OK - that would be one example. If I recall correcly, the concepts of
structired programming began hitting the world in the late 1960s - so
I am wondering how the IBM guys wrote code that would be considered
good prior to that, especially without even IF ... THEN ELSE ...ENDIF.
> Results count.
I agree, but we are talking about style.
The followoing code that I picked up from a book in the 1980s works:
SUBROUTINE EXHEAP(N,INDEX,I,J,ISGN)
IF (INDEX) 90,10,80
10 CONTINUE
N1 = N
L = 1 + N/2
20 CONTINUE
L = L - 1
30 CONTINUE
L1 = L
40 CONTINUE
I = L1 + L1
IF (I-N1) 50,60,70
50 CONTINUE
J = I + 1
INDEX = -2
RETURN
60 CONTINUE
J = L1
L1 = I
INDEX = -1
RETURN
70 CONTINUE
IF (L.GT.1) GO TO 20
IF (N1.EQ.1) GO TO 110
I = N1
N1 = N1 - 1
J = 1
INDEX = 1
RETURN
80 CONTINUE
IF (INDEX-1) 30,30,40
90 CONTINUE
IF (INDEX.EQ.-1) GO TO 100
IF (ISGN.LT.0) I = I + 1
GO TO 60
100 CONTINUE
IF (ISGN.LE.0) GO TO 70
INDEX = 2
RETURN
110 CONTINUE
INDEX = 0
RETURN
END
I believe it is Fortran 66 - surely the existence of stuff like this
was one of the main reasons for the sorry state of Fortran today -
Fortran 77 cleaned up all this dirty stuff and we never publicized it.
And then while C was relentlessly obliterating F77, we spent thirteen
plus years in "Ada-envy" dreaming up 'clean' features - only to
discover that the user base was largely gone when the mostrosity
called f90 was finally delivered.
>
> Ken Plotkin
Duane Bozarth
>
> Ken Plotkin <kplo...@nospam-cox.net> wrote in message news:<4kun30l19h85smiod...@4ax.com>...
> > On 24 Feb 2004 01:42:44 -0800, anal...@hotmail.com (analyst41)
> > wrote:
> >
> >
> > >Please be so kind as to furnish ONE example of non-trivial Fortran
> > >code written in the 1960s that you would consider "good" code.
> >
> > Was the IBM Scientific Subroutine library written in the 1960s? Or
> > was that 1950s?
> >
> > I thought it was a very good package. The routines were readily
> > available, worked, and if they didn't quite meet your needs could be
> > easily adapted.
> >
>
> OK - that would be one example. If I recall correcly, the concepts of
> structired programming began hitting the world in the late 1960s - so
> I am wondering how the IBM guys wrote code that would be considered
> good prior to that, especially without even IF ... THEN ELSE ...ENDIF.
Simple...they worked at it and thought about how they wrote code.
There's no IF ... THEN ELSE ...ENDIF in assembler code, yet some of it
is every bit as structured as any other code. The point is, it <isn't>
the language per se, it's the writer.
If you're so adamantly opposed to Fortran, why bother us with your
hangups?
Richard Maine
> The followoing code that I picked up from a book in the 1980s works:
Looks fairly straightforward compared to many. At a glance I can
see that it is doing a binary search. But not a single comment
in the code, even one giving a hint as to what the purpose of the
subroutine is? F66 allows comments. This is a failing of the
programmer, not of the language. That's enough anaysis of it for
now.
As I said earlier (and about a billion or so other people said it
before me - it isn't exactly original), you can write bad code in any
language. Posting a single example of bad code does not constitute
evidence that good coding can't be done in f66. Posting 10,000
examples of bad coding wouldn't do any more. Hey, if I wanted
to show some samples of bad code, I could come up with a *LOT*
worse than this without even trying. You didn't ask for that - it
would be a lot simpler than coming up with samples of good code; but
that wouldn't show anything either. I've seen nobody claim that
there isn't poorly written f66 code. If anyone does claim that,
then they are as...well...let's scratch that hypothetical line
before I say things that I shouldn't.
You cannot prove nonexistance of something by showing examples of
lots of examples of things that do exist and aren't it. Obviously,
cockroaches don't exist. There are several billion people in the
world, not one of which is a cockroach. I guess that must be
several billion pieces of evidence.
But I don't know why I bother.
Greg Lindahl
Dan Nagle <dna...@erols.com> wrote:
>The distinction of "Official" versus ad hoc standards
>is important, for example, in what may be specified in a contract
>for the purchase, say, of a large amount of hardware
>(which would be worth enough money to spur the development
>of a compiler).
Huh? I thought that lots of contracts required HPF, not caring if it
was official or ad hoc.
But even if not, I'm sure we can think of many other examples where
standardizing something didn't mean that it was either a good idea or
got used.
-- greg
Gary Strand
> I agree, but we are talking about style.
A 'puter language don't dictate th' style, ya know, like, ya know, English
ain't demandin' how its spoke.
> The followoing code that I picked up from a book in the 1980s works:
So does this:
-------------------------------------------------------------------------------
#include <stdio.h>
main(t,_,a)
char *a;
{
return!0<t?t<3?main(-79,-13,a+main(-87,1-_,main(-86,0,a+1)+a)):
1,t<_?main(t+1,_,a):3,main(-94,-27+t,a)&&t==2?_<13?
main(2,_+1,"%s %d %d\n"):9:16:t<0?t<-72?main(_,t,
"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l+,/n{n+,/+#n+,/#\
;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l \
q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# \
){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' \
iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c \
;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'{n' ')# \
}'+}##(!!/")
:t<-50?_==*a?putchar(31[a]):main(-65,_,a+1):main((*a=='/')+t,_,a+1)
:0<t?main(2,2,"%s"):*a=='/'||main(0,main(-61,*a,
"!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"),a+1);
}
-------------------------------------------------------------------------------
I guess the above proves C is garbage too.
--
/\ Gary Strand (303) 497-1336 NCAR ML220
\_][ www.cgd.ucar.edu/ccr/strandwg 1850 Table Mesa Dr
\___stra...@ucar.edu Boulder, Colorado, USA 80305-3000
Greg Lindahl
>
>So does this:
No fair posting code from the Obfuscated C Contest without telling us
what the answer is! This one prints the 12 Days of Christmas.
-- greg
Ed Wells
> Think of this
>
> Minimizing a convex function, minimizing a linear function (both
> convex and concave) and minimizing a concave function subject to
> constraints - are for all practical purposes unrelated problems.
>
> What good is it to define a "class" or whatever of fucntions by their
> concavity/convexity and try to develop generic algortihms.
You're right, those three types of routines are probably not
well-suited to develop a general concavity/convexity class.
Any one of them, however, is well suited to be written as a routine
that finds the concavity/convexity of a scalar "class": integers,
reals, complex reals, and some user-defined types.
>
> And finally, the oft-quoted advantage of "generic programming" that
> you don't need to duplicate code for sorting real numbers and for
> sorting integers - is this trivial gain worth increasing the
> compiler's complexity ?
For my application in Computational Crystalography it is worth having
generic procedures that deal with objects to embody atoms, symmetry
operations, direct-space lattice vectors, reciprocal-space lattice
vectors, and some other "classes" that extend the functionality of
these basic "classes". My generic procedures must be able to read,
write, sort, rank, and initialize each of these types. So, yes, it is
worth some added complexity to the comiler so that I don't have to
remember every special name for every procedure.
Also, think of ELEMENTAL procedures that allow you to write a single
routine that can take input as a scalar up to an arbitrarily shaped
and sized array. I think that's a very object-oriented approach.
Really, and truly, I've read your opinions for some time on this list
and they amount to one thing: you simply don't like or agree with the
direction of Fortran. That's your right, but you don't have to come
here and shout it everytime you misunderstand and don't see a direct
use for features that others use on a regular basis. Don't use those
features you consider bloat and move along with business.
Gary Strand
> No fair posting code from the Obfuscated C Contest without telling us
> what the answer is! This one prints the 12 Days of Christmas.
It's just a little piece of C I keep around just to show folks who think it's
not as bad as some other language X, so I should use C all the time. I've yet
to meet anyone who could guess what it does, who hasn't seen it before.
bv
>
> Really, and truly, I've read your opinions for some time on this list
> and they amount to one thing: you simply don't like or agree with the
> direction of Fortran. That's your right, but you don't have to come
> here and shout it everytime you misunderstand and don't see a direct
> use for features that others use on a regular basis.
Really, and truly, he should come here and shout every time he sees
fanatics advocating language polluting features that only a minority
uses on a regular basis.
btw, ever heard of G.Booch? fyi, he's long departed the OO train
(and ADA locomotive) and moved onto better things!
analyst41
actually I love fortran and loathe C/C++/Java.
My main concern is with the impending death of Fortran 90 and later
versions.
Let me state my position clearly.
(1) The fact is that the vast bulk of published Fortran code from the
60s was awful - statement numbers, gotos, arithmetic ifs etc.
(2) In the late 60s and early 70s, the proponents of structured
programming used a lot of examples from 60s fortran to illustrate bad
coding style - and created a universal image of Fortran as a dirty
language.
(3) Fortran 77 cleaned up Fortran enormously - it was in fact clean
enough to withstand all its clean competitors - PASCAL, ALGOL to name
2.
(4) Fortran started dying in the decade of the 80s not because it
wasn;t clean enough - BUT BECAUSE IT WASN'T DIRTY ENOUGH (system
calls, command line args,low level access to external files, bits,
arrays with variable dimensions, data base APIs, exception handling
etc.). After all it was decimated by the ultimate dirty language - C.
(5) The Fortran elders spent the 80s "cleaning" Fortran 77 and
transforming it to Fortran 90 - which is going to fail miserably for
exactly the same reason as Ada - it may be clean and safe but few real
life programmers want to use either one.
(6) Even if I had ANY dout that Fortran 90 etc will die - the
introduction of OOP into Fortran settles it.
(7) In the meantime, a magnificent language - f77 - languishes - if
only some "dirty", practical things were addred to it - it would clean
the clock of C/C++/Java for a large domain of applications.
Helge Avlesen
| (4) Fortran started dying in the decade of the 80s not because it
| wasn;t clean enough - BUT BECAUSE IT WASN'T DIRTY ENOUGH (system
| calls, command line args,low level access to external files, bits,
| arrays with variable dimensions, data base APIs, exception handling
| etc.). After all it was decimated by the ultimate dirty language - C.
|
| (5) The Fortran elders spent the 80s "cleaning" Fortran 77 and
| transforming it to Fortran 90 - which is going to fail miserably for
| exactly the same reason as Ada - it may be clean and safe but few real
| life programmers want to use either one.
if there is such a thing as decreasing use of Fortran (relative to
other lang. yes, but in absolute numbers no?) I doubt syntax should
get all the credit, except for the piece of the HPC cake, which
is significant, but not cathastrophic, that may have been lost due to
lack of standard interoperability, OO etc.
The major source for decrease in usage (my guess);
Fortran lost its position as a problem solving tool for engineers and
other non computer scientists, to spreadsheets and rapid problem
solving environments like matlab, maple etc. At my old school they
have stopped teaching programming to first year students all
together. They now learn using spreadsheets and macros. Which makes
sense for a lot of tasks. Why compile and debug when you can see the
answer right away...
Fortran never was a system programming language, e.g. UNIX was written
in C so Fortran would not have been a natural choice for all coming
open source hackers anyway.
--
Helge
Dan Nagle
On Thu, 26 Feb 2004 19:19:17 GMT, lin...@pbm.com (Greg Lindahl)
wrote:
>In article <dhjr30t9e83u1ro35...@4ax.com>,
>Dan Nagle <dna...@erols.com> wrote:
>
>>The distinction of "Official" versus ad hoc standards
>>is important, for example, in what may be specified in a contract
>>for the purchase, say, of a large amount of hardware
>>(which would be worth enough money to spur the development
>>of a compiler).
>
>Huh? I thought that lots of contracts required HPF, not caring if it
>was official or ad hoc.
How was HPF identified? (Oh, _That_ Rice University!)
>But even if not, I'm sure we can think of many other examples where
>standardizing something didn't mean that it was either a good idea or
>got used.
Agreed.
But notice how you can specify ISO/IEC xxxx-yy just by saying so,
but may have to incorporate the entire document
of an unofficial standard in the contract to have the same effect.
>-- greg
BTW, if two HPF compilers give different results for the same code,
how do you arbitrate the interpretation?
Has NIST ever produced a conformance suite for HPF, MPI, PVM, etc.?
If not, why not?
Claus Pedersen
> Fortran lost its position as a problem solving tool for engineers and
> other non computer scientists, to spreadsheets and rapid problem
> solving environments like matlab, maple etc.
I would be careful in calling Matlab a rapid problem solving environment.
It certainly depends on the kind of computational problems one is dealing
with. I have seen computations that literally took days to do in Matlab.
The same computations took less than an hour with Fortran 90. (Note that
this is not an attack on Matlab --- in fact I use it quite a lot).
So to me (an engineering student), the situation is the opposite. Fortran
has gained a position as a problem solving tool for calculations I
previously used Matlab for. And I do not think, that I am switching back.
But I still see Matlab as a good tool for many (smaller) tasks.
> At my old school they
> have stopped teaching programming to first year students all
> together. They now learn using spreadsheets and macros. Which makes
> sense for a lot of tasks. Why compile and debug when you can see the
> answer right away...
My statement above should indicate that this is not always possible.
--- 8< 8< 8< ------------
Best regards,
Claus
--
Stud. Polyt. Claus Pedersen,
Dept. of Communication Technology, Inst. of Electronic Systems,
Aalborg University, Aalborg, Denmark.
E-mail: cpe...@kom.aau.dk
ioson
A petition to retire Matthew.............
Walter Spector
>
> Ed Wells wrote:
> >
> > Really, and truly, I've read your opinions for some time on this list
> > and they amount to one thing: you simply don't like or agree with the
> > direction of Fortran. That's your right, but you don't have to come
> > here and shout it everytime you misunderstand and don't see a direct
> > use for features that others use on a regular basis.
>
> Really, and truly, he should come here and shout every time he sees
> fanatics advocating language polluting features that only a minority
> uses on a regular basis.
Yes, F95 is bloated and things should be dropped. Here are a few
from my list:
1.) Drop 'default typing' of variables. This is incredibly error-prone.
Anyone with any sense uses IMPLICIT NONE religiously.
2.) Require all subroutine and functions to be checked against an
interface. (E.g.., everything will either be CONTAINed in modules,
or user-written INTERFACE blocks will be needed.) Anything else is
error-prone.
3.) Deprecate COMMON blocks. Module-based globals are superior in almost
every respect.
For all the fine work the Fortran Standard groups have done, failing to
address #1 above seems like quite a mistake. They had a GOLDEN opportunity
to do it with Fortran-90, yet failed to do so. Then they could have done
it at F95 time, and again failed to do it. Looks like they will have
their heads in the sand again with F-2003. Compare to the C99 effort,
which took their opportunity to fix the 'implicit int' problems in C.
With the exception of the above, and a very few other things, I regularly
use almost the entire F90/F95 language, and have done so for over a decade.
Drank a pretty good draught of that Kood-Aid, I guess. But I honestly think
that if F90 hadn't been as good as it is, Fortran really would be dead today.
Walt
-...-
Walt Spector
(w6ws at earthlink dot net)
beli...@aol.com
> Fortran lost its position as a problem solving tool for engineers and
> other non computer scientists, to spreadsheets and rapid problem
> solving environments like matlab, maple etc. At my old school they
> have stopped teaching programming to first year students all
> together. They now learn using spreadsheets and macros. Which makes
> sense for a lot of tasks. Why compile and debug when you can see the
> answer right away...
The "scripting is faster" hype has become pervasive, but I am
skeptical.
When using a scripting language, it is possible for the program to run
half-way, print some results, and then crash because of an error in
your program -- maybe a function you are calling is not defined, or it
has the wrong number of arguments. I find this an annoying waste of
time. With Fortran 95, especially using modules, such problems are
caught at compile time, BEFORE the program starts running. I greatly
prefer this. It is easy to write a batch file that compiles and links
your program and then runs it, IF an executable could be created. For
numerical programming, I consider Fortran 95 to be a prototyping
language -- with a little experience, it is easy to code up something
fast. But unlike most prototyping languages, the Fortran code does not
need to be rewritten to make it fast and portable!
I have used Excel spreadsheets with VBA a lot. It is convenient, and
the spreadsheet GUI is very familiar to users. But what do you when
you bump against its limits, for example the rather small limits on
rows and especially columns? Understanding how a spreadsheet arrives
at its results quickly gets difficult as the spreadsheet grows more
complex. This cell depends on that cell, which depends on that cell,
... . There is also NO guarantee that your spreadsheet will still work
when the IT department "upgrades" your version of Excel. Another
problem -- it is the experience of my colleagues and me that as your
spreadsheet programs get larger, they tend to crash at random, for
unknown reasons.
No one of average intelligence needs college instruction in using
Excel.
But if they do not learn a real programming language in college, they
may never get beyond Excel. I have suggested to colleagues doing heavy
statistical analysis in Excel to learn R, but to no avail.
> Fortran never was a system programming language, e.g. UNIX was written
> in C so Fortran would not have been a natural choice for all coming
> open source hackers anyway.
Most programming magazines are dominated by discussion of databases,
web programming, GUI development, and text analysis. Most programmers
seem to be working on things far removed from numerical work, and this
may partially explain the small market share of Fortran.
Richard Maine
> Yes, F95 is bloated and things should be dropped. Here are a few
> from my list:
[several things I at least tend in the same directikon as Walter on]
> 1.) Drop 'default typing' of variables.
...
> They had a GOLDEN opportunity
> to do it with Fortran-90, yet failed to do so.
That was one of my formal comments on f90 - that implicit none could
be made the default in free source form without invalidating any
standard conforming existing code (since free source form was new to
the standard). Though several of my comments were accepted, that
one wasn't.
> Then they could have done
> it at F95 time, and again failed to do it. Looks like they will have
> their heads in the sand again with F-2003.
I wouldn't say that was an accurate characterization. It can't now
be done without invalidating existing code. While that doesn't
100% rule something out, it is a pretty significant issue. In this
case, it would invalidate *LOTS* of existing code - probably the
majority of it. It is even a significant fraction of new code.
Now I personally agree that implicit none should be strongly
preferred. But the purpose of the standard is not to allow me
(or you) to force our preferences on other people, no matter how
"right" we might think our preferences are. There are clearly
quite a few people who vehemently disagree with our preferences
there.
I don't think you appreciate how big a deal it would be to invalidate
that much existing code and a practice that is still in use by as
many people as implicit typing is. I don't think the "head in the
sand" analogy is appropriate here. The committee sees the issue;
I'd more question whether you do. My guess is that the backlash
against removing implicit typing would be strong enough to prevent
a standard from passing. I'd say that the committee would have its
head in the sand if it tried such a change and didn't forsee the
reaction.
I'm sure that the committee is at fault for lots of things. But don't
blame the entire world's problems on J3. They can't do things that
the market won't accept. Well, I guess they can... but it turns into
a pretty big waste of everyone's time.
Tell you what - we'll strike a deal. You get the user community to
accept that it is ok to remove default typing and I'll get J3 to do
it. I've got by far the easier job. (In fact, if you do your job
first, then mine becomes really easy). Oh, and it's no fair to say
that users who disagree with us don't count for some reason. And
a simple majority isn't enough - you need a consensus from a very
substantial supermajority. I'll grant you a few isolated holdouts,
but they better not be representative of a significant segment
(for any of several measures of significance). I might add that
a concensus of clf isn't enough because there are significant
segments that aren't represented much, if at all, here.
Or for another deal: get me established as world dictator for
life, and I'll remove default typing whether the market goes
along or not. I might have one or two other projects to complete
first, though. :-)
Walter Spector
>
> Walter Spector <w6ws_xt...@earthlink.net> writes:
>
> > Yes, F95 is bloated and things should be dropped. Here are a few
> > from my list:
>
> [several things I at least tend in the same directikon as Walter on]
>
> > 1.) Drop 'default typing' of variables.
> ...
> > their heads in the sand again with F-2003.
>
> I wouldn't say that was an accurate characterization. It can't now
> be done without invalidating existing code. While that doesn't
> 100% rule something out, it is a pretty significant issue. In this
> case, it would invalidate *LOTS* of existing code - probably the
> majority of it. It is even a significant fraction of new code.
I don't have a lot of time to respond this morning, but consider
the following:
1.) Fortran-77 deleted Hollerith constants. This 'invalidated' literally
every Fortran program in existance. The sky did not fall.
2.) Fortran-95 has deprecated fixed source form. This 'invalidated' large
amounts of pre-Fortran-90 code. The sky did not fall.
3.) With modern text processing tools, it is a tiny matter to insert
the following like the following into every needy program unit in a code:
IMPLICIT REAL(A-H, O-Z), INTEGER (I-N)
This gives a 'quick n dirty' conversion path for existing code. The sky
will not fall.
In practice, once a deprecation period was over, every compiler vendor would
probably accept default typing as an extension. Perhaps issue a warning,
rather than a fatal error, if a user forgets to type something. (This what
the C99 compilers that I am familiar with do with 'implicit int' issues...)
Or perhaps by requiring a user turn on the extension with a compiler option.
But ya gotta start somewhere, and currently no one has done anything.
BTW, I meant what I said about the fine work X3J3 is doing. I look forward
to using a full F2003 compiler.
Richard Maine
> 3.) With modern text processing tools, it is a tiny matter to insert
> the following like the following into every needy program unit in a code:
>
> IMPLICIT REAL(A-H, O-Z), INTEGER (I-N)
>
> This gives a 'quick n dirty' conversion path for existing code. The sky
> will not fall.
True. That would be less traumatic than some options. I think I
was reading "drop default typing" to mean dropping implicit typing
altogether (so that the above wouldn't work either). But I do
suppose you said "drop default typing" instead of "drop implicit
typing", so implicit typing that wasn't the default would still be
there. I missed that distinction.
Greg Lindahl
Dan Nagle <dna...@erols.com> wrote:
>But notice how you can specify ISO/IEC xxxx-yy just by saying so,
>but may have to incorporate the entire document
>of an unofficial standard in the contract to have the same effect.
I agree that this is an advantage of an official standard. It's about
the only one.
>Has NIST ever produced a conformance suite for HPF, MPI, PVM, etc.?
PVM has never been standardized; it is specified by the
implementation. BTW, you can run the PVM-on-MPI on any MPI system, and
you'll be bug-compatible.
MPI has a "test" (conformance) suite that ships with MPICH. I don't
know the details, but I do recall Intel and NIST and DARPA being
involved in earlier suites, that might be the ancestors of this
one. Of course, you can't test conformance to the parts of the MPI
standard where the committee that wrote it disagrees on the meaning.
HPF is dead. That parrot's nailed to the perch.
-- greg
analyst41
>
> Most programming magazines are dominated by discussion of databases,
> web programming, GUI development, and text analysis. Most programmers
> seem to be working on things far removed from numerical work, and this
> may partially explain the small market share of Fortran.
Please try to be aware of the dismal FACTS and then comment.
(1) before the decimation of the Fortran user-base (which took place
apprximately in the decade of the 1980s +- a couple of years) -
Fortran was EVERYWHERE - weapons systems, industrial process control,
aerospace, wall street, just anout every large enterprise. The
Creature called VAX-FORTRAN (ie Fortran with a lot of C-like
extensions including system calls) was a smashing success story in
terms of user take-up. Statistical packages like SAS were written in
Fortran as were most commercial optimization packages.
(2) Fortran is now viewed as a quaint relic by wall street and
mainstream businesses and new development in Fortran is unthinkable.
I would assume that it has been eliminated from weapons systems
software.
(3) During the dying off period of Fortran there were massive
'porting' projects that would be advertised in the employment ads
(mostly to C or C++). VAX Fortran is now essentially kaput, as far as
I know, as are any significant legacy Fortran applications in any
Fortune 500 enterprise.
(4) Take Linear Programming - the one purely quantitative application
on which the most money is probably spent world wide. The premier
commercial package is written in C. The user manuals spend 99 pct on
how to call the package from C/C++/Java. There is a teeny tiny
section on how to call it from Fortran - just Fortran - not a peep
about Fortran 90 or 95. SAS has now been rewritten in C. The list
goes on and on.
Just think about - the supposedly CORE COMPETENCY area of Fortran -
quantitative computing - has been occupied by C/C++/Java.
(5) For the pull-the-sheet-over-your-head crowd that hangs out here -
some remnants such as weather prediction and still-working code from
the 70s that no one has been able to port is a source of comfort - but
the writing is clearly on the wall.
(6) We need to turn our back on the Fortran committee and go back to
Fortran 77 and re-evolve it avoiding all the ada-envy driven bloat and
minimally extend that beautiful language - it would be such a thing of
beauty that the user base will return. But it must happen soon before
the current crop of Fortran experts who are still lurking in
mainstream computing retire. If something is not done soon - it is
curtains for all flavors of Fortran.
Greg Lindahl
analyst41 <anal...@hotmail.com> wrote:
>(2) Fortran is now viewed as a quaint relic by wall street and
>mainstream businesses and new development in Fortran is unthinkable.
>I would assume that it has been eliminated from weapons systems
>software.
You mean places like the US National Labs, which are writing a lot
of new code in Fortran 95? Yes, they also write a lot of C++.
Other communities, like weather, are largely Fortran.
Yes, Fortran's % seems to have fallen a lot. But you seem to be rather
cavalier about what you do and don't know about that.
-- greg
Dan Tex1
I disagree. Going back to F77 would be a big mistake IMHO. If we were to go
back to F77, or F77 with a few minor extensions... I feel quite confident that
THAT would be the death blow to fortran. And... the death would come quickly.
ie... almost NO new code would be written in the language.
Fortran is an old language. Thus... Comp Sci departments in schools aren't
likely to even want to look at Fortran and consider it's usefulness unless some
major changes occur in the language. Even then... by human nature, they
probably won't give it much thought. You know how things work. When someone
comes out with some tasty new flavor of ice cream, everone wants some. It's
the new flavor of the month. However, after a while... there come other new
flavors of the month. Most people never really want to go back to the
original flavor of the month. So... it's not really hard for me to believe
that Comp Sci depts. don't want to backtrack and take another look at fortran,
even in it's modern form. If you go back to F77... it's a given that they
don't even want to hear you mention the name, "Fortran".... other than for a
good laugh that is.
Of course... Comp Sci departments ( in general ) aren't spending all that much
time on the types of codes that scientists and engineers want and need to
write. So... why should they look at Fortran??? After all... if you want a
good Finite Element program, are you going to ask someone without the
engineering background to write it? You might ask them to write an interface,
but... someone who knows and understands FEM needs to write the analytical
parts of the program. Sure. I've seen engineering codes where a
"non-engineer" wrote the code. However, I don't ever think I've seen such
codes that actual worked very well. They often look spiffy. They just tend to
bomb often and spit out erroneous results when they don't bomb. Yes. You
often get the same results when an engineer writes the code too. However, the
good programs are actually written by engineers who "can" program. Not by
engineers who can't program or by Comp Sci programmers who don't know much
engineering. Bottom line... Comp Sci depts don't focus primarily on science
and engineering codes. Thus... they have no incentive to spend much time on
languages which are appreciated by scientist and engineers.
There are a lot of features that F77 doesn't have that a LOT of people want (
even for FEM type codes ). Thus... going back to F77 isn't going to
popularize fortran at all IMHO. Heck... the mere lack of dynamic memory
allocation in F77 is "all by itself" a reason not to go back to F77. The
simple TRIM() function is worth having. I've found Modules, even in their most
basic form to be very helpful. The new array syntax for operating on arrays
makes code easier to read. The new syntax makes some codes much easier to read.
All of these features are, IMHO, incredibly nice to have. I've seen a lot of
post here claiming that F90 became way too complex. None of these features is
very complex ( at least from a users point of view ). And... every one of them
is extremely helpful.
How about abstract data types ( user TYPEs ). Boy... these are sure nice to
have at times.You don't always need them. But... when you do... they are
nice!!! And.. in general, they are "very" easy to use.
Yes... pointers are in the language now. They certainly add some complexity (
in my opinion, the most complex addition to the language for your average
"engineer-type" of programmer ). However, where needed, they are very
powerful ( linked-list as one example ). Without them... more people will
just claim that not having them is a "con" to the language. Additionally, at
least Fortran pointers are more restricted and controlled. It's easy to shoot
yourself in the foot with them. However, unlike pointers in most other
languages... you're only risking shooting yourself in the foot. In other
languages, the risk is of sticking the gun barrel in your mouth and squeezing
the trigger.
So... I reiterate. Go back to F77 and the language is essentially dead. I
think the committe did a great job with F90/95 overall. I still have to wait
and see about the upcomming F2003. I'm worried a little about the complexity
there. ie... will the language still be easy enough to use for those who are
scientist/engineers, etc. who do programming in addition to their normal tasks.
Some of the features for F2003 sound pretty nice. I'm merely hoping that they
are implemented in a way which doesn't overly complicate things.
Dan :-)
Matthew
said (1) I use/like Fortran and (2) this is not my petition.
But, then, that would require an attention span longer than a gnat's age
and an interest in reading.
"ioson" <io...@nospam.it> wrote in message news:<l8I%b.4215$mt1....@tornado.fastwebnet.it>...
Clive Page
<anal...@hotmail.com> writes
>(3) Fortran 77 cleaned up Fortran enormously - it was in fact clean
>enough to withstand all its clean competitors - PASCAL, ALGOL to name
>2.
I agree with your points 1 and 2, but think that the problem with
Fortran77 was that it didn't go far enough. It had IF with END IF, but
not END DO to go with DO, for example, and no CASE statement. (OK, most
compilers did implement END DO as an extension, and some implement CASE
as well, even g77 has it for integer types, but that "some" means that
you can't rely on these extensions). In addition Fortran77 was crippled
by having no dynamic memory mechanism whatever, and no stream I/O.
Fortran90 fixed the former; Fortran2003 should fix the latter, rather
belatedly.
>(4) Fortran started dying in the decade of the 80s not because it
>wasn;t clean enough - BUT BECAUSE IT WASN'T DIRTY ENOUGH (system
>calls, command line args,low level access to external files, bits,
>arrays with variable dimensions, data base APIs, exception handling
>etc.). After all it was decimated by the ultimate dirty language - C.
Agreed; the Posix extensions should have solved that, but hardly any
vendors implemented them, unfortunately.
>(5) The Fortran elders spent the 80s "cleaning" Fortran 77 and
>transforming it to Fortran 90 - which is going to fail miserably for
>exactly the same reason as Ada - it may be clean and safe but few real
>life programmers want to use either one.
I disagree, Fortran90/95 isn't clean, as it has virtually the whole of
Fortran77 and most of Fortran66 still in there. That's one of its
weaknesses, but you can't at all easily have cleanliness and keep
compilers compatible with old code.
--
Clive Page
Dr Chaos
That probably coincides with the era that the companies started
being able to hire professional programmers from "computer science"
departments, already indoctrinated with "Fortran sucks".
There was some truth to that---then.
> (5) For the pull-the-sheet-over-your-head crowd that hangs out here -
> some remnants such as weather prediction and still-working code from
> the 70s that no one has been able to port is a source of comfort - but
> the writing is clearly on the wall.
>
> (6) We need to turn our back on the Fortran committee and go back to
> Fortran 77 and re-evolve it avoiding all the ada-envy driven bloat and
> minimally extend that beautiful language - it would be such a thing of
> beauty that the user base will return. But it must happen soon before
> the current crop of Fortran experts who are still lurking in
> mainstream computing retire. If something is not done soon - it is
> curtains for all flavors of Fortran.
So, since Fortran 77 died very quickly, the right answer is to make
new Fortran more like Fortran 77?
Fortran 77 was NOT a beautiful language.
I think the main reason for decline is that they didn't make a Fortran
81 or 82 with at least ALLOCATABLE arrays, simple structures and basic
pointers.
C had malloc. Fortran didn't.
C had structures. You could make linked lists which looked
like they were from the the textbooks. You could make trees.
James Giles
...
> C had structures. You could make linked lists which looked
> like they were from the the textbooks. You could make trees.
This particular argument always bothers me. The textbook
writers were in need of some simple examples to demonstrate
the basic properties of pointers. They chose lists and trees
as simple things that students could understand so that they
could concentrate on the purpose of the lesson: teaching
the properties of pointers.
However, it is *not* a good idea to implement lists or trees
with the naive textbook style! In fact, that's almost always one
of the worst approaches you can take. The textbook had a
specific purpose: teaching pointers. The programmer has
a different purpose: using lists or trees. The textbooks
didn't teach that second purpose.
--
J. Giles
Dr Chaos
That's unfortunate. You've told me this before, and I've still looked
for good examples so I can learn how to do it, but they are rare.
You have to admit that the conceptually simplest way to do it
(i.e. from verbal description to code) is with pointers---just as the
conceptually simplest way to use complex numbers is to declare COMPLEX
:: a and not some awful circumlocution in other languages.
I think it is important that a language can support the intellectual
and pedagogical structures of easy algorithms as well as sophisticated
ones.
James Giles
[... linked lists and trees ...]
> You have to admit that the conceptually simplest way to do it
> (i.e. from verbal description to code) is with pointers---just as the
> conceptually simplest way to use complex numbers is to declare COMPLEX
By that analogy, the conceptually simplest way would be to directly
declare things to be lists or trees. In Lisp, many things are lists
without any pointers (user manipulated) at all. Despite its other
failings, Lisp is a very good language for manipulating lists.
Similarly, in some languages (like Haskell, for example) trees,
lists, and other recursive data structures can be directly described,
all without a pointer in sight, and the result is conceptually
simpler. The conceptually simplest way does not really involve
pointers.
In lower-level languages (like C and Fortran), what's conceptually
simple depends on what your program will do with the structure.
Balanced binary trees are much simpler if you just use an array
in which the descendents of node N have indices of 2*N and
2*N+1. Again, no pointers in sight. As for lists, many uses of
them need no pointers at all. I've seen C programmers use linked
lists to implement queues and stacks - both of which are conceptually
simpler as allocatable arrays. In fact, most uses of linked lists would
be either simpler or faster (or both) if you chose to either not use links
or implement the links as array indices.
What languages really need is the ability to encapsulate the data
structure in such a way that the required manipulations are clear,
but the internal structure (including whether pointers are used
or not) is irrelevant.
--
J. Giles
TimC
> In lower-level languages (like C and Fortran), what's conceptually
> simple depends on what your program will do with the structure.
> Balanced binary trees are much simpler if you just use an array
> in which the descendents of node N have indices of 2*N and
> 2*N+1.
And if you want to grow your tree? Not knowing how big it is going to
be before you start?
> Again, no pointers in sight. As for lists, many uses of
> them need no pointers at all. I've seen C programmers use linked
> lists to implement queues and stacks - both of which are conceptually
> simpler as allocatable arrays.
And when you want to grow it, you have to allocate a new array, copy
all the elements to the new array, and deallocate the old array? Not
very suitable for many things.
> In fact, most uses of linked lists would be either simpler or faster
> (or both) if you chose to either not use links or implement the
> links as array indices.
I will agree many uses of linked lists implemented with pointers are
bad (in particular, if there is any index involved, and you have to
look up an element by its index). But if you don't need that index
(always sequential access), then it could well be the best.
Personally, I'm all for perl's implementation of lists :) Can access
as a list, or an array index (indeed, a sparse array - whether it is
implemented as sparse in memory, I have no idea). Grown as needed,
just by accessing element[n], or push()ing or unshift()ing.
Oh, and not indexed by the hideous nature of Fortran's overloaded use
of brackets :)
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
I am not a number. I'm a Free NaN.
Chris Reuter @ ARK
James Giles
> James Giles (aka Bruce) was almost, but not quite, entirely unlike tea:
>> In lower-level languages (like C and Fortran), what's conceptually
>> simple depends on what your program will do with the structure.
>> Balanced binary trees are much simpler if you just use an array
>> in which the descendents of node N have indices of 2*N and
>> 2*N+1.
>
> And if you want to grow your tree? Not knowing how big it is going to
> be before you start?
Have you never heard of re-allocation? You do that rarely, and in
larger than one-unit chunks. It's far more efficient than going
through the memory manager for each node you add or delete.
>> Again, no pointers in sight. As for lists, many uses of
>> them need no pointers at all. I've seen C programmers use linked
>> lists to implement queues and stacks - both of which are conceptually
>> simpler as allocatable arrays.
>
> And when you want to grow it, you have to allocate a new array, copy
> all the elements to the new array, and deallocate the old array? Not
> very suitable for many things.
Why not? Calling the memory manager a small number of times is
far more efficient than calling it once per element. And, the new
reallocate is permitted to extend the array in-place if there's room.
(In fact, it can be implemented internally by cooperating with the
virtual memory paging mechanism and *always* be able to reallocate
without moving data. That's a "quality of implementation" issue.)
> Personally, I'm all for perl's implementation of lists :) Can access
> as a list, or an array index (indeed, a sparse array - whether it is
> implemented as sparse in memory, I have no idea). Grown as needed,
> just by accessing element[n], or push()ing or unshift()ing.
And probably implemented internally in exactly the way you just
finished calling "Not very suitable for many things"? That's very
likely the case you know. (And yes, that's exactly the kind of
thing I think Fortran could do with very little additional work:
the F2003 allocatable array features include most of what's
necessary.)
> Oh, and not indexed by the hideous nature of Fortran's overloaded use
> of brackets :)
???
Until Fortran 2003, no standard Fortran even uses brackets [], unless
you're referring to something else. They certainly aren't overloaded.
--
J. Giles
TimC
>> Oh, and not indexed by the hideous nature of Fortran's overloaded use
>> of brackets :)
>
> ???
> Until Fortran 2003, no standard Fortran even uses brackets [], unless
> you're referring to something else. They certainly aren't overloaded.
()
Not braces. Not brackets. What are they?
Reading other peoples code, I can never tell whether they are talking
about arrays or functions. Doesn't even work in the case of a function
with many arguments - that call to a function accepting 15 arguments
really could be a 15 dimensional array :)
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
When some other esteemed editor reposts this, it'll be the Periodic
Periodic Table Table story, and I will be even happier. ;^)
-- Emil Brink on /., about the periodic table table.