Home > Archive > Fortran > March 2004 > Re: A petition to J3 apropos FORTRAN's future
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: A petition to J3 apropos FORTRAN's future
|
|
| James Giles 2004-03-27, 12:16 am |
| Dr Chaos wrote:
[... 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
| |
|
| 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?
> 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 2004-03-27, 12:16 am |
| TimC wrote:
> James Giles (aka Bruce) was almost, but not quite, entirely unlike tea:
>
> 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.
>
> 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
| |
|
| James Giles (aka Bruce) was almost, but not quite, entirely unlike tea:
> TimC wrote:
>
> ???
> 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.
| |
| Jan C. Vorbrüggen 2004-03-27, 12:16 am |
| > ()
>
> Not braces. Not brackets. What are they?
Parantheses.
> 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 :)
Nope - a standard-conforming array can only have a maximum of seven
dimensions.
But to take the matter further, an array really _is_ a function - quite a
simple one, of course, but it takes the indices, performs a certain (fixed)
computation on them, and returns a value. It just so happens that the
language pre-defines the computation such that the compiler can always
inline it 8-).
Jan
| |
|
| David Ham (aka Bruce) was almost, but not quite, entirely unlike tea:
> Jan C. Vorbrüggen <jvorbrueggen@mediasec.de> writes:
>
>
> Ah, this would be one of the more irritating English dialect differences:
>
> () [] {}
>
> English: brackets square brackets curly brackets
>
> American: parentheses brackets braces
>
> (the term parentheses is also used in English).
So I was going for the Half-n-half American and English approach. I
feel so... dirty.
> The ambiquity in the meaning of the word "brackets" causes all sorts
> of problems. Of course this could be fixed if the inhabitants of the
> North American colonies would learn to speak English :-).
My Canadian friends know how to speak English :)
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
As a computer, I find your faith in technology amusing.
| |
| beliavsky@aol.com 2004-03-27, 12:16 am |
| Dr Chaos wrote:
<SNIP>
> 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".
A physics professor told me recently that "there is a split in the
world of CS departments that teach Java or C++, and the computational
science community that uses Fortran. At the moment, the view in the CS
community is against teaching most any compiled language."
Science and engineering departments should not leave the teaching of
computer programming entirely to the CS departments -- or leave their
students completely dependent on MATLAB.
<SNIP>
> 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.
I think END DO, IMPLICIT NONE, and free source form were also obvious
additions that came far too late. I love modules and array intrinsic
functions, but I can understand why those big changes took a long time
after F77 to arrive.
| |
| Walter Spector 2004-03-27, 12:16 am |
| TimC wrote:
> ...
> Reading other peoples code, I can never tell whether they are talking
> about arrays or functions...
FWIW, many years ago, my original Fortran mentor taught me to use a
coding convention where one places a character of white space between
the name and the parentheses when it is a procedure call, and join the
two together for an array reference. E.g.:
real :: myarray(:)
:
myarray(i) = sqrt (x)
:
call xyzzy (myarray(23))
Walt
-...-
Walt Spector
(w6ws at earthlink dot net)
| |
|
| beliavsky@aol.com (aka Bruce) was almost, but not quite, entirely unlike tea:
> I think END DO, IMPLICIT NONE, and free source form were also obvious
> additions that came far too late. I love modules and array intrinsic
> functions, but I can understand why those big changes took a long time
> after F77 to arrive.
Still, I do hate how IMPLICIT NONE is not the default. Sure, most
(all?) compilers have their own flag to assume implicit none, but this
kind of thing should be mandated *on* by default (just to encourage
people who haven't changed their ways, to do so), with a switch to
turn it off for those silly little legacy programs that seem to exist
everywhere :)
And, yes, I have been bitten by it. Whenever I didn't write the
Makefile myself, and start adding functions to someone elses program,
I will be bitten by a spelling mistake, until I turn on said flag.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Usage: fortune -P [-f] -a [xsz] Q: file [rKe9] -v6[+] file1 ...
| |
| Gordon Sande 2004-03-27, 12:16 am |
| In article <4059B844.4FAD8973@earthlink.net>,
Walter Spector <w6ws_xthisoutx@earthlink.net> wrote:
>Subject: Re: A petition to J3 apropos FORTRAN's future
>From: Walter Spector <w6ws_xthisoutx@earthlink.net>
>Organization: Not much.
>Date: Thu, 18 Mar 2004 14:55:35 GMT
>Newsgroups: comp.lang.fortran
>
>TimC wrote:
>
>FWIW, many years ago, my original Fortran mentor taught me to use a
>coding convention where one places a character of white space between
>the name and the parentheses when it is a procedure call, and join the
>two together for an array reference. E.g.:
>
> real :: myarray(:)
> :
> myarray(i) = sqrt (x)
> :
> call xyzzy (myarray(23))
>
An even stronger form of this convention is to suppress all whitespace is
subscripts and make sure it is around all arguements. Thus
x(i,j) is an array reference
and
joe ( i, j ) is a function reference
and
sam ( i, y(j) ) is a function reference in which the
second arguement is an array element
I have used my own RatFor, complete with matching pretty printer, which
does
this and even adds the extra layer of using [ and ] for subscripts. At this
point I do not know which visual cue (the square brackets or the
whitespace)
is more important but I agree in liking the distinction. I first added
the square brackets to the RatFor and then realized I could use them to
control the whitespace. (RatFor has no symbol table so it is just a blind
character conversion and toggling of whitespace insertion that relies on
correct coding.)
>Walt
>-...-
>Walt Spector
>(w6ws at earthlink dot net)
| |
| Walter Spector 2004-03-27, 12:16 am |
| Gordon Sande wrote:
> Walter Spector <w6ws_xthisoutx@earthlink.net> wrote:
> ...
>
> An even stronger form of this convention is to suppress all whitespace is
> subscripts and make sure it is around all arguements...
Hadn't seen that one. I sorta do the same thing, but not quite as formally.
I typically only place a space after the comma in arg lists. But when array
expressions get complicated, one often needs more whitespace to break things
up a bit.
Walt
-...-
Walt Spector
(w6ws at earthlink dot net)
| |
| Gary Scott 2004-03-27, 12:16 am |
| Walter Spector <w6ws_xthisoutx@earthlink.net> wrote in message news:<4059B844.4FAD8973@earthlink.net>...
> TimC wrote:
>
> FWIW, many years ago, my original Fortran mentor taught me to use a
> coding convention where one places a character of white space between
> the name and the parentheses when it is a procedure call, and join the
> two together for an array reference. E.g.:
>
> real :: myarray(:)
> :
> myarray(i) = sqrt (x)
> :
> call xyzzy (myarray(23))
>
I always (or almost always) just do as you did above and include the
word "array" or "arr" in the name. I have used other methods, but
that is the one I use most often. It can be messy though with F77
6-character names. I don't think I could enforce your method on
myself though there once was a department programming standard that
required something like the following:
call xyz ( arg1, arg2, arg3 )
someone's idea of a readability improvement. I can sort of see it,
but it is an unnatural thought process for me to include at least 3 of
those spaces.
> Walt
> -...-
> Walt Spector
> (w6ws at earthlink dot net)
| |
| James Giles 2004-03-27, 12:16 am |
| Jan C. Vorbrüggen wrote:
....
> But to take the matter further, an array really _is_ a function - quite a
> simple one, of course, but it takes the indices, performs a certain
> (fixed) computation on them, and returns a value. It just so happens
> that the language pre-defines the computation such that the compiler can
> always inline it 8-).
I always preferred the fact that an array reference and a function
reference look the same. If I change a given function to a table
lookup instead, I need only change the definition of that one
symbol. I don't need to weed through the whole program to
change all the references.
--
J. Giles
| |
| analyst41 2004-03-27, 12:17 am |
| Walter Spector <w6ws_xthisoutx@earthlink.net> wrote in message news:<4059B844.4FAD8973@earthlink.net>...
> TimC wrote:
>
> FWIW, many years ago, my original Fortran mentor taught me to use a
> coding convention where one places a character of white space between
> the name and the parentheses when it is a procedure call, and join the
> two together for an array reference. E.g.:
>
> real :: myarray(:)
> :
> myarray(i) = sqrt (x)
> :
> call xyzzy (myarray(23))
>
> Walt
> -...-
> Walt Spector
> (w6ws at earthlink dot net)
beautiful !!
I intend to use this convention going forward - thank you.
I almost never use a function value directly.
I define function something0(horse,zebra...)
and when I use it I would say
something = something0(hare,tortoise,...)
and use something for whatever I want to do with the function.
| |
| analyst41 2004-03-27, 12:17 am |
| Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnc5hes0.44u.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
> On 27 Feb 2004 19:12:08 -0800, analyst41 <analyst41@hotmail.com> wrote:
> .
>
> 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".
Computer Science departments turn their noses up at C also. Computer
Science departments have never had anything to do with real-life
computing and never will.
During the dying-off period of fortran (late 1970s to early 1990s) All
low level "dirty" stuff was done with C (such as database internals)
and it turned out that All-C projects (incuding any math that was
needed) was what the dynamics of capitalism mandated and that was
that. Fortran 77 was decimated not because it wasn't clean enough but
because you couldn't do dirty things with it.
>
> There was some truth to that---then.
>
>
> So, since Fortran 77 died very quickly, the right answer is to make
> new Fortran more like Fortran 77?
it may have died compared to C/C++/Java but I'll bet it is seriously
kicking the ass of Fortran 90 and subsequent obscenities bearing the
Fortran name even as we speak. All we need to do is put C's
phenomenally successful dirty stuff in it and it actually would come
back.
>
> Fortran 77 was NOT a beautiful language.
IYNSHO.
>
> 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.
Allocatable arrays I agree - it was sorely needed - as was stream I/O.
Apparently pointers are now out of fashion.
| |
| Richard Maine 2004-03-27, 12:17 am |
| analyst41@hotmail.com (analyst41) writes:
> Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnc5hes0.44u.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
[stuff]
>
> IYNSHO.
Hmm. So we have to be careful to explicitly label opinions that
disagree with yours as opinions (which seems appropriate, I'd agree).
But your own opinions, complete with evaluations of other people's
motivations, are all FACTS (complete with the upper case).
Ok. I'll try to keep it straight. :-)
And I don't think I'll inject my opinions here. Or for that
matter, any facts; I'll save them for elsewhere.
--
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
| |
| Catherine Rees Lay 2004-03-27, 12:17 am |
| In article <slrnc5juoh.e29.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>, Dr
Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> writes[color=darkred]
>On 18 Mar 2004 10:27:55 +0100, David Ham <D.A.Ham@CiTG.TUDelft.nl> wrote:
>
>In the Queen's English, is what yankers would call a "parenthetical remark"
>known as a "bracketoid remark" ????
>
>:-)
>
No, it's known as an aside. Much shorter :-)
BTW, in any context where there is more than one sort of bracket, the
first sort are often referred to as "round brackets" not just
"brackets". Saves a lot of confusion.
Catherine.
--
Catherine Rees Lay
To email me, use my first name in front of the "at".
| |
| Jan C. Vorbrüggen 2004-03-27, 12:17 am |
| > During the dying-off period of fortran (late 1970s to early 1990s) All
> low level "dirty" stuff was done with C (such as database internals)
Ah yes. So the database application I wrote in 1986-1988 in Fortran, based
on database code written in Fortran, of course didn't exist. Neither did the
various real-time data acquisition systems written in Fortran, each containing
several hundred thousand lines of code, not counting the libraries they were
using.
Please excuse me, while I reboot my brain into your alternate reality, which
of course it the only correct one.
> Apparently pointers are now out of fashion.
No, they have always been out of fashion - at least in their C incarnation
- for people who had any idea at all what software engineering is about.
Jan
| |
| analyst41 2004-03-27, 12:17 am |
| Richard Maine <nospam@see.signature> wrote in message news:<m1znadhoec.fsf@macfortran.local>...
> analyst41@hotmail.com (analyst41) writes:
>
> [stuff]
>
> Hmm. So we have to be careful to explicitly label opinions that
> disagree with yours as opinions (which seems appropriate, I'd agree).
> But your own opinions, complete with evaluations of other people's
> motivations, are all FACTS (complete with the upper case).
>
> Ok. I'll try to keep it straight. :-)
>
> And I don't think I'll inject my opinions here. Or for that
> matter, any facts; I'll save them for elsewhere.
This may seem ad-hominem and/or irrelevant but
Have you ever been in an anvironment where programming projects have
to be proposed,accepted,budgeted,documented,th
e code
developed,acceptance tested and moved into production and then
supported on an ongoing basis ?
| |
| analyst41 2004-03-27, 12:17 am |
| Jan C. Vorbrüggen <jvorbrueggen@mediasec.de> wrote in message news:<405AF1F6.ADD9DC4D@mediasec.de>...
>
> Ah yes. So the database application I wrote in 1986-1988 in Fortran, based
> on database code written in Fortran, of course didn't exist. Neither did the
> various real-time data acquisition systems written in Fortran, each containing
> several hundred thousand lines of code, not counting the libraries they were
> using.
>
You seem to have an English-comprehension problem. If something died
during an interval that started in the late 1970s and ended in the
early 1990s, parts of it could have been alive in 1986-1988 - or do
you fid this an alternate-universe concept, too ?
> Please excuse me, while I reboot my brain into your alternate reality, which
> of course it the only correct one.
>
>
> No, they have always been out of fashion - at least in their C incarnation
> - for people who had any idea at all what software engineering is about.
>
>
> Jan
| |
| Richard Maine 2004-03-27, 12:17 am |
| analyst41@hotmail.com (analyst41) writes:
> Have you ever been in an anvironment where programming projects have
> to be proposed,accepted,budgeted,documented,th
e code
> developed,acceptance tested and moved into production and then
> supported on an ongoing basis ?
(Most people probably want to just skip this.)
I don't normally figure that this is the place to list my
qualifications. I prefer to let my arguments speak for themselves
rather than depending on my name. But if you really want to
know... I'll omit the Fortran standards-committee stuff because
regulars here presumably know about that. In my "day" job,
Fortran standards work is not what I'm mostly known for, though.
Yes. I have such projects myself. I personally did all those things
for the system that is used for managing *ALL* flight data at NASA
Dryden. It has been in production use for about 15 years and there
are no signs of it being particularly near the end of its lifetime.
It was designed with a long life cycle specifically in mind. Regular
production and support was long ago turned over to other people who
still run it. I don't actually have an account on the servers any
more or I'd go see how many people are using them at this instant.
I suppose I shouldn't call it a programming project, because it is
more than that. It is a complete operational system, including
several million dollars of dedicated hardware, software, operational
procedures, and interfaces with other systems at the center. It has
dedicated redundant servers that operate 24x7 and are in essentially
continuous use by multiple people. It includes both commercial
off-the-shelf, plus custom software. The custom software, by the way
is primarily in f90, with a few small C wrappers for interfacing.
I also have done some parameter estimation programs that have been
widely used worldwide in the area of aircraft stability and control.
After the first Shuttle flight, some aerodynamic stability and
control parameter estimation was done by people from 4 different
organizations so that there would be opportunity for cross-checking
each other's work. (Some of the Shuttle aero had been *MAJORLY*
mispredicted - I was impressed that the control system had been
able to deal well enough to bring it home, even though it did
fly awfull sloppily). I was a bit surprised to find that all
4 organizations were using my program for the analysis. There
is a lot of engineering work that also goes into such analysis;
it isn't just a matter of feeding data to the program and getting
its answers. So there was good cross-checking of that. But I'd
actually been hoping for independent programs as well; I'd have
been happier with a broader variety of approaches. But my program
was the one in production use in that field in all 4 organizations.
Oh. And I almost forgot to mention. That same parameter estimation
program was the basis for a matlab toolbox. It is the state space
identification toolbox in Matlab. Not one of the most popular of
the Matlab toolboxes - I was a bit surprised myself to see it adopted
for Matlab. I didn't do the Matlab version, but it was directly
based on the free code of my Fortran version. Garth Milne took
my program and "matlabized" it; he came out here to visit once to
ask for some advice on it.
That same parameter estimation program has also been used in
other areas, including submarines, economics, and medical
research, though aircraft stability and control was its primary
focus. Most of that stuff is fairly old history by now. The
program is vintage mid 70s and it shows. I still get an occasional
request for it once a year or so, but I usually manage to steer
people in other directions any more (if only to the "new"
replacement program that I did in the early to mid 90s, which is
the one now in production use here for that kind of thing.)
I've been involved in a few other programming projects in my day,
including many that are in production use, but the above are
major ones that are identifiable as "mine" rather than just
something I worked on.
Thank you for your interest. :-)
--
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 F. Cornwall 2004-03-27, 12:17 am |
| analyst41 wrote:
>
> Jan C. Vorbrüggen <jvorbrueggen@mediasec.de> wrote in message news:<405AF1F6.ADD9DC4D@mediasec.de>...
>
> You seem to have an English-comprehension problem. If something died
> during an interval that started in the late 1970s and ended in the
> early 1990s, parts of it could have been alive in 1986-1988 - or do
> you fid this an alternate-universe concept, too ?
Well, the USGS is running a distributed water database that is about 90
percent Fortran, and it's still being maintained & updated constantly.
There's some C in there, but not much. We use a great deal of embedded
SQL, and IMO it's a lot easier to do in Fortran than in C.
Jim C
[color=darkred]
>
--
****************************************
************
** Facilior veniam posterius quam prius capere! **
****************************************
************
** James F. Cornwall, sole owner of all opinions **
** expressed in this message... **
****************************************
************
| |
| analyst41 2004-03-27, 12:17 am |
| "James F. Cornwall" <JCornwall@cox.net> wrote in message news:<405B5C93.5640C671@cox.net>...
you fid this an alternate-universe concept, too ?
>
> Well, the USGS is running a distributed water database that is about 90
> percent Fortran, and it's still being maintained & updated constantly.
> There's some C in there, but not much. We use a great deal of embedded
> SQL, and IMO it's a lot easier to do in Fortran than in C.
>
> Jim C
>
exactly. From what I understand even Operating systems were written
in Fortran. Up until the late seventies, Fortran was an all-pupose
language, leaving ALGOL, PL/1 in the dust (a contemporary horror,
COBOL, was ubiquitous, but its realm was strictly non-intersecting
with Fortran's).
When the C onslaught came, Fortran folded like an accordion and gave
up everything except "number crunching by people who are not
professional programmers".
Instead of taking C on directly (all that was needed was either
intercallability with C for some low level stuff or actually
replicating a small number of C's dirty features in Fortran) Fortran
tried to defend only its alleged core, but since it was a
fundamentally flawed strategy, C and its descendants have essentially
elimiated Fortran from "grown up" computing, quantitative or not.
The pathetic regulars here cite some remnants from government and
other non-profit applications - but it really too  to see them
arguing about "an allocatable component of a structure without an
explicit inteface to a recursive array valued function only works on
full moon nights" when the language itself has been rendered
non-viable.
| |
| Catherine Rees Lay 2004-03-27, 12:17 am |
| In article <60758fd6.0403210634.730d562e@posting.google.com>, analyst41
<analyst41@hotmail.com> writes
>"James F. Cornwall" <JCornwall@cox.net> wrote in message
>news:<405B5C93.5640C671@cox.net>...
> you fid this an alternate-universe concept, too ?
>
>
>exactly. From what I understand even Operating systems were written
>in Fortran. Up until the late seventies, Fortran was an all-pupose
>language, leaving ALGOL, PL/1 in the dust (a contemporary horror,
>COBOL, was ubiquitous, but its realm was strictly non-intersecting
>with Fortran's).
>
>When the C onslaught came, Fortran folded like an accordion and gave
>up everything except "number crunching by people who are not
>professional programmers".
>
>Instead of taking C on directly (all that was needed was either
>intercallability with C for some low level stuff or actually
>replicating a small number of C's dirty features in Fortran) Fortran
>tried to defend only its alleged core, but since it was a
>fundamentally flawed strategy, C and its descendants have essentially
>elimiated Fortran from "grown up" computing, quantitative or not.
>
>The pathetic regulars here cite some remnants from government and
>other non-profit applications - but it really too to see them
>arguing about "an allocatable component of a structure without an
>explicit inteface to a recursive array valued function only works on
>full moon nights" when the language itself has been rendered
>non-viable.
That would be those of us who are prepared to put both our names and the
companies we work for to our posts, I guess. How very pathetic of us.
I don't work for a government. I don't write non-profit applications. I
don't use non-viable languages. And if C and its descendants define
"grown-up" computing, thank goodness so many important systems are, and
continue to be, written in nice simple baby languages.
Ga goo goo,
Catherine.
--
Catherine Rees Lay
To email me, use my first name in front of the "at".
| |
| West Coast Engineering 2004-03-27, 12:17 am |
| foraker@hotmail.com (Matthew) wrote:
>www.fortranstatement.com
Matthew,
Most of the time I am reserved and nice to people but you sir are a
XXXXING XXXXXXX.
WCE
| |
| James Giles 2004-03-27, 12:17 am |
| analyst41 wrote:
....
> Instead of taking C on directly (all that was needed was either
> intercallability with C for some low level stuff or actually
> replicating a small number of C's dirty features in Fortran) Fortran
> tried to defend only its alleged core, but since it was a
> fundamentally flawed strategy, C and its descendants have essentially
> elimiated Fortran from "grown up" computing, quantitative or not.
"Grown up"? I guess that's why most C code looks like it was
written by a talentless eight year old?
You keep coming up with this tired old argument. C didn't beat
out Fortran alone - it beat out lots of other languages as well.
Some of which (like Turing plus) had *all* the "dirty" features
of C but was *vastly* better designed (ie. easier to write, read,
verify, maintain, reuse, etc.). So, if the existence of C's "dirty"
features was the death of Fortran, why did C also beat these
other languages?
In the real world, rather than the one you seem to live in, language
popularity is not in any way correlated with features supported or
quality of design. That, however, is not a reason to abandon quality
design, or adopt bad features, or omit good features. You'd have
us do all the above.
--
J. Giles
| |
| Richard Steiner 2004-03-27, 12:17 am |
| Here in comp.lang.fortran,
analyst41@hotmail.com (analyst41) spake unto us, saying:
>When the C onslaught came, Fortran folded like an accordion and gave
>up everything except "number crunching by people who are not
>professional programmers".
That isn't entirely true.
For example, a number of major airlines still heavily use Fortran on
their production systems, and some are still doing a lot of active
in-house application development in that language as well.
And no, it isn't end users who are writing the code. :-)
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
Applications analyst/designer/developer (14 yrs) s ing employment.
See web site above for resume/CV and background.
| |
| Walt Brainerd 2004-03-27, 12:17 am |
| analyst41 wrote:
> The pathetic regulars here cite some remnants from government and
> other non-profit applications -
You might be interested in some of the places where
I have given onsite Fortran training recently:
Ontario Power
Schlumberger
Lockheed
Duke Energy
Compaq
Atomic Energy of Canada. Ltd (well, that is probably
gov't subsidized, but so are the oil companies
in the US)
An insurance company
Westinghouse
Another insurance company
An electric utility in Dallas
A financial investment company in Manhatten
Two different engineering companies that design
and build special chips/boards
A company that builds auxiliary engines to
power the A/C, etc when your plane is on the
ground
Northwest Airlines (software to control their
simulators)
And yes, I have been to quite a few gummint
institutions, also.
--
Walt Brainerd +1-877-355-6640 (voice & fax)
The Fortran Company +1-520-760-1397 (outside USA)
6025 N. Wilmot Road walt@fortran.com
Tucson, AZ 85750 USA http://www.fortran.com
| |
| Gary L. Scott 2004-03-27, 12:17 am |
| West Coast Engineering wrote:
>
> foraker@hotmail.com (Matthew) wrote:
>
>
> Matthew,
>
> Most of the time I am reserved and nice to people but you sir are a
> XXXXING XXXXXXX.
>
> WCE
Where's the FCC when you need them. Let me see, that looks like about a
$247,000 fine.
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson
| |
| Dr Chaos 2004-03-27, 12:17 am |
| On 21 Mar 2004 06:34:00 -0800, analyst41 <analyst41@hotmail.com> wrote:
>
> When the C onslaught came, Fortran folded like an accordion and gave
> up everything except "number crunching by people who are not
> professional programmers".
>
> Instead of taking C on directly (all that was needed was either
> intercallability with C for some low level stuff or actually
> replicating a small number of C's dirty features in Fortran)
Actually, it would have meant being able to interpret arbitrary
C code and C preprocessor macros in operating system header files.
Is that feasible to do in Fortran? I don't see it.
> Fortran
> tried to defend only its alleged core, but since it was a
> fundamentally flawed strategy, C and its descendants have essentially
> elimiated Fortran from "grown up" computing, quantitative or not.
What *specifically* would have make a difference?
> The pathetic regulars here cite some remnants from government and
> other non-profit applications - but it really too to see them
> arguing about "an allocatable component of a structure without an
> explicit inteface to a recursive array valued function only works on
> full moon nights" when the language itself has been rendered
> non-viable.
| |
| Ron Shepard 2004-03-27, 12:17 am |
| In article <405E45CB.BD57FE1A@ev1.net>,
"Gary L. Scott" <garyscott@ev1.net> wrote:
>
> Where's the FCC when you need them. Let me see, that looks like about a
> $247,000 fine.
We clearly need a 5-second delay in c.l.f.
$.02 -Ron Shepard
| |
| Jan C. Vorbrüggen 2004-03-27, 12:17 am |
| > > > During the dying-off period of fortran (late 1970s to early 1990s) All
>
> You seem to have an English-comprehension problem.
Is that so? I responded to your "all low level dirty stuff was done with C
....during that period" re-quoted above, and gave particular examples of low
level dirty stuff including database internals, which you also mentioned.
And that was new development, for a high-energy physics experiment that was
only then starting up.
I will conclude that _you_ have a reading-comprehension problem.
Jan
| |
| Jan C. Vorbrüggen 2004-03-27, 12:17 am |
| > Instead of taking C on directly (all that was needed was either
> intercallability with C for some low level stuff or actually
> replicating a small number of C's dirty features in Fortran)
On well-defined platforms, that was available very early - as early
as a C compiler becoming available (yes, Fortran was there first).
But people were taught an ill-defined langauge - C - on an ill-defined
platform - Unix -, and it is impossible to standardize against something
that has no agreed-upon definition - which was the case for C until at
least 1990. And - surprise, surprise! - at about the same time F90 was
standardized, which supported a lot of C's "dirty features", e.g., pointers.
But what use is aguing with you? I'm sure that when asked, you will argue
that the success of the current video standard, when compared to Betamax
for instance, is due to its technical superiority.
Jan
| |
| analyst41 2004-03-27, 12:17 am |
| Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnc5sos2.4oj.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
> On 21 Mar 2004 06:34:00 -0800, analyst41 <analyst41@hotmail.com> wrote:
>
> Actually, it would have meant being able to interpret arbitrary
> C code and C preprocessor macros in operating system header files.
>
> Is that feasible to do in Fortran? I don't see it.
am doing both as we speak.
I have a mixed language application in production that is in Fortran,
but calls C routines for database access.
You have translated "intercallability with C for some low level stuff"
into "the ability to interpret arbitrary C code".
My fortran (Sun f77) allows long variable names, command line
args,non-statically dimnesioned arrays, flush,bounds checking without
performance degradation - reasons I have been able to keep Fortran
alive in my environment, although I am its sole advocate.
>
>
> What *specifically* would have make a difference?
WHy only ask me ? Haven't others seen "fortran to C/C++/Java" porting
projects ? Isn't it a simple matter of interviewing folks involved
and finding out why ?
Please see above. The really non-'grown-up' thing about Fortran is
its "record-I/O" - a punched-card holdover. reads from an external
medium should be handled as
call fread(file identifier,ask,get,condition code)
where ask and get are in bytes. In another incarnation, a whole group
of us were able to keep Fortran alive by using this extension to read
large files efficiently.
| |
| Harold W. Stevens 2004-03-27, 12:17 am |
| In <405EAB35.BD8041B9@mediasec.de>, Jan C Vorbrüggen:
> But what use is aguing with you?
There isn't--analyst41 has trolled from gitgo. I plonked it shortly after
it inanely badgered Richard Maine about C pointers or some such way back.
Why hustle J3 directly, when you can snipe instead from Usenet ambushes?
--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
Standard Disclaimer: These are my opinions not Internet America.
| |
| Rich Townsend 2004-03-27, 12:17 am |
| analyst41 wrote:
>
> Please see above. The really non-'grown-up' thing about Fortran is
> its "record-I/O" - a punched-card holdover. reads from an external
> medium should be handled as
>
> call fread(file identifier,ask,get,condition code)
>
> where ask and get are in bytes. In another incarnation, a whole group
> of us were able to keep Fortran alive by using this extension to read
> large files efficiently.
Well, why aren't you using a platform-agnostic data format like netCDF
or HDF4/5, all of which have well-defined Fortran bindings?
| |
| James F. Cornwall 2004-03-27, 12:17 am |
| analyst41 wrote:
>
> "James F. Cornwall" <JCornwall@cox.net> wrote in message news:<405B5C93.5640C671@cox.net>...
> you fid this an alternate-universe concept, too ?
>
> exactly. From what I understand even Operating systems were written
> in Fortran. Up until the late seventies, Fortran was an all-pupose
> language, leaving ALGOL, PL/1 in the dust (a contemporary horror,
> COBOL, was ubiquitous, but its realm was strictly non-intersecting
> with Fortran's).
>
> When the C onslaught came, Fortran folded like an accordion and gave
> up everything except "number crunching by people who are not
> professional programmers".
>
> Instead of taking C on directly (all that was needed was either
> intercallability with C for some low level stuff or actually
> replicating a small number of C's dirty features in Fortran) Fortran
> tried to defend only its alleged core, but since it was a
> fundamentally flawed strategy, C and its descendants have essentially
> elimiated Fortran from "grown up" computing, quantitative or not.
>
> The pathetic regulars here cite some remnants from government and
> other non-profit applications - but it really too to see them
> arguing about "an allocatable component of a structure without an
> explicit inteface to a recursive array valued function only works on
> full moon nights" when the language itself has been rendered
> non-viable.
Pathetic, eh? Shame you are so fixated on taking Fortran back a couple
of decades and throwing out the good things that have been put in since
then. Use what you like, ignore the rest, and Fortran will still keep
chugging along.
Have an adequate day...
Jim C
--
****************************************
************
** Facilior veniam posterius quam prius capere! **
****************************************
************
** James F. Cornwall, sole owner of all opinions **
** expressed in this message... **
****************************************
************
| |
| analyst41 2004-03-27, 12:17 am |
| "James Giles" <jamesgiles@worldnet.att.net> wrote in message news:<t2o7c.12802$PY1.289534@bgtnsc05-news.ops.worldnet.att.net>...
> analyst41 wrote:
> ...
>
> "Grown up"? I guess that's why most C code looks like it was
> written by a talentless eight year old?
It sure does - but since Capitalism drives everything in the world,
let us give C (to me C means C/C++/JAVA) its due - C being the
foundation of Microsoft ORACLE etc. - not to speak of innumerable C
applications (including quantitative ones) running in tax-paying
corporations does mean something.
C won the ultimate contest - it gets used. If we refuse to see that C
did something right - then thats truly childish.
>
> You keep coming up with this tired old argument. C didn't beat
> out Fortran alone - it beat out lots of other languages as well.
> Some of which (like Turing plus) had *all* the "dirty" features
> of C but was *vastly* better designed (ie. easier to write, read,
> verify, maintain, reuse, etc.). So, if the existence of C's "dirty"
> features was the death of Fortran, why did C also beat these
> other languages?
I don't give a flying XXXX about truly clean languages or languages
that did dirty things cleanly that got used by a grand total of <= 3
people even BEFORE C did them in.
That C has (probably) irreparably decimated Fortran's user base is a
fact. If my reasons why are incorrect - we should find the true
reasons and discover is there any way the user base can be brought
back. A REALLY tired argument in this regard would be "irrationality
of decision makers in software projects".
>
> In the real world, rather than the one you seem to live in, language
> popularity is not in any way correlated with features supported or
> quality of design. That, however, is not a reason to abandon quality
> design, or adopt bad features, or omit good features. You'd have
> us do all the above.
A lot of "good" features in Fortran 90 onwards are like one's mother's
admonitions "stand up straight", "get regular exercise", "eat fiber"
etc. They are actually good for you, except that real people don't
follow them.
| |
| Richard Maine 2004-03-27, 12:17 am |
| analyst41@hotmail.com (analyst41) writes:
> ... but since Capitalism drives everything in the world,
and various other broad unsupported generalizations, ad hominem
attacks, plus a few obscenities thrown in just to make sure
that we can appropriately place the level of argument. Perhaps
he should have paid more attention to some of mother's admonitions
before labeling other people as childish, tired, quaint,
pathetic, and other such technical terms. But anyway...
Does this mean that it is capitalism that drives the near unanimous
rejection of analyst41's views? I guess it must be working. :-)
Actually, I seriously think that is the answer here. I have no
inherent objection to analyst41 going off with whatever support
he can garner and developing a langauge to suit his exact tastes,
whatever those may be.
Alas (for analyst41), there doesn't seem to be an adequate market
for his proposed product. Or if there is such a market, it appears
to have somehow been overlooked by those capitalists that might
want to take advantage of it. If you truly believed in the proposed
product and in the inherent virtues of capitalism, you'd be out
raising money to make your first million (I made mine quite a while
ago, thank you, just to let you know that you are indeed speaking
to a proper capitalist - I'd be most upset if the government came in
and took over the capital that I've built up). The story of your
sucess as a capitalist would be a lot more interesting reading
than the whines we get treated to instead.
Looks to me like the demonstrated market for standard Fortran is
infinitely larger than the demonstrated market for analyst4's
language. If there is a big unrealized market there, I'm quite
enough of a capitaist to knoww what to do about that. Your
opportunity waits.
In the meantime...
> C won the ultimate contest - it gets used. If we refuse to see that C
> did something right - then thats truly childish.
Seems like Fortran won the ultimate contest over your proposal;
Fortran gets used.
(I might add that the figures I've heard of suggest that the absolute
value of Fortran usage now is higher than it was in the 60's and 70's,
even though its market fraaction is lower. The market grew a lot in
areas outside of Fortran's primary strengths. But apparently some of
us would rather state "facts" that "everyone knows" instead of using
actual data. No, I don't have facts on that available either - the
vendors who do seemto consider it proprietary marketing data.)
--
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
| |
| Dr Chaos 2004-03-27, 12:17 am |
| On 22 Mar 2004 03:29:57 -0800, analyst41 <analyst41@hotmail.com> wrote:
> Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnc5sos2.4oj.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
>
> am doing both as we speak.
>
> I have a mixed language application in production that is in Fortran,
> but calls C routines for database access.
>
> You have translated "intercallability with C for some low level stuff"
> into "the ability to interpret arbitrary C code".
>
> My fortran (Sun f77) allows long variable names, command line
> args,non-statically dimnesioned arrays, flush,bounds checking without
> performance degradation - reasons I have been able to keep Fortran
> alive in my environment, although I am its sole advocate.
>
> WHy only ask me ? Haven't others seen "fortran to C/C++/Java" porting
> projects ? Isn't it a simple matter of interviewing folks involved
> and finding out why ?
They say "management told us Fortran is dying".
| |
| James Giles 2004-03-27, 12:17 am |
| analyst41 wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:<t2o7c.12802$PY1.289534@bgtnsc05-news.ops.worldnet.att.net>...
>
> It sure does - but since Capitalism drives everything in the world,
> let us give C (to me C means C/C++/JAVA) its due - C being the
> foundation of Microsoft ORACLE etc. - not to speak of innumerable C
> applications (including quantitative ones) running in tax-paying
> corporations does mean something.
>
> C won the ultimate contest - it gets used. If we refuse to see that C
> did something right - then thats truly childish.
If you misidentify what C supposedly did right, you're truly
counterproductive. C was in the right place at the right time.
That's pretty much all it did right.
> That C has (probably) irreparably decimated Fortran's user base is a
> fact. If my reasons why are incorrect - we should find the true
> reasons and discover is there any way the user base can be brought
> back. A REALLY tired argument in this regard would be "irrationality
> of decision makers in software projects".
But, the fact that an argument is REALLY tired doesn't make
it false. And yes, the decisions were taken irrationally. The
most popular reason given was that C was so common (this
reason was used clear back in the late 70's - when almost no
one was using C, but that didn't deter the promoters of C from
using the claim). Other promotional C dogmas were as easily
dismissed. There was never a valid *technical* reason to use C.
Ironically, if you had a rational plan for improving Fortran
I might even support the effort. I too think the committee has
gone in some wrong directions since the 80's.
But, trashing the lot and adopting even *worse* features instead
is really not a viable choice. Discarding features very selectively
and discussing genuinely well-designed replacements might be
productive. It would have to be a separate language: no standardized
language can undo design decisions in a timely fashion even if
*everyone* agreed they were mistakes.
So, what are your *specific* recommendations about what
features to delete? And, more important, what are your *specific*
recommendations for what to do instead? Just saying we need more
"dirty features" doesn't address the question. What "dirty features"?
Exacly how would they work? How would they fit in with the parts
of Fortran you plan to keep?
--
J. Giles
| |
| Dr Chaos 2004-03-27, 12:17 am |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> analyst41 wrote:
>
> If you misidentify what C supposedly did right, you're truly
> counterproductive. C was in the right place at the right time.
> That's pretty much all it did right.
In 1981, it had structures, pointers, malloc, lower case, stream I/O,
and didn't require you to columnate the input source.
Fortran 77's lack of those are pretty annoying. C's lack of real
arrays and integer do loops is also annoying. Why was it necessary to
choose?
Why wasn't there Fortran 80 giving all those features?
| |
| James Giles 2004-03-27, 12:17 am |
| Dr Chaos wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
.....
>
> In 1981, it had structures, pointers, malloc, lower case, stream I/O,
> and didn't require you to columnate the input source.
So did a lot of languages before 1981. What's your point?
There was not a single thing C did that many other languages
didn't do *better*. Fortran was not the relevant alternative
to C for many things, so just mentioning things that Fortran
didn't have is not a relevant way of defending the choice to
use C - even then.
C had structures (badly designed: they weren't discriminated),
pointers (badly designed: there's no need for pointer arithmetic,
for example), malloc (badly designed: calloc would be a better
choice for something to promote), lower case (badly designed:
case sensitivity is a poor choice for a programming language),
stream I/O (a feature of the system and library, not the language,
but a capability *all* environments at the time had - including all
Fortran implementations I used - at least as an extension, if the
I/O form existed on the system at all), and free form source (which
nearly all non-C languages of the time allowed, and C's syntax is
otherwise appalling). Which of these is an advantage that C had,
and *no* other language had? In fact, name a system implementation
language in that time frame that *didn't* have *all* these capabilities.
Are any of these features *really* things that C did right? Are any
of them *really* things where Fortran (or any language) should
emulate the C verson of the features? I don't think so.
Again: if you misidentify what C supposedly did right, you're truly
counterproductive.
--
J. Giles
| |
| Dr Chaos 2004-03-27, 12:17 am |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> Dr Chaos wrote:
> ....
>
> So did a lot of languages before 1981. What's your point?
> There was not a single thing C did that many other languages
> didn't do *better*. Fortran was not the relevant alternative
> to C for many things, so just mentioning things that Fortran
> didn't have is not a relevant way of defending the choice to
> use C - even then.
>
> C had structures (badly designed: they weren't discriminated),
> pointers (badly designed: there's no need for pointer arithmetic,
> for example), malloc (badly designed: calloc would be a better
> choice for something to promote), lower case (badly designed:
> case sensitivity is a poor choice for a programming language),
> stream I/O (a feature of the system and library, not the language,
> but a capability *all* environments at the time had - including all
> Fortran implementations I used - at least as an extension, if the
> I/O form existed on the system at all), and free form source (which
> nearly all non-C languages of the time allowed, and C's syntax is
> otherwise appalling). Which of these is an advantage that C had,
> and *no* other language had?
In the early 1980's I remember microcomputers having either Basic, a
tightly restrictive Pascal without general purpose malloc-free, and
modest C compilers. Of those choices, certainly C was superior.
> In fact, name a system implementation
> language in that time frame that *didn't* have *all* these capabilities.
> Are any of these features *really* things that C did right? Are any
> of them *really* things where Fortran (or any language) should
> emulate the C verson of the features? I don't think so.
The particular C version of those features, no---their existence,
yes.
| |
| James Giles 2004-03-27, 12:17 am |
| Dr Chaos wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
....
>
> The particular C version of those features, no---their existence,
> yes.
Well, now your position is out of context. I was addressing an
argument that C is popular because it had those features. I'm
claiming that was obviously not the reason C became popular
since many other languages also had those features. If the
C version of those features is not to be emulated, but merely
their existence, that's support for my statement. The popularity
of a language is never particularly correllated with its quality.
C did not become popular because of its technical merits (whatever
those are, I've never noticed any).
Now, if you're arguing that Fortran should *now* adopt those
features, at least if we can avoid the C version of them, what's
still missing? Stream I/O is the only one I can think of (and
it's usually available as an extension on those platforms where
the system supports it at all). I've never thought it was all that
superior, and that it mainly was needed to deal with C programs
that use it (probably because C is *terrible* at record-based
I/O). F2003 has stream I/O (assuming the system supports it).
--
J. Giles
| |
| beliavsky@aol.com 2004-03-27, 12:17 am |
| Richard Maine <nospam@see.signature> wrote in message news:<m14qsgixyb.fsf@macfortran.local>...
> analyst41@hotmail.com (analyst41) writes:
>
>
> and various other broad unsupported generalizations, ad hominem
> attacks, plus a few obscenities thrown in just to make sure
> that we can appropriately place the level of argument. Perhaps
> he should have paid more attention to some of mother's admonitions
> before labeling other people as childish, tired, quaint,
> pathetic, and other such technical terms. But anyway...
I also dislike arrogant tone of analyst41, but he seems to be an
experienced Fortranner who makes some reasonable points, in an
obnoxious way. He wrote
'When the C onslaught came, Fortran folded like an accordion and gave
up everything except "number crunching by people who are not
professional programmers".
Instead of taking C on directly (all that was needed was either
intercallability with C for some low level stuff or actually
replicating a small number of C's dirty features in Fortran) Fortran
tried to defend only its alleged core, but since it was a
fundamentally flawed strategy, C and its descendants have essentially
elimiated Fortran from "grown up" computing, quantitative or not.'
It is an exagerration to say Fortran "folded", and I do not know if
the particular features he cites would have made a difference. But
there is a big danger in Fortran's current status as a niche numerical
language. The vast majority of programmers are not doing "scientific
computing", and few of them are knowledgable about modern Fortran. In
my company, and I suspect most companies, there are far more of the
non-scientific than scientific programmers, and someone such as the
"Chief Information Officer", who decides what technologies get used,
is much more likely to be drawn from the former group.
In theory, programmers would just "use the best language for the job",
as is commonly advised, and the fact the Fortran is not best language
for writing Windows GUIs (for example) would not affect its use for
number-crunching. But there are reasons, both real and silly, why one
language (currently, C++) tends to push out others. Some real reasons
are that
(1) buying compilers for several languages costs more money, with the
compiler for less-used language typically being more expensive, since
there are fewer users to amortize the fixed cost.
(2) mixed-language programs can be harder to debug and understand, and
also more fragile because they depend on two different products
working together
(3) there are more tools and public-domain code in the dominant
language
The silly reasons stem from the fact that programmers often have false
notions about languages they do not use, and the people who do use
them.
In theory, not being well-suited for writing an operating system or
GUI should not preclude other uses of a language, but it seems to
often work out that way.
Point (1) above is being addressed by the G95 projects and the free or
low-price "non-commercial" compilers marketed by vendors. (2) will be
addressed in Fortran 2003 by C interoperability features, but do not
count on many C programmers learning or caring about them. Sites like
www.fortran.com and www.fortranlib.com ameliorate the third problem.
| |
| Dr Chaos 2004-03-27, 12:17 am |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> Dr Chaos wrote:
> ...
>
> Well, now your position is out of context. I was addressing an
> argument that C is popular because it had those features.
It supplanted use of Fortran 77 when there was a useful
choice between them.
> I'm
> claiming that was obviously not the reason C became popular
> since many other languages also had those features. If the
> C version of those features is not to be emulated, but merely
> their existence, that's support for my statement. The popularity
> of a language is never particularly correllated with its quality.
> C did not become popular because of its technical merits (whatever
> those are, I've never noticed any).
C was popular because it came with things which were free or cheap.
Actually on the earliest Macintoshes the choice was between
some variants of Pascal and C, and the developers quite quickly
wanted C over that Pascal despite many APIs and original
development being done in Pascal.
Maybe C wasn't better than lots of other languages in theory, but
compilers, good and cheap, were not available on small machines.
> Now, if you're arguing that Fortran should *now* adopt those
> features, at least if we can avoid the C version of them, what's
> still missing? Stream I/O is the only one I can think of (and
> it's usually available as an extension on those platforms where
> the system supports it at all). I've never thought it was all that
> superior, and that it mainly was needed to deal with C programs
> that use it (probably because C is *terrible* at record-based
> I/O). F2003 has stream I/O (assuming the system supports it).
Oh sure, Fortran 95/2003 is way better than C.
| |
| analyst41 2004-03-27, 12:17 am |
| Walt Brainerd <walt@fortran.com> wrote in message news:<405E2FCE.9080003@fortran.com>...
> analyst41 wrote:
>
> You might be interested in some of the places where
> I have given onsite Fortran training recently:
>
> Ontario Power
> Schlumberger
> Lockheed
> Duke Energy
> Compaq
> Atomic Energy of Canada. Ltd (well, that is probably
> gov't subsidized, but so are the oil companies
> in the US)
> An insurance company
> Westinghouse
> Another insurance company
> An electric utility in Dallas
> A financial investment company in Manhatten
> Two different engineering companies that design
> and build special chips/boards
> A company that builds auxiliary engines to
> power the A/C, etc when your plane is on the
> ground
> Northwest Airlines (software to control their
> simulators)
>
> And yes, I have been to quite a few gummint
> institutions, also.
Manna from heaven !!
The PHB in my case is a forty-ish PhD in economics - and he has
informed me that he is considering eliminating the Fortran for "risk
mitigation" - ie, difficulty of finding staff willing to code in it
(of course this year Budget is tight, and so I am OK till Dec 2004).
These and the Airline examples that have been cited would help as
counter-arguments ("Nobody uses Fortran anymore" - WROOOOOONG !!!!
"all these private and public sector guys do").
I can do everything that I can ever think of wanting to do in Fortran
77 (with C interop for a few things plus a limited number of
extensions)and I think my code has gem-like qualities (certifed as
such by an ex-boss and colleagues. I have entrusted my sleep (it runs
every morning around 4 am and I'll be called if it breaks) to my f77
code over the past 10 years. I have gone on long vacations without
ever having to worry about being called to support it.
I have always wanted some evidence from this group that Fortran is
currently doing well and that it has prospects of survival in a
variety of settings. I need to be able to defend usage of ANY Fortran
in my present setting before I can start looking at all the great
stuff that have been put into bad old f77 with f90 onwards.
Thank you for finally providing what I have been clamoring for.
| |
| Gary L. Scott 2004-03-27, 12:17 am |
| analyst41 wrote:
>
> Walt Brainerd <walt@fortran.com> wrote in message news:<405E2FCE.9080003@fortran.com>...
>
> Manna from heaven !!
>
> The PHB in my case is a forty-ish PhD in economics - and he has
> informed me that he is considering eliminating the Fortran for "risk
> mitigation" - ie, difficulty of finding staff willing to code in it
> (of course this year Budget is tight, and so I am OK till Dec 2004).
>
> These and the Airline examples that have been cited would help as
> counter-arguments ("Nobody uses Fortran anymore" - WROOOOOONG !!!!
> "all these private and public sector guys do").
>
> I can do everything that I can ever think of wanting to do in Fortran
> 77 (with C interop for a few things plus a limited number of
> extensions)and I think my code has gem-like qualities (certifed as
> such by an ex-boss and colleagues. I have entrusted my sleep (it runs
> every morning around 4 am and I'll be called if it breaks) to my f77
> code over the past 10 years. I have gone on long vacations without
> ever having to worry about being called to support it.
>
> I have always wanted some evidence from this group that Fortran is
> currently doing well and that it has prospects of survival in a
> variety of settings. I need to be able to defend usage of ANY Fortran
> in my present setting before I can start looking at all the great
> stuff that have been put into bad old f77 with f90 onwards.
>
> Thank you for finally providing what I have been clamoring for.
Have him come and teach at your company!?! I once tried but couldn't
get funding.
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson
| |
| James Giles 2004-03-27, 12:17 am |
| Dr Chaos wrote:
....
>
> It supplanted use of Fortran 77 when there was a useful
> choice between them.
But not for any technical reasons.
> C was popular because it came with things which were free or cheap.
So did a lot of research-based languages and systems. And, that's not
a technical reason. Fortran (and any other language) can't regain that
share by adding C features. The claim in this thread has been that
the technical features of C were the reasons for the change in
relative popularity of the languages. I maintain that's simply not
true.
--
J. Giles
| |
| Matthew 2004-03-27, 12:17 am |
| West Coast Engineering < westcoastengineering@westcoastengineerin
g.com> wrote in message news:<lmhr50lia981edhs1vksdkia9c1aqgjt26@4ax.com>...
> foraker@hotmail.com (Matthew) wrote:
>
>
> Matthew,
>
> Most of the time I am reserved and nice to people but you sir are a
> XXXXING XXXXXXX.
>
> WCE
Dear Sir,
Perhaps if you had read the site more closely, and read the thread at
all, you might have realized that
not only am I *NOT* the author of the site, I said as much in the
thread. Perhaps, in these harried times, people do not take the time
before forming opinions and venting their spleen in a public forum.
More's the pity. Though it is not incumbant upon me to do so, perhaps
some explanation is in order.
I merely posted the site not to encourage people to vote one way or
another, but to bring the issue to light and to encourage debate. I
also had some hope that someone with better arguments than me would
make them directly to the author of the site. In fact, this occurred,
if you have but bothered to peruse it more closely. That said, I feel
justified in demanding a public apology of some sort. Your unkind
words were neither professional, nor warranted.
Matthew
| |
| Ron Shepard 2004-03-27, 12:17 am |
| In article <60758fd6.0403220902.6254fbce@posting.google.com>,
analyst41@hotmail.com (analyst41) wrote:
> That C has (probably) irreparably decimated Fortran's user base is a
> fact.
What evidence is there that there are fewer fortran programers now
than 10 years ago, or 20 years ago, or 30 years ago, or 40 years
ago? I don't know any data, but I would guess that the number of
fortran programmers has increased during the past 40 years, not
decreased. As far as the past 10 years, look at how active this
newsgroup is, there are more messages now than 10 years ago when I
first started following it.
$.02 -Ron Shepard
| |
| Ron Shepard 2004-03-27, 12:17 am |
| In article <slrnc5um10.6se.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>,
Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote:
> Why wasn't there Fortran 80 giving all those features?
At that time the standards committee was dominated by vendors, not
by programmers. The vendors did not want the language improved for
various reasons. Most of those vendors are now out of business.
One of them, Digital Equipment Corporation, went in my mind from one
of the best companies to support scientific programming to one of
the worst offenders. However, within the decade they went out of
business. Convex was another company that was highly critical of
improving the fortran language in the 80's.
What *SHOULD* have happened was that there should have been a series
of minor improvements, every 2 to 4 years, during the 80's. F80
should have been F77 plus the MIL-STD extensions. Then there should
have been ALLOCATE() and array syntax a couple of years later. I'd
guess that a standard preprocessor could have been agreed upon
during that time too if programmers had been in control of the
committee. I don't think the language that would have resulted in
1990 would have been that much different from what actually
resulted, but fortran would not have lost a whole decade of new
programmers during that time.
Remember, F90 was an international ISO standard *BEFORE* it was a US
standard. That was because the vendors on the committee were still
dragging their feet, even in 1990.
$.02 -Ron Shepard
| |
| Michael Metcalf 2004-03-27, 12:17 am |
|
"Ron Shepard" <ron-shepard@NOSPAM.comcast.net> wrote in message
news:ron-shepard-6E2688.00202323032004@comcast.ash.giganews.com...
> In article <slrnc5um10.6se.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>,
> Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote:
>
>
> At that time the standards committee was dominated by vendors, not
> by programmers. The vendors did not want the language improved for
> various reasons. Most of those vendors are now out of business.
Yes, there was visceral opposition from Harris and Convex, and DEC and IBM
wanted no new standard so as to keep customers locked into their own
compilers with extensions. DEC and IBM saw the light in 1988 when WG5
threatened to take the standard out of the hands of X3J3 and publish it
internationally. With their sudden support, the rest was plain sailing.
Harris and Convex never changed their view.
Regards,
Mike Metcalf
| |
| William Clodius 2004-03-27, 12:17 am |
|
Ron Shepard wrote:
> In article <slrnc5um10.6se.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>,
> Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote:
>
>
> At that time the standards committee was dominated by vendors, not
> by programmers. The vendors did not want the language improved for
> various reasons.
Not quite, although the vendors did want a much more limited set of
improvements, preferably based on a current implementations on some
processor. The one area where I view their position as completely
unrealistic was the general opposition to free form.
Effectively one side viewed the better as being the enemy of the best,
the other side viewed perfection as the enemy of the good enough.
> Most of those vendors are now out of business.
> One of them, Digital Equipment Corporation, went in my mind from one
> of the best companies to support scientific programming to one of
> the worst offenders. However, within the decade they went out of
> business. Convex was another company that was highly critical of
> improving the fortran language in the 80's.
>
> What *SHOULD* have happened was that there should have been a series
> of minor improvements, every 2 to 4 years, during the 80's. F80
> should have been F77 plus the MIL-STD extensions.
That time scale is unachievable due to the realities of people and
beaurocracies. A four to five year time scale might have been
achievable.
> Then there should
> have been ALLOCATE() and array syntax a couple of years later. I'd
> guess that a standard preprocessor could have been agreed upon
> during that time too if programmers had been in control of the
> committee. I don't think the language that would have resulted in
> 1990 would have been that much different from what actually
> resulted, but fortran would not have lost a whole decade of new
> programmers during that time.
>
> Remember, F90 was an international ISO standard *BEFORE* it was a US
> standard. That was because the vendors on the committee were still
> dragging their feet, even in 1990.
>
> $.02 -Ron Shepard
--
-------------------------------------------------------------
William B. Clodius Space & Remote Sensing Sciences
Tech. Staff Member, ISR-2 Phone: (505) 665-9370
Mail Stop B244 FAX: (505) 665-4414
Los Alamos National Lab. Group office: (505) 667-5776
Fed Ex add: Bikini Atoll Rd. Email: remove gibberish
Los Alamos, NM 87545
-------------------------------------------------------------
| |
| Richard Maine 2004-03-27, 12:17 am |
| William Clodius <wclodius@gibberish.lanl.gov> writes:
> Ron Shepard wrote:
>
> That time scale is unachievable due to the realities of people and
> beaurocracies. A four to five year time scale might have been
> achievable.
For a point of reference, the bureaucratic process alone takes about 2
years. The f2003 CD was released in Sept of 2002. If all goes
perfectly, the standard will be formally published in Dec of 2004;
wouldn't surprise me at all if the actual printing slipped into 2005
(though that would be an annoyance - we might have to change the
darned ISO formal citation). Though some technical changes have been
made since the CD, the process would not have been significantly
shorter even if the CD ended up, word for word, becoming the standard.
The process just takes that long. And no, the Fortran committees do
not have much leverage to streamline it. Nor does anyone on this
newsgroup. Heck, what we are doing is a slightly streamlined version
- two of the early stage votes get combined into one. We have to get
approval for that particular shortcut, but it seems to be pretty
routinely granted.
Oh yes, and another major shortcut is that this is done in such
a way that the separate US approval cycle is pretty much avoided
completely. I forget the exact details; there may be some token
step, but it isn't a major separate process like it was for f90.
Mostly the US agrees at the outset of the project that it will
rubber stamp what comes out of ISO instead of doing its own
thing.
Two years between standards is just undoable. (And I'm not even
considering time for implementors to do their thing -- I'm just
looking at the standardization process alone.)
As Bill says, 4-5 years is just barely doable. That assumes the
changes are modest and not hugely controversial. F95 is a good sample
of that. It was... I'd have to check the exact dates, but something
on the order of 6 years after f90 (the ISO version of f90. Though the
US one took a long time afterwards, it didn't involve a whole lot of
direct J3 work; in particular, it didn't hold up work on f95.) The
changes involved were pretty modest and not hugely controversial.
That was a very busy 6 years. I know I was working awfully hard on
it, and I wasn't alone. I recall one of the Hawaii meeetings where I
managed only about 3 hours of sleep for 4 nights in a row - and I
swear I was so intensly involved I was dreaming Fortran questions for
those few hours. Not going to pull that one again, but I distinctly
recall getting kidded about the perk of having a meeting in
Hawaii... when in fact it was probably among the hardest working ws
I've ever had. My wife and daughter came along, but I didn't see much
of them until the wend after. Got a 2-bedroom condo so that I
could work most of the night in one area without keeping them from
sleeping.
You need to set goals that are at least close to achievable in order
to make things happen. I don't see 2 years as fitting that criterion.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| glen herrmannsfeldt 2004-03-27, 12:17 am |
| Richard Maine wrote:
> William Clodius <wclodius@gibberish.lanl.gov> writes:
[color=darkred]
[color=darkred]
[color=darkred]
> For a point of reference, the bureaucratic process alone takes about 2
> years. The f2003 CD was released in Sept of 2002. If all goes
> perfectly, the standard will be formally published in Dec of 2004;
> wouldn't surprise me at all if the actual printing slipped into 2005
Is there a rule against starting the next one before the previous
one is published?
Not that the analogy is very good, but it takes the E. Coli
bacteria 40 minutes to duplicate its DNA. It can divide
every 20 minutes, which means it must start the next duplication
before the previous one is finished.
There are probably also analogies with pipelined
processors, but I think that one should be close enough.
Though with the delay after the standard in getting compilers
out, I don't think there is much point in doing it much
faster.
-- glen
| |
| Richard Maine 2004-03-27, 12:17 am |
| glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Is there a rule against starting the next one before the previous
> one is published?
No rule, but it tends to be hard to work. In theory we were going to
do f95 and f2003 (well, it was being called f2000 then) in parallel,
with the near term smaller stuff in f95 and bigger changes in f2003.
But in practice almost nothing got started on f2003 until f95 was done.
Well, it didn't wait for final official publication, as J3 had very
little to do with it for about the last half year. But it did have
to wait until J3 was done with the work on f95.
It is just hard to maintain adequate focus in working on two
different releases in parallel. Particularly with the small number
of people involved.
I won't say it couldn't ever be done, but the attempt to do f95
and f2003 in parallel didn't work.
> Though with the delay after the standard in getting compilers
> out, I don't think there is much point in doing it much
> faster.
That's also an issue. People would like the time for some feedback on
experience with one version before getting too awfully far along on
the next. For example, some people would prefer that we do nothing at
all towards f2003+ until there have been f2003 compilers out for long
enough for people to have experience using them. Well, that's likely
to be several years. I personally think it reasonable to start now
and do some work before then, but I certainly agree that we shouldn't
be so far down the road that changes can't be made based on such
feedback.
--
Richard Maine
email: my last name at domain
domain: sumertriangle dot net
| |
| Gary L. Scott 2004-03-27, 12:17 am |
| Michael Metcalf wrote:
>
> "Ron Shepard" <ron-shepard@NOSPAM.comcast.net> wrote in message
> news:ron-shepard-6E2688.00202323032004@comcast.ash.giganews.com...
>
> Yes, there was visceral opposition from Harris and Convex, and DEC and IBM
> wanted no new standard so as to keep customers locked into their own
> compilers with extensions. DEC and IBM saw the light in 1988 when WG5
> threatened to take the standard out of the hands of X3J3 and publish it
> internationally. With their sudden support, the rest was plain sailing.
> Harris and Convex never changed their view.
That seems odd to me. Harris was quite advanced in its support of a
very large number of the F90 extensions, back in the 1981 timeframe.
They did have some unique extensions that we used quite extensively. In
the end, that was quite an advantage to us. Our Customer kept insisting
that we give our proprietary code away to competitors (because THEY PAID
FOR IT). Since it wasn't very portable code, it wasn't very helpful to
those competitors.
>
> Regards,
>
> Mike Metcalf
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson
| |
| Matthew 2004-03-27, 12:18 am |
| West Coast Engineering < westcoastengineering@westcoastengineerin
g.com> wrote in message news:<lmhr50lia981edhs1vksdkia9c1aqgjt26@4ax.com>...
> foraker@hotmail.com (Matthew) wrote:
>
>
> Matthew,
>
> Most of the time I am reserved and nice to people but you sir are a
> XXXXING XXXXXXX.
>
> WCE
I guess he's not nearly as nice as he imagines himself to be. :-)
He's certainly seems unwilling to step forward and say 'You know, that was
childish and immature, not to mention uncalled for, and I'm sorry'.
| |
| Dr Chaos 2004-03-27, 12:18 am |
| On 18 Mar 2004 04:41:28 -0800, beliavsky@aol.com <beliavsky@aol.com> wrote:
> Dr Chaos wrote:
>
><SNIP>
>
>
> A physics professor told me recently that "there is a split in the
> world of CS departments that teach Java or C++, and the computational
> science community that uses Fortran. At the moment, the view in the CS
> community is against teaching most any compiled language."
>
> Science and engineering departments should not leave the teaching of
> computer programming entirely to the CS departments -- or leave their
> students completely dependent on MATLAB.
he. In my physics undergraduate education, the math department taught
me Lesbegue integrals, but I never saw a differential
equation or Fourier transform. Teaching of real E&M started with
Laplace's equation and the legendre polynomials, assuming you already
knew the 'obvious' Fourier transforms.
Teaching programming? They probably thought that was like teaching
pencil sharpening.
Note, I'm not saying this was a good idea.
And I still need an electric pencil sharpener.
| |
| Michael Metcalf 2004-03-27, 12:18 am |
|
"Gary L. Scott" <garyscott@ev1.net> wrote in message
news:4060EB68.E8DA91BA@ev1.net...
>
> That seems odd to me. Harris was quite advanced in its support of a
> very large number of the F90 extensions, back in the 1981 timeframe.
You can see what Bill Leonard wrote about it in his article in "Computer
Standards & Interfaces", 18, North Holland/Elsevier, 1996.
Regards,
Mike Metcalf
| |
| Gary L. Scott 2004-03-27, 12:18 am |
| Michael Metcalf wrote:
>
> "Gary L. Scott" <garyscott@ev1.net> wrote in message
> news:4060EB68.E8DA91BA@ev1.net...
>
> You can see what Bill Leonard wrote about it in his article in "Computer
> Standards & Interfaces", 18, North Holland/Elsevier, 1996.
Thanks, Will see if I can locate it. I know that this advanced "F90"
support of these and other features such as inline assembly and data
pools were among reasons why we chose Harris mini's for our simulation
tool set (and no regrets either).
>
> Regards,
>
> Mike Metcalf
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson
| |
| William Clodius 2004-03-27, 12:18 am |
|
"Gary L. Scott" wrote:
> Michael Metcalf wrote:
>
> That seems odd to me. Harris was quite advanced in its support of a
> very large number of the F90 extensions, back in the 1981 timeframe.
> They did have some unique extensions that we used quite extensively. In
> the end, that was quite an advantage to us. Our Customer kept insisting
> that we give our proprietary code away to competitors (because THEY PAID
> FOR IT). Since it wasn't very portable code, it wasn't very helpful to
> those competitors.
> <snip>
Are you certain you don't mean the 1991 timeframe? If it was the 1981 time
frame there were very few F90 extensions that were defined. The MIL_STD was in
existence by then, so lower case, eight character variables, labeled ENDDO, (DO
WHILE?) and the bit intrisics had well accepted definitions, but little else.
These were the additions to F77 that almost no vendor opposed because they
already had to support them if they had military contracts. In 1981 no detailed
specifications existed for free form, derived types, unlabelled ENDDO, SELECT
CASE, named constructs, recursive procedures, the machine model intrinsics,
array math, allocatable arrays, pointers, internal subprograms, selected kinds,
or modules. With the possible exceptions of unlabelled ENDDO and integer SELECT
CASE almost all of the non-MIL-STD additions by F90 were controversial with
several vendors for various reasons: lack of experience, magnitude of growth of
the language, lack of consideration of the interaction of the extension with
common extensions, and failure to adopt an existing similar extension that was
already implemented by one or more vendors. (The last was a problem for the
committee as if they adopted a specific variant of an extension it seemingly
favored one vendor over another, but if the major vendors had compiler switches
to implement one anothers variants, the relative cost for those vendors was
smaller than implementing another variant invented by the committee. Therefore
the committee's version was sometimes viewed as a gratuitous complication.)
Also note that many vendors had hand written recursive descent parsers, that
had grown ad hoc in adding various extensions, and the magnitude of F90's
changes meant that that part of the compiler had to be rewritten from scratch.
--
-------------------------------------------------------------
William B. Clodius Space & Remote Sensing Sciences
Tech. Staff Member, ISR-2 Phone: (505) 665-9370
Mail Stop B244 FAX: (505) 665-4414
Los Alamos National Lab. Group office: (505) 667-5776
Fed Ex add: Bikini Atoll Rd. Email: remove gibberish
Los Alamos, NM 87545
-------------------------------------------------------------
| |
| John Harper 2004-03-27, 12:18 am |
| In article <4061B694.B3E1CF11@gibberish.lanl.gov>,
William Clodius <wclodius@gibberish.lanl.gov> wrote:
>
> In 1981 no detailed specifications existed for free form
The IBM VS Fortran Language Reference manual (February 1981) did give
detailed specifications for free form, as an IBM language extension,
but different from what f90 gave us: no ! or & in the character set,
" in column 1 instead of ! anywhere to start a comment,
- instead of & at end of line to conti | | |