Home > Archive > Fortran > March 2007 > Aren't the fuddy-duddies in the group going to comment on Fortress
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 |
Aren't the fuddy-duddies in the group going to comment on Fortress
|
|
| analyst41@hotmail.com 2007-03-10, 7:08 pm |
| http://research.sun.com/minds/2005-0302/
It will of course go nowhere, because its yet another attempt to"to
paint the lily" or "to gild refined gold" or even "to throw a perfume
on the violet" - examples that Shakespeare used to demonstrate
"ridiculous excess."
A language that "makes the mathematical parts of a program look like
mathematics" is a bit of fatuity that insults the intelligence of the
average Fortranner (reminds me of COBOL's "add one to counter" style
of syntax to help business programmers.).
But if it does come into existence - it should throw the current
(aesthetically criminal) custodians of Fortran even more on the
defensive - because apparently it would have a lot features currently
deemed "sexy" that officlal Fortran doesn't have or has only as a
"yes,but".
At any rate, if this development brings out more clearly that backward
compatibility with Fortran 77 is the only raison d'etre for official
Fortran , then that would be a good thing.
| |
|
|
<analyst41@hotmail.com> wrote in message
news:1173536983.589504.312500@t69g2000cwt.googlegroups.com...
> http://research.sun.com/minds/2005-0302/
>
> It will of course go nowhere, because its yet another attempt to"to
> paint the lily" or "to gild refined gold" or even "to throw a perfume
> on the violet" - examples that Shakespeare used to demonstrate
> "ridiculous excess."
>
> A language that "makes the mathematical parts of a program look like
> mathematics" is a bit of fatuity that insults the intelligence of the
> average Fortranner (reminds me of COBOL's "add one to counter" style
> of syntax to help business programmers.).
>
> But if it does come into existence - it should throw the current
> (aesthetically criminal) custodians of Fortran even more on the
> defensive - because apparently it would have a lot features currently
> deemed "sexy" that officlal Fortran doesn't have or has only as a
> "yes,but".
>
> At any rate, if this development brings out more clearly that backward
> compatibility with Fortran 77 is the only raison d'etre for official
> Fortran , then that would be a good thing.
>
The question has been raised once before. There was little interest. Current
Fortress is an interpreted language running on a Java VM, so is not
competitive. The language looks nice, and doesn't seem to have the fatuity
to which you refer - perhaps because of different backgrounds. The
mathematical approach appeared to be closer to the problems of APL - so many
symbols as to make programs harder to understand. With use this may go
away - the Chinese cope well with their symbol-rich language, compared to 26
or so symbols (maybe up to 127/255) with Western European languages.
I've never thought of the 'custodians of Fortran' as backward, criminal, or
whatever - they seem to do a good job, putting constructs into the language
when found useful, letting vendors experiment with new constructs where
fashion makes it the case.
Summary: Fortress looks worth watching. But the list of Fortran killers
started with Algol and has yet to stop; and while they have whittled away at
Fortran, Fortran seems to have surmounted them. Should Fortran go the way of
Algol 68 we'll cope.
| |
| Beliavsky 2007-03-10, 7:08 pm |
| Your reply was reasonable, but each of the
(1) subject line
(2) identity of the author
(3) message body
of the original message indicated a troll, which is best ignored.
| |
| analyst41@hotmail.com 2007-03-10, 7:08 pm |
| On Mar 10, 10:42 am, "max" <n...@none.com> wrote:
> <analys...@hotmail.com> wrote in message
>
> news:1173536983.589504.312500@t69g2000cwt.googlegroups.com...
>
>
>
>
>
>
>
>
>
>
> The question has been raised once before. There was little interest. Current
> Fortress is an interpreted language running on a Java VM, so is not
> competitive. The language looks nice, and doesn't seem to have the fatuity
> to which you refer - perhaps because of different backgrounds.
I was directly quoting from the interview with Guy Steele:
"What if we tried really hard to make the mathematical parts of a
program look like mathematics?"
>From what I understand of Fortress, AB will be interpreted as A*B
because mathematicians write products that way. To me these kinds of
"features" are just fluff ( ditto things like operator overloading,
derived types etc.).
Fortran will live if and only if
(0) It supports legacy code.
(1) It remains a small,fast language.
(2) The language allows for relatively simple compilers to be written.
(3) It has to be able to do dirty things
a) either as part of the language (without violating 1 and 2 above)
b) or as extensions supported by most vendors
c) or mixed language (C primarily) programming or by calling object
code complied from other languages.
Dirty things would include pipes,system calls, command line arguments,
accessing databases, Byte stream I/O (to support newer filetypes) to
name a few.
(4) This is a tough one - allow for parallel processing. It would be
best if opportunities for parallelization are recognized by the
compiler - but if explicit parallelization cannot be introduced into
Fortran without destroying the look and feel of the language then
perhaps the explicitly parallel operations should be done with C
routines callable from Fortran.
The philosophy of the official Fortran enhancement path seems to have
been to add a gazillion features considered "modern" as (0) was
maintained - and the result is a  failure - just about EVERY
"modern" feature in Fortran is a "Yes,but".
Do you have pointers ? yes, but....
Do you have OOP ? yes, but ....
Do you have dynamic memory ? yes, but...
The elementary C notion of variable length string seems to give
Fortran a stroke. My suggestion - If it is that hard - then DON'T DO
IT FORTRAN - do it through C-interop.
You mention Fortran-killers - the most dangerous Fortran killers out
there are the post-fortran 77 official Fortrans out there.
The
> mathematical approach appeared to be closer to the problems of APL - so many
> symbols as to make programs harder to understand. With use this may go
> away - the Chinese cope well with their symbol-rich language, compared to 26
> or so symbols (maybe up to 127/255) with Western European languages.
>
> I've never thought of the 'custodians of Fortran' as backward, criminal, or
> whatever - they seem to do a good job, putting constructs into the language
> when found useful, letting vendors experiment with new constructs where
> fashion makes it the case.
>
> Summary: Fortress looks worth watching. But the list of Fortran killers
> started with Algol and has yet to stop; and while they have whittled away at
> Fortran, Fortran seems to have surmounted them. Should Fortran go the way of
> Algol 68 we'll cope.- Hide quoted text -
>
> - Show quoted text -
| |
| Sebastian Hanigk 2007-03-10, 7:08 pm |
| analyst41@hotmail.com writes:
> (4) This is a tough one - allow for parallel processing. It would be
> best if opportunities for parallelization are recognized by the
> compiler - but if explicit parallelization cannot be introduced into
> Fortran without destroying the look and feel of the language then
> perhaps the explicitly parallel operations should be done with C
> routines callable from Fortran.
Thread-level parallelism via OpenMP and more explicit parallelisation
via MPI are available. Co-Array Fortran looks very nice and personally I
would throw out the whole OO stuff from the standard and push Co-Arrays.
> Do you have OOP ? yes, but ....
Object orientation shouldn't have gotten into the standard. It has its
uses, yes, but so many people advocate it as the silver bullet that
solves every software problem, which is clearly false.
The field of software architecture has in some ways made progress by
adopting OO principles, but I think that these (good) principles do not
depend on explicit language support.
> Do you have dynamic memory ? yes, but...
Well, since Fortran 90, arrays and the like can be allocated at run
time. What kind of dynamic memory do you have in mind?
> The elementary C notion of variable length string seems to give
> Fortran a stroke. My suggestion - If it is that hard - then DON'T DO
> IT FORTRAN - do it through C-interop.
I'm not quite sure what you mean by that. Is it the Fortran version of
variable-length strings or the usual fixed-length strings? I haven't had
much trouble with fixed-length ones, in fact, I'm finding them more
comfortable ...
Sebastian
| |
| Gordon Sande 2007-03-10, 7:08 pm |
| On 2007-03-10 14:13:07 -0400, analyst41@hotmail.com said:
> The elementary C notion of variable length string seems to give
> Fortran a stroke. My suggestion - If it is that hard - then DON'T DO
> IT FORTRAN - do it through C-interop.
I am always a bit  by such comments. C strings are not all that good.
I have the collection of C string functions available in my private "library".
Once the "I0" formatting arrived to match "A" formatting my use of the C
strings went down a lot. The only remaining thing that I use much is my
token extraction functions that happen to be missing from C as well. Token
come in various flavors so it is not to surprising that the standard functions
do not provide them.
If you want variable length strings then Pascal strings with their explicit
external length would seem to be the way to go. I can only guess that the
"problem" with Fortran strings is that it is easy to forget to "TRIM" when
concatenating if you are thinking C. Fortran is more on a par with BASIC
in terms of its complete collection of operators for strings as a native
datatype.
| |
| Richard Maine 2007-03-10, 7:08 pm |
| (I won't respond to the OP. He is very close to joining the exclusive -
in two senses - list of people in my tiny killfile. But I will respond
to this).
Sebastian Hanigk <hanigk@in.tum.de> wrote:
> Object orientation shouldn't have gotten into the standard. It has its
> uses, yes, but so many people advocate it as the silver bullet that
> solves every software problem, which is clearly false.
As one of the people who helped push for some of the OO stuff in f2003,
I'll note that I very specifically do *NOT* advocate it as a silver
bullet. Quite to the contrary, part of the OO approach in f2003 was to
add to Fortran those OO features that fit into Fortran and supplemented
it well, at least in my opinion.
There were OO advocates that wanted to, as I viewed it, rip the language
apart and redo it along OO lines. That approach got essentially zero
support in the committee because I don't think there was a single person
on the committee who thought that OO was a silver bullet that everythig
should be wrapped around (a horrible mix of metaphors, I realize).
F2003 uses very much an approach of fitting some OO concepts into their
place in Fortran rather than redoing Fortran to fit into OO.
I have related before the tale of how I "saw the light" and realized
that OO could have a place in Fortran, and specifically in my Fortran
codes. I had read material and seen presentations about OO before, but
it just didn't seem to "click" with me. I couldn't see why I would care
about any of that stuff, which seemed rather academic and disconnected
from things that I did with Fortran. But then John Cuthbertson gave a
presentation at one of the committee meetings. His presentation put it
in Fortran terms and showed how some of the ideas fit. Suddenly, I
realized that this did make sense to me, and indeed that I had been
doing things along that general line for... well... a long time. I just
hadn't known the fancy terms for what I was doing. I also hadn't
realized that the language could actually help instead of get in the way
- as it so often had; I had formerly done many "cheats/tricks" to get
around places where the language seemed to be "fighting" me.
Also, as is so often the case, once I got a larger and more abstract
view of the principles I was using, I saw ways to use them better....
not for everything - definitely not, but they sure help in some parts of
my Fortran applications.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Gary Scott 2007-03-10, 7:08 pm |
| Gordon Sande wrote:
> On 2007-03-10 14:13:07 -0400, analyst41@hotmail.com said:
>
>
>
> I am always a bit by such comments. C strings are not all that
> good.
> I have the collection of C string functions available in my private
> "library".
> Once the "I0" formatting arrived to match "A" formatting my use of the C
> strings went down a lot. The only remaining thing that I use much is my
> token extraction functions that happen to be missing from C as well. Token
> come in various flavors so it is not to surprising that the standard
> functions
> do not provide them.
It isn't so much tokenization that I would like, as it is a standard set
of string parsing facilities. But I'd base mine on REXX parsing.
>
> If you want variable length strings then Pascal strings with their explicit
> external length would seem to be the way to go. I can only guess that the
> "problem" with Fortran strings is that it is easy to forget to "TRIM" when
> concatenating if you are thinking C. Fortran is more on a par with BASIC
> in terms of its complete collection of operators for strings as a native
> datatype.
>
>
>
>
--
Gary Scott
mailto:garylscott@sbcglobal dot 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
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Greg Lindahl 2007-03-10, 7:08 pm |
| In article <1hurbby.9b9hju1gfgvtoN%nospam@see.signature>,
Richard Maine <nospam@see.signature> wrote:
>(I won't respond to the OP. He is very close to joining the exclusive -
>in two senses - list of people in my tiny killfile.
But he may already be in your killfile -- is he the same person as
AbdulQat@hotmail.com or mrhrundivbakshi@hotmail.com ?
-- greg
| |
| Richard Maine 2007-03-10, 7:08 pm |
| Greg Lindahl <lindahl@pbm.com> wrote:
> In article <1hurbby.9b9hju1gfgvtoN%nospam@see.signature>,
> Richard Maine <nospam@see.signature> wrote:
>
>
> But he may already be in your killfile -- is he the same person as
> AbdulQat@hotmail.com or mrhrundivbakshi@hotmail.com ?
Could be. They do sound a lot alike. I never bothered to look deeper;
they aren't worth it.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Rich Townsend 2007-03-11, 7:09 pm |
| Greg Lindahl wrote:
> In article <1hurbby.9b9hju1gfgvtoN%nospam@see.signature>,
> Richard Maine <nospam@see.signature> wrote:
>
>
> But he may already be in your killfile -- is he the same person as
> AbdulQat@hotmail.com or mrhrundivbakshi@hotmail.com ?
>
> -- greg
Possibly not. He does manage to get through a post without accusing others of
paedophilia or homosexuality, which the cited email addresses don't. Less mad, I
think -- but also, it seems, not really as clever. The only thing the two really
have in common is a hatred, and an utter misunderstanding of, modern Fortran
language features.
cheers,
Rich
| |
| Lane Straatman 2007-03-11, 7:09 pm |
|
"Richard Maine" <nospam@see.signature> wrote in message
news:1hurh0n.i3zzas11d1wxjN%nospam@see.signature...
> Greg Lindahl <lindahl@pbm.com> wrote:
>
>
> Could be. They do sound a lot alike. I never bothered to look deeper;
> they aren't worth it.
I finally figured out what troll means. When you look at what he posts,
it's just pasted together in a way that destroys context.
--
LS
| |
| Richard Maine 2007-03-11, 7:09 pm |
| Sebastian Hanigk <hanigk@in.tum.de> wrote:
> nospam@see.signature (Richard Maine) writes:
>
>
> Thank god for that! It's nice to get first-hand information on the
> causes for decisions like that.
>
> To sidetrack a bit: when you state that the committee was in unison
> against the more - ahem - "progressive" proposals, where have those come
> from? Was it more like (hypothetically) myself mailing the committee for
> inclusion of Co-Array or has it came from people with more impact?
There were some emails. And one or two people even showed up at
committee meetings.
>
> Would it be the 1996 paper on the ACM SIGPLAN Fortran Forum ("Fortran
> object oriented programming examples")? Have it downloading at the
> moment and will read it afterwards.
I don't know for sure. But the timeframe is about right. If Cuthbertson
is the author, then that is probably it, though I wouldn't swear that
the paper version would necessarily have quite the same impact as the
oral presentation, with audience questions and feedback.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Sebastian Hanigk 2007-03-11, 7:09 pm |
| nospam@see.signature (Richard Maine) writes:
>
> I don't know for sure. But the timeframe is about right. If Cuthbertson
> is the author, then that is probably it, though I wouldn't swear that
> the paper version would necessarily have quite the same impact as the
> oral presentation, with audience questions and feedback.
The paper is just two pages and contains just a few examples what to do
in an OO way (well, the title says "examples" ...). On the other hand, a
search for "Fortran" and "object oriented programming" leaves me with a
plethora of reading material :-)
Sebastian
| |
| Charles Russell 2007-03-11, 7:09 pm |
| Lane Straatman wrote:
>
> I finally figured out what troll means. When you look at what he posts,
> it's just pasted together in a way that destroys context.
When I looked up "troll" on wikipedia a year or more ago, I found no
definition that matched this context. I posted a comment asking what
the definition was in this case, and whether it derived from the kind of
troll that lurks under a bridge or from the fishing technique. Last
time I looked, my question was still unanswered.
| |
| Dan Nagle 2007-03-11, 7:09 pm |
| Hello,
Charles Russell wrote:
> Lane Straatman wrote:
>
>
> When I looked up "troll" on wikipedia a year or more ago, I found no
> definition that matched this context. I posted a comment asking what
> the definition was in this case, and whether it derived from the kind of
> troll that lurks under a bridge or from the fishing technique. Last
> time I looked, my question was still unanswered.
Do you really expect an informal, recently-invented term, such as troll,
to have a precise lexicographic definition?
Is asking for one itself a troll?
Aren't self-referential questions suspect? ;-)
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Richard Maine 2007-03-11, 7:09 pm |
| Sebastian Hanigk <hanigk@in.tum.de> wrote:
> nospam@see.signature (Richard Maine) writes:
>
>
> The paper is just two pages and contains just a few examples what to do
> in an OO way (well, the title says "examples" ...).
Ah. Likely then just the examples from his talk. Perhaps that's what he
had written and the rest was all oral. The talk was a lot more than just
examples, although there were supporting examples.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Michael Metcalf 2007-03-12, 8:11 am |
|
"Dan Nagle" <dannagle@verizon.net> wrote in message
news:R0VIh.214$y56.191@trnddc07...
>
> Do you really expect an informal, recently-invented term, such as troll,
> to have a precise lexicographic definition?
>
> Is asking for one itself a troll?
>
My 1993 edition of the Shorter OED says: "(slang) cruise in search of a
sexual partner etc.".
Pretty close.
Regards,
Mike Metcalf
| |
| Jan Vorbrüggen 2007-03-12, 8:11 am |
| > Fortran will live if and only if
>
> (0) It supports legacy code.
This is certainly an important item on the priority list, but its relative
importance is down on what it once was. In my personal opinion, there is
nowadays to much material in the standard, with too many interactions among
useful new features, because of this legacy support. A not-quite-so-dogmatic F
would be the right thing to have. Being a bit more radical, with F03 do away
with the F77-type fixed-length strings and only use variable-length strings.
> (1) It remains a small,fast language.
Fast has mmore than one aspect, but fast execution is still relevant.
Small is in the eye of the beholder. For all its warts, Fortran is still quite
regular and principled, compared to, for instance, C, and small compared to,
for instance, C++. Do away with some of the legacy support mentioned above,
and even F03 can still be considered to be small.
> (2) The language allows for relatively simple compilers to be written.
Entirely irrelevant. Most of the code is in the optimization part anyway, and
that is to a large degree indepedent of the fron-end language - except for
such things as supporting arrays as first-calls citizens.
> (3) It has to be able to do dirty things
>
> a) either as part of the language (without violating 1 and 2 above)
>
> b) or as extensions supported by most vendors
>
> c) or mixed language (C primarily) programming or by calling object
> code complied from other languages.
>
> Dirty things would include pipes,system calls, command line arguments,
> accessing databases, Byte stream I/O (to support newer filetypes) to
> name a few.
Always been possible, did that almost thirty years ago. Not part of the
standardized language anyway. A far smaller fraction of this is actually
doable in standard C than people think.
> (4) This is a tough one - allow for parallel processing. It would be
> best if opportunities for parallelization are recognized by the
> compiler - but if explicit parallelization cannot be introduced into
> Fortran without destroying the look and feel of the language then
> perhaps the explicitly parallel operations should be done with C
> routines callable from Fortran.
Entirely orthogonal to the language for many approaches to parallelism.
Data-parallel is useful in a sufficient number of cases, and sufficiently well
supported, that it is supposed to become part of F08.
> The philosophy of the official Fortran enhancement path seems to have
> been to add a gazillion features considered "modern" as (0) was
> maintained - and the result is a failure - just about EVERY
> "modern" feature in Fortran is a "Yes,but".
>
> Do you have pointers ? yes, but....
With the but saying "...but this time we got it correct (compared to C)."
> Do you have OOP ? yes, but ....
With the but saying "but this time we got a more useful and much safer version
than C++."
> Do you have dynamic memory ? yes, but...
With the but saying "but this time we got it correct compared to both C and C++."
> The elementary C notion of variable length string seems to give
> Fortran a stroke.
C does not have variable lengths strings. C has an abomination instead that
should be banned from being used due to its warts and proneness to serious
errors. And the support routines are even worse.
Jan
| |
| Charles Russell 2007-03-12, 7:06 pm |
| Michael Metcalf wrote:
>
> My 1993 edition of the Shorter OED says: "(slang) cruise in search of a
> sexual partner etc.".
British slang! Alas!
I have a copy of the Oxford-Duden German-English Dictionary that is
useless for slang, since it simply translates German slang into British
slang that is equally unintelligible to an American.
| |
| Michael Metcalf 2007-03-12, 7:06 pm |
|
"Charles Russell" <NOSPAM@bellsouth.net> wrote in message
news:dCeJh.7376$m7.1847@bignews5.bellsouth.net...
> Michael Metcalf wrote:
>
>
> British slang! Alas!
>
Well, let's try (same source): "N. Amer. trail a baited line behind a boat.
Also fig., move in an alluring manner;".
Regards,
Mike Metcalf
| |
| Gary Scott 2007-03-12, 7:06 pm |
| Charles Russell wrote:
> Michael Metcalf wrote:
>
>
>
> British slang! Alas!
>
> I have a copy of the Oxford-Duden German-English Dictionary that is
> useless for slang, since it simply translates German slang into British
> slang that is equally unintelligible to an American.
I don't think this usage of troll is British per se. I've heard it used
quite often.
--
Gary Scott
mailto:garylscott@sbcglobal dot 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
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Steven G. Kargl 2007-03-12, 7:06 pm |
| In article <mReJh.1261$2%3.134@trndny06>,
"Michael Metcalf" <michaelmetcalf@compuserve.com> writes:
>
> "Charles Russell" <NOSPAM@bellsouth.net> wrote in message
> news:dCeJh.7376$m7.1847@bignews5.bellsouth.net...
> Well, let's try (same source): "N. Amer. trail a baited line behind a boat.
> Also fig., move in an alluring manner;".
>
While "trail" works in the above sentence. In N. Amer., and the USA in
particular, a fisherman normally "trawls" the line behind the boat.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Charles Russell 2007-03-12, 7:06 pm |
| Steven G. Kargl wrote:
> While "trail" works in the above sentence. In N. Amer., and the USA in
> particular, a fisherman normally "trawls" the line behind the boat.
You trawl in the ocean with a net. You troll in the bayou with a line.
| |
| Charles Russell 2007-03-12, 7:06 pm |
| Gary Scott wrote:
> Charles Russell wrote:
>
>
> I don't think this usage of troll is British per se. I've heard it used
> quite often.
Generational or regional difference? Some of what my kids say is also
unintelligible.
| |
| Steven G. Kargl 2007-03-12, 7:06 pm |
| In article <SYhJh.4370$nV1.4105@bignews6.bellsouth.net>,
Charles Russell <NOSPAM@bellsouth.net> writes:
> Steven G. Kargl wrote:
>
>
> You trawl in the ocean with a net. You troll in the bayou with a line.
>
Apparently, you've never heard of a "trawl line". Google is your
friend.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Janne Blomqvist 2007-03-12, 7:06 pm |
| In article <45f5a0d8$1@news.meer.net>, Greg Lindahl wrote:
> The language-independent part of our compiler is < 1 million lines.
>
> The Fortran front-end is 600,000 lines, and almost all of it is
> non-legacy stuff.
Uh, what? For comparison, the gfortran frontend is about 70000 lines
(with sloccount, about twice with "wc -l"), and the language
independent part of the GCC frontend is about 0.5 million (again, with
sloccount).
Is the thing written in COBOL, or how did you manage to bloat it like
that? ;-)
Certainly you have some features gfortran doesn't have (and vice
versa, I guess), and gfortran still has some catching up to do wrt
performance, but a factor of 10 in sloc is hard to swallow. Especially
given your previous comments that Pathscale has a pretty dumb
scalarizer, with the smarts residing in the scalar optimizers
(presumably in the language-independent part).
--
Janne Blomqvist
| |
| analyst41@hotmail.com 2007-03-12, 7:06 pm |
| On Mar 12, 7:44 am, "Michael Metcalf" <michaelmetc...@compuserve.com>
wrote:
> "Dan Nagle" <danna...@verizon.net> wrote in message
>
> news:R0VIh.214$y56.191@trnddc07...
>
>
>
> My 1993 edition of the Shorter OED says: "(slang) cruise in search of a
> sexual partner etc.".
>
> Pretty close.
>
> Regards,
>
> Mike Metcalf
The wikipedia entry reads
In Internet terminology, a troll is a person who enters an established
community such as an online discussion forum and intentionally tries
to cause disruption, often in the form of posting messages that are
inflammatory, insulting, incorrect, inaccurate, absurd, or off-topic,
with the intent of provoking a reaction from others.
end quote.
Nothing about sex partners, please note.
But don't worry,
"That which you desire will come to pass, for as you s so shall you
find"
| |
| Rich Townsend 2007-03-12, 10:06 pm |
| analyst41@hotmail.com wrote:
> On Mar 12, 7:44 am, "Michael Metcalf" <michaelmetc...@compuserve.com>
> wrote:
>
> The wikipedia entry reads
>
> In Internet terminology, a troll is a person who enters an established
> community such as an online discussion forum and intentionally tries
> to cause disruption, often in the form of posting messages that are
> inflammatory, insulting, incorrect, inaccurate, absurd, or off-topic,
> with the intent of provoking a reaction from others.
>
> end quote.
>
> Nothing about sex partners, please note.
>
> But don't worry,
>
> "That which you desire will come to pass, for as you s so shall you
> find"
>
Quoiting the bible now? Are you sure you're not Coulter?
| |
| Greg Lindahl 2007-03-12, 10:06 pm |
| In article <slrnevbmbh.6d4.foo@vipunen.hut.fi>,
Janne Blomqvist <foo@bar.invalid> wrote:
>Is the thing written in COBOL, or how did you manage to bloat it like
>that? ;-)
It was written by CraySoft, not us.
-- greg
| |
| Greg Lindahl 2007-03-12, 10:06 pm |
| In article <slrnevbmbh.6d4.foo@vipunen.hut.fi>,
Janne Blomqvist <foo@bar.invalid> wrote:
> Especially
>given your previous comments that Pathscale has a pretty dumb
>scalarizer, with the smarts residing in the scalar optimizers
>(presumably in the language-independent part).
I was going to send you email about this, but you haven't bothered to
provide your email address, so I guess you don't want to know.
It's pretty odd to call our vectorizing compiler a "scalar optimizer".
Or to call the step of transforming array notation to F77 loops
"scalarization". We have something called the global scalar optimizer,
and it works on ... scalars. It's separate from the vectorizer and the
SIMD vectorizer.
-- g
| |
| Charles Russell 2007-03-13, 4:15 am |
| Steven G. Kargl wrote:
> In article <SYhJh.4370$nV1.4105@bignews6.bellsouth.net>,
> Charles Russell <NOSPAM@bellsouth.net> writes:
>
>
>
> Apparently, you've never heard of a "trawl line". Google is your
> friend.
>
No, I hadn't. Seems to be what we called a "trotline" when I was
trolling in the bayou.
| |
| Jan Vorbrüggen 2007-03-13, 4:15 am |
| > The Fortran front-end is 600,000 lines, and almost all of it is
> non-legacy stuff.
>
> So: no, it's not the legacy stuff that makes the front-end a bloated
> p-o-s.
Live and learn. Nonetheless, I'm surprised. Support fixed-form source, with
all its oddities and irregularities, doesn't significantly contribute to the
parser and lexer, especially compared to the more regular and easier-to-parse
free-form source? Supporting EQUIVALENCE, non-integer do-loop variables,
shared CONTINUE statements, three-way IFs, hollerith constants, ....?
ALLOCTABLES, especially combined with INTENT, that I can see as being a
significant thing to support properly.
Jan
| |
| James Giles 2007-03-13, 4:15 am |
| Jan Vorbrüggen wrote:
>
> Live and learn. Nonetheless, I'm surprised. Support fixed-form
> source, with all its oddities and irregularities, doesn't
> significantly contribute to the parser and lexer, especially compared
> to the more regular and easier-to-parse free-form source? [...]
All that was solved in the 50's on machines that we would not
now consider big enough to run the firmware of our refirgerators.
Sure, there's more features since then, but all deliberately designed
to work with the same sort of parsing methods. Some of that
changed a little when names longer than 6 characters were allowed,
but modifications to Sale's algorith could still easily handle it.
> [...] Supporting EQUIVALENCE, non-integer do-loop variables, shared
> CONTINUE statements, three-way IFs, hollerith constants, ....?
Again, all fairly simple. The rules are anyway. Some are error
prone for users. But compiling them is old hat. Three-way ifs,
for example, are just conditional branches. Simple.
> ALLOCTABLES, especially combined with INTENT, that I can see as
> being a significant thing to support properly.
Pointers, especially combined with array slicing is even harder. Whole
array operations themselves are no picnic. Derived types (especially
now, with ALLOCATABLE components) are not trivial either. Given
that modern users expect all these things very well optimized as well
as correct is a real chore.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Charles Russell 2007-03-13, 7:10 pm |
| James Giles wrote:
> Jan Vorbrüggen wrote:
>
>
>
> All that was solved in the 50's on machines that we would not
> now consider big enough to run the firmware of our refirgerators.
My Lahey f77l compiler is 171 kB, the run-time library 135 kB. And that
is one of the best compilers I've ever used. I keep it around for
debugging because of the great diagnostics. Remember that this and other
f77 compilers used to run from a 360 kB floppy.
| |
| Greg Lindahl 2007-03-13, 7:10 pm |
| In article <55n3t4F264dnsU1@mid.individual.net>,
Jan Vorbrüggen <jvorbrueggen@not-mediasec.de> wrote:
> Support fixed-form source, with
> all its oddities and irregularities, doesn't significantly contribute to the
> parser and lexer, especially compared to the more regular and easier-to-parse
> free-form source?
No. Intrinsics and all their named parameters are a much larger
contributor.
> Supporting EQUIVALENCE, non-integer do-loop variables,
> shared CONTINUE statements, three-way IFs, hollerith constants, ....?
All easy, except non-integer do loops, which we don't support.
EQUIVALENCE is similar to a union, for example. 3-way ifs are simply
expanded.
>ALLOCTABLES, especially combined with INTENT, that I can see as being a
>significant thing to support properly.
You're still cold.
One huge item is expanding all the array intrinsics in-line so they
can be properly optimized.
-- g
| |
| analyst41@hotmail.com 2007-03-14, 10:08 pm |
| On Mar 12, 7:45 am, Jan Vorbr=FCggen <jvorbrueg...@not-mediasec.de>
wrote:
>
>
> This is certainly an important item on the priority list, but its relative
> importance is down on what it once was. In my personal opinion, there is
> nowadays to much material in the standard, with too many interactions amo=
ng
> useful new features, because of this legacy support. A not-quite-so-dogma=
tic F
> would be the right thing to have. Being a bit more radical, with F03 do a=
way
> with the F77-type fixed-length strings and only use variable-length strin=
gs.
>
>
> Fast has mmore than one aspect, but fast execution is still relevant.
>
> Small is in the eye of the beholder. For all its warts, Fortran is still =
quite
> regular and principled, compared to, for instance, C, and small compared =
to,
> for instance, C++. Do away with some of the legacy support mentioned abov=
e,
> and even F03 can still be considered to be small.
>
>
> Entirely irrelevant. Most of the code is in the optimization part anyway,=
and
> that is to a large degree indepedent of the fron-end language - except f=
or
> such things as supporting arrays as first-calls citizens.
>
>
>
>
>
>
> Always been possible, did that almost thirty years ago. Not part of the
> standardized language anyway. A far smaller fraction of this is actually
> doable in standard C than people think.
>
>
> Entirely orthogonal to the language for many approaches to parallelism.
> Data-parallel is useful in a sufficient number of cases, and sufficiently=
well
> supported, that it is supposed to become part of F08.
>
>
>
> With the but saying "...but this time we got it correct (compared to C)."
>
>
> With the but saying "but this time we got a more useful and much safer ve=
rsion
> than C++."
>
>
> With the but saying "but this time we got it correct compared to both C a=
nd C++."
>
>
> C does not have variable lengths strings. C has an abomination instead th=
at
> should be banned from being used due to its warts and proneness to serious
> errors. And the support routines are even worse.
>
> Jan
http://www.adass.org/adass/proceedings/adass99/P2-38/
How many more conversions like this can Fortran survive ?
True this article explicitly says that lack of f90 compilers was one
reason for the migration - but for whatever reason, the heartland of
Fortran apps was decimated during the decade of 1980.
We may argue till we are blue in the face about the superiority of
modern fortrans, buy until we start reading stories of reverse
migrations (C,C++,Java) to fortran the picture is dismal.
start quote
2=2E Why Convert to C?
There were three major reasons, listed in decreasing importance.
2=2E1. Job Market for Graduate Students
Most entering graduate students bring in some knowledge of C or Visual
Basic. Most do not end up on a track leading to a tenured position at
a research university, and many go into computer-related fields. The
job market for C programmers is vastly richer than for Fortran
experts. This is true both at the local level here in Lexington and in
national astronomical centers. Students would be far more competitive
in the job market if they had several years of experience developing
large-scale C programs. Graduate students rely on the faculty to make
choices that are in their long-term interests. If we can get our work
done in a C environment, we owe it to our students to do so.
2=2E2. Open Source/GNU Friendly
Fortran 95 is a modern language. Unfortunately, the Open Source
movement does not support Fortran beyond the f2c conversion utility
and the g77 compiler. Modern compilers are commercially available but
are expensive, making modern Fortran more like IDL than a true ANSI
language. As a result, portable Fortran code cannot go much beyond
FORTRAN 77. At the same time, the C++ standard has now existed for
well over a year and the gcc compiler and its standard template
library are moving ever closer to full compliance. gcc has long been
fully compliant with 1989 ANSI C.
2=2E3. Leverage Other Technologies
Most system shells and higher-level languages carry intellectual
heritage from C. As universities change to better take advantage of
the web, languages like Java, XGL, and SQL will become increasingly
important. A C environment makes this both easy and natural
end quote.
I think that becoming larger or more capable or cleaner or more
regular are losing propositions for Fortran when it comes to the
fundamental question of survival.
In real life,with respect to C/C++/Java, modern fortrans are (rightly
or wrongly) considered to offer no real advantages by the overwhelming
mass of managers (especially in the private sector) who make language/
platform decisions. Add on top of it the colossal commercial success
of these languages, then "total cost of ownership" arguments ensure
that new projects in Fortran are non-starters.
After all, I would argue that as of 2007, Fortran has less than 1 pct
share of number-crunching type computing in business.
So, "back to the future" is the best chance of survival - after all
unbelievably powerful code was written with Fortran 77 (I remember a
"60 minutes" documentary about Soviet missiles, and IIRC they showed
fortran code scrolling on a CRT in the control room). Somehow fortran
was practically extinguished in the 1980s by the move to "modernity"
and that near-death experience is not reversible. Whatever the new
fortrans have to offer over and above f77 is too late.
ONLY what remains of the f77 legacy can now be saved, and that has to
be done with the "small superset" strategy.
The only future for f90 etc. is the museum.
| |
| Rich Townsend 2007-03-14, 10:08 pm |
| analyst41@hotmail.com wrote:
> On Mar 12, 7:45 am, Jan Vorbrüggen <jvorbrueg...@not-mediasec.de>
> wrote:
>
>
>
> http://www.adass.org/adass/proceedings/adass99/P2-38/
>
> How many more conversions like this can Fortran survive ?
>
> True this article explicitly says that lack of f90 compilers was one
> reason for the migration - but for whatever reason, the heartland of
> Fortran apps was decimated during the decade of 1980.
The link you gave discusses the conversion of the CLOUDY astrophysics code from
Fortran to C. Contrary to the impression that your post might give, Fortran use
is alive and well in the astrophysics community, not just in terms of legacy
code, but also for new codes. Two large projects that spring immediately to mind
are the ZEUS and FLASH magnetohydrodynamical codes, used for instance to perform
supernova simulations. Both of these are significant and ongoing F90/95
projects; FLASH in particular represents the investment of a significant amount
of effort, probably over a man-century, and is funded by the Department of Energy.
These are just two examples, but I could provide many others. To claim that
Fortran use has been decimated in this particular community would be completely
specious. Therefore, I suggest you chose a different strawman.
cheers,
Rich
| |
| Gary Scott 2007-03-14, 10:08 pm |
| Rich Townsend wrote:
> analyst41@hotmail.com wrote:
>
>
>
> The link you gave discusses the conversion of the CLOUDY astrophysics
> code from Fortran to C. Contrary to the impression that your post might
> give, Fortran use is alive and well in the astrophysics community, not
> just in terms of legacy code, but also for new codes. Two large projects
> that spring immediately to mind are the ZEUS and FLASH
> magnetohydrodynamical codes, used for instance to perform supernova
> simulations. Both of these are significant and ongoing F90/95 projects;
> FLASH in particular represents the investment of a significant amount of
> effort, probably over a man-century, and is funded by the Department of
> Energy.
>
> These are just two examples, but I could provide many others. To claim
> that Fortran use has been decimated in this particular community would
> be completely specious. Therefore, I suggest you chose a different
> strawman.
>
Agree, but still would like to see Fortran usage expanded in other
domains. With the right adjustments in feature set and the right
marketing, it can happen.
> cheers,
>
> Rich
--
Gary Scott
mailto:garylscott@sbcglobal dot 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
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Greg Lindahl 2007-03-15, 7:12 pm |
| In article <7e2Kh.7467$M65.647@newssvr21.news.prodigy.net>,
Gary Scott <garylscott@sbcglobal.net> wrote:
>Agree, but still would like to see Fortran usage expanded in other
>domains. With the right adjustments in feature set and the right
>marketing, it can happen.
Genetics people used to only use C/C++, "Fortran? No, we don't use
that old thing!" Then they started moving beyond sequence matching
into molecular dynamics, quantum chemistry, etc. And suddently they
were using Fortran, because there's no point taking Fortran code that
already works and rewriting it into C/C++.
There are some new codes in C/C++ so it's not a clean sweep. But it
was still fun to watch.
-- greg
| |
| analyst41@hotmail.com 2007-03-15, 7:12 pm |
| On Mar 14, 10:23 pm, Rich Townsend <r...@barVOIDtol.udel.edu> wrote:
> analys...@hotmail.com wrote:
tive[color=darkred]
is[color=darkred]
among[color=darkred]
gmatic F[color=darkred]
o away[color=darkred]
rings.[color=darkred]
>
>
ll quite[color=darkred]
ed to,[color=darkred]
bove,[color=darkred]
>
ay, and[color=darkred]
t for[color=darkred]
>
ly[color=darkred]
>
tly well[color=darkred]
>
)=2E"[color=darkred]
>
version[color=darkred]
>
C and C++."[color=darkred]
>
that[color=darkred]
ious[color=darkred]
>
>
>
>
>
> The link you gave discusses the conversion of the CLOUDY astrophysics cod=
e from
> Fortran to C. Contrary to the impression that your post might give, Fortr=
an use
> is alive and well in the astrophysics community, not just in terms of leg=
acy
> code, but also for new codes. Two large projects that spring immediately =
to mind
> are the ZEUS and FLASH magnetohydrodynamical codes, used for instance to =
perform
> supernova simulations. Both of these are significant and ongoing F90/95
> projects; FLASH in particular represents the investment of a significant =
amount
> of effort, probably over a man-century, and is funded by the Department o=
f Energy.
>
> These are just two examples, but I could provide many others. To claim th=
at
> Fortran use has been decimated in this particular community would be comp=
letely
> specious. Therefore, I suggest you chose a different strawman.
You are the straw-man setter-upper and not me.
I did not claim Fortran has been decimated in each and every niche. I
have said repeatedly that Government and other not-for-profit
organizatizations are the mainstay of Fortran today (there seem to
have been significant defections even in those areas. The example
that I cited was only an illustration along with reasons that the
Fortran community absolutely refuses to deal with).
I guess that Fortran has less than 1 per-cent marketshare for "number-
crunching" apps in business. If it cannot reclaim a foothold in the
world of commerce, it bodes very poorly for its survival.
It seems to have practically disappeared from Wall Street which
probably does more number-crunching than even the government, NASA,
Boeing etc. put together.
Commercial Statistical and Optimization software is another area where
Fortran seems to have vanishing market share. Data mining alone is
huge area of business that Fortran should have claimed as its domain
but that hasn't happened.
I am not that familiar with whats happening in the world of
engineering - Numerically Controlled machines, Nuclear reactor
control, aerodynamics modeling and simulation etc.- but I suspect the
situation is only slightly less bleak.
I would dearly love to hear of a Fortran app in a Fortune 1000 company
thats considered important and is not marked for a re-write in C/C++/
Java as soon as the incumbent codger retires or otherwise goes away.
And if you reply, at least try to be honest.
>
> cheers,
>
> Rich- Hide quoted text -
>
> - Show quoted text -
| |
| Sebastian Hanigk 2007-03-16, 4:31 am |
| analyst41@hotmail.com writes:
One thing before my reply: could everyone in this thread be so kind and
not quote everything in his reply?
> I guess that Fortran has less than 1 per-cent marketshare for "number-
> crunching" apps in business. If it cannot reclaim a foothold in the
> world of commerce, it bodes very poorly for its survival.
I find this number of yours very unrealistic. You have of course
some solid reference for it.
Concerning the "survival": great people like Dijkstra have scorned
Fortran (for valid reasons) and still after 50 years it is in active
development and use.
> I am not that familiar with whats happening in the world of
> engineering - Numerically Controlled machines, Nuclear reactor
> control, aerodynamics modeling and simulation etc.- but I suspect the
> situation is only slightly less bleak.
One of my employers is in the field of nuclear safety engineering and
the two codes most used are written in Fortran (ATHLET and MELCOR, if
that's of any use).
At the last workshop on fluid dynamics I was attending, about one third
of the participants had written their code in Fortran, the rest was C,
but the C crowd was very interested in Fortran, I surmise they had never
had contact with it during their university education; at my alma mater
(the TU München) there are only Java and C courses for mathematicians,
physicists and computer scientists.
> I would dearly love to hear of a Fortran app in a Fortune 1000 company
> thats considered important and is not marked for a re-write in C/C++/
> Java as soon as the incumbent codger retires or otherwise goes away.
I do not think that you are on the right track. From my point of view,
Fortran has other strengths than direct application programming. From
what I have seen, Fortran is mostly used either for in-house development
and scientific projects where the user has certain knowledge or as
library for more general purposes (my girlfriend works in the financial
sector on a risk analysis code where the front-end development is done
in C++ while the brunt of the work is done by a wrapped Fortran
library).
Sebastian
| |
|
| <analyst41@hotmail.com> wrote in message
news:1173922510.213778.267500@y66g2000hsf.googlegroups.com...
>True this article explicitly says that lack of f90 compilers was one
>reason for the migration
That material is somewhat dated.
Fortran 90 compilers have been available for 15 years,
and 95 compilers for a decade.
>2.2. Open Source/GNU Friendly
>Fortran 95 is a modern language. Unfortunately, the Open Source
>movement does not support Fortran beyond the f2c conversion utility
>and the g77 compiler.
For at least a decade, Fortran 90 and 95 compilers have been available
to compile F77 codes.
For the same period of time, various conversion aids and tools
have been readily available.
> Modern compilers are commercially available but
>are expensive,
How expensive is free?
> making modern Fortran more like IDL than a true ANSI
>language. As a result, portable Fortran code cannot go much beyond
>FORTRAN 77.
Fortran 90 and 95 compilers compile (standard) FORTRAN 77 codes.
In other words, current compilers compile (standard) FORTRAN 77.
| |
| analyst41@hotmail.com 2007-03-17, 7:10 pm |
| On Mar 16, 4:31 am, Sebastian Hanigk <han...@in.tum.de> wrote:
> analys...@hotmail.com writes:
>
> One thing before my reply: could everyone in this thread be so kind and
> not quote everything in his reply?
>
>
> I find this number of yours very unrealistic. You have of course
> some solid reference for it.
>
I have only anecdotal evidence (Les Hatton's book "safer C" that came
out IIRC in the early 1990s in which he stated that in most
organizations he visited, they were only maintaining their Fortran
codes and not enhancing them any more. He also had this line
(paraphrasing) "the Fortran 90 language spec induces a state of
catatonia in a compiler writer". Other evidence would include
Fortran's absence from areas of computing where it should be a natural
choice, Lahey deciding not to enhance its Windows product any more,
"quant" type jobs where the language required by the employer is C/C++
(the unkindest cut are the ads for porting from Fortran to C/C++ that
say "might need to brush up on fortran from old manuals").)
But the bottom line is that we have only anecdotal evidence of who
uses what flavor of fortran in what type of business/industry/govt
type organization for what kind of applications. We also have only
anecdotal evidence as to how many schools teach fortran (broken down
by engineering, comp sci, applied math etc.). The "Classical Fortran"
folks represent a viewpoint that has to be acknowledged.
There are around a thousand subscribers to this group according to
Google and surely they can be a good source of information about these
questions - but the fuddy-duddies would come out of the woodwork with
howls of furious protest EACH AND EVERY TIME anybody has dared to
raise the topic of assessing actual Fortran usage in the real world.
>From what I understand, it is none of their business (nor should it be
anybody else's) if the language is used at all, or that its compiler
vendors' proprietary information or whatever - the sand their head is
buried in firmly on this question has turned to concrete now.
> Concerning the "survival": great people like Dijkstra have scorned
> Fortran (for valid reasons) and still after 50 years it is in active
> development and use.
>
>
> One of my employers is in the field of nuclear safety engineering and
> the two codes most used are written in Fortran (ATHLET and MELCOR, if
> that's of any use).
>
Thats good to know. Fortran 77 or the newer fortrans ?
> At the last workshop on fluid dynamics I was attending, about one third
> of the participants had written their code in Fortran, the rest was C,
> but the C crowd was very interested in Fortran, I surmise they had never
> had contact with it during their university education; at my alma mater
> (the TU M=FCnchen) there are only Java and C courses for mathematicians,
> physicists and computer scientists.
Thats a big problem. If Eng schools no longer push fortran that bodes
poorly for the future.
>
>
> I do not think that you are on the right track. From my point of view,
> Fortran has other strengths than direct application programming. From
> what I have seen, Fortran is mostly used either for in-house development
> and scientific projects where the user has certain knowledge or as
> library for more general purposes (my girlfriend works in the financial
> sector on a risk analysis code where the front-end development is done
> in C++ while the brunt of the work is done by a wrapped Fortran
> library).
>
It would be good to know if the fortran library is frozen in place or
is still being enhanced. My understanding is that Fortran has all but
disappeared from Wall Street (at least the bigger outfits).
Actually what you have outlined could be a paradigm for Fortran usage
anywhere.
A typical application today would look like
(1) A data base with input data (with an Extract Transform Load
process in front of it).
(2) Things you want to do with the input data (with hooks from the GUI
to fine tune what you want to do).
(3) Output of the core processing
(4) Put the output back to the data base
(5) View the output through a GUI
A strategy that might work to promote Fortran usage (with the sales
pitch of "Total Cost of Ownership") would be to concentrate on (2) (3)
and (4). Only minimal amounts of "dirty" processing would be required
from the Fortran piece. The Fortran processing would add the core
value of the application through a "text files in" - "text files out"
process. All the rest can be by the typical drudges one finds in IT
departments.
> Sebastian
| |
| glen herrmannsfeldt 2007-03-17, 7:10 pm |
|
On Mar 16, 4:31 am, Sebastian Hanigk <han...@in.tum.de> wrote:
>analys...@hotmail.com writes:
>One thing before my reply: could everyone in this thread be so kind and
>not quote everything in his reply?
[color=darkred]
>I find this number of yours very unrealistic. You have of course
>some solid reference for it.
It might be that a large fraction is now in interpreted languages,
which are much more popular than they used to be.
R for statistical programming, Matlab and Mathematica for engineering,
and Excel for many others.
Computers are fast enough that what would be "number crunching" not so
long ago is often fast enough today in an interpreted language, and it
is faster to write.
-- glen
| |
| Brooks Moses 2007-03-17, 7:11 pm |
| NNTP-Posting-Host: dnab42a455.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1174174449 11016 171.66.164.85 (17 Mar 2007 23:34:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: < C6udnZanydhwoGHYnZ2dnUVZ_hqdnZ2d@comcast
.com>
Xref: number1.nntp.dca.giganews.com comp.lang.fortran:159752
glen herrmannsfeldt wrote:
> It might be that a large fraction is now in interpreted languages,
> which are much more popular than they used to be.
>
> R for statistical programming, Matlab and Mathematica for engineering,
> and Excel for many others.
>
> Computers are fast enough that what would be "number crunching" not so
> long ago is often fast enough today in an interpreted language, and it
> is faster to write.
Also, with Matlab, in many cases the time-consuming operations are
handled either by array operations or library calls, either of which
will mostly involve compiled code rather than interpreted, so there's
little speed penalty.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Sebastian Hanigk 2007-03-18, 7:07 pm |
| analyst41@hotmail.com writes:
>
> Thats good to know. Fortran 77 or the newer fortrans ?
MELCOR is FORTRAN77, ATHLET is obviously a product of the F77 time, but
continuous development has for example converted the COMMON blocks into
modules and one of my goals is a modular restructuring of the code
(thermohydraulics, neutron kinetics, controls, and so on) with a looser
coupling to faciliate parallelisation.
>
> Thats a big problem. If Eng schools no longer push fortran that bodes
> poorly for the future.
My personal opinion is that universities should not teach you knowledge,
they teach you how to get knowledge. Learning programming is not part of
a useful curriculum, it's a secondary skill; in most cases one will have
contact with real-world programming during some kind of internship.
No one has taught me Ada or even suggested its existence and yet I have
seen that in some places it is of good use, same goes for Fortran.
> It would be good to know if the fortran library is frozen in place or
> is still being enhanced. My understanding is that Fortran has all but
> disappeared from Wall Street (at least the bigger outfits).
As far as I know, it's bought third-party software like the NAG libraries.
> A typical application today would look like
>
> (1) A data base with input data (with an Extract Transform Load
> process in front of it).
>
> (2) Things you want to do with the input data (with hooks from the GUI
> to fine tune what you want to do).
>
> (3) Output of the core processing
>
> (4) Put the output back to the data base
>
> (5) View the output through a GUI
>
> A strategy that might work to promote Fortran usage (with the sales
> pitch of "Total Cost of Ownership") would be to concentrate on (2) (3)
> and (4). Only minimal amounts of "dirty" processing would be required
> from the Fortran piece. The Fortran processing would add the core
> value of the application through a "text files in" - "text files out"
> process. All the rest can be by the typical drudges one finds in IT
> departments.
For commercial software, that is perhaps a fitting description, but from
my point of view, most Fortran development happens in the field of
scientific programming where one is more interested in a fast
implementation of algorithms than in a more structured,
software-engineered application.
Sebastian
| |
| J. F. Cornwall 2007-03-18, 10:09 pm |
| analyst41@hotmail.com wrote:
(MUCH snippage)
>
> A typical application today would look like
>
> (1) A data base with input data (with an Extract Transform Load
> process in front of it).
Database (Ingres RDBMS on Solaris), with real-time and human (keyboard)
and assorted batch input processes for data files from many different
sources.
>
> (2) Things you want to do with the input data (with hooks from the GUI
> to fine tune what you want to do).
A few small bits of the "business process" have GUI programs. Most of
them are still character-based escape-sequence "graphics".
>
> (3) Output of the core processing
>
> (4) Put the output back to the data base
Many of the processing applications do indeed store results back to the
DB, yes.
> (5) View the output through a GUI
Sort of. Most of the real-time data and some of the remainder is sent
from our database machines (approximately one per US State) to a
centralized Web server where it is made available for public viewing and
downloads (http://waterdata.usgs.gov/nwis). Very few of *our* apps are GUI.
(snippage)
Jim
|
|
|
|
|