Surprise
kron...@yahoo.co.uk
Why are people still using it? I was a great fan of it until about
1997 when I moved to Matlab...then LabView. Why the need to resurect
Fortran? Yes, I know C is shite, has no complex numbers etc but that's
not an excuse.
K.
J. F. Cornwall
Resurrect? Riggggghhhhhttttttttt.......
Nice trolling attempt. Well, actually, it was a rather lame attempt.
On the off chance you were actually serious, we're still using Fortran
because (a) it does what we want it to do, (b) we have millions of lines
of code fully operational and we have no need or desire to change it to
some other language, and (c) it's far from dead, has never been anywhere
close to dead, and is not a candidate for being dead anytime in the near
(by geologic scales) future.
J.
Luka Djigas
I always liked the part about fortran 'being dead' ;-)
It was allegely 'dead' in the 70ties, then in the 80ties, then in the
...
But, better to stop here, and not to give the troll any more
encouragement.
Luka
Tim Prince
about Fortran.
Sjouke Burry
glen herrmannsfeldt
> Gosh, this was a big surprise. I though Fortran was dead as a Dodo!
> Why are people still using it? I was a great fan of it until about
> 1997 when I moved to Matlab...then LabView. Why the need to resurect
> Fortran?
Interpreted languages like Matlab have many uses, but in many
cases they aren't fast enough. Labview has completely different
uses.
> Yes, I know C is shite, has no complex numbers etc but that's
> not an excuse.
No it isn't. As of C99, C now has complex numbers.
-- glen
Gary Scott
Well, it's still shite, but for other reasons.
>
> -- glen
>
--
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
Thomas Koenig
> I know C is shite, has no complex numbers
Actually, C has complex numbers since the C99 standard.
kron...@yahoo.co.uk
Not at all. I moved from Fortran to C and it was crap. No complex
numbers. This was around 1987 of course. Having to write my own
structures of complex numbers was just daft whenyou had them built in.
I am not a troll and have used Fortran for around 20 years ...in fact
more like 25 years. Is it now OO?
K.
Steven G. Kargl
kron...@yahoo.co.uk writes:
> Is it now OO?
Yes, for some measure of OO.
See http://en.wikipedia.org/wiki/Fortran
to re-educate yourself.
glen herrmannsfeldt
(snip)
> Not at all. I moved from Fortran to C and it was crap. No complex
> numbers. This was around 1987 of course. Having to write my own
> structures of complex numbers was just daft whenyou had them built in.
> I am not a troll and have used Fortran for around 20 years ...in fact
> more like 25 years. Is it now OO?
They were added to the C standard in 1999. 1987 was even
before ANSI C in 1989.
It might be that compilers implementing full C99 are arriving
even slower than Fortran 2003 compilers.
Even so, much Fortran work with complex numbers is not done
using complex variables. It is usual to write FFT routines
using real variables. It might be that the dummy array
for assumed shape has to be complex, but the rest of the
calculation is often done using separate variables for the
real and imaginary parts. For assumed size, it is usual
to use a REAL dummy array.
-- glen
Richard Maine
> For assumed size, it is usual
> to use a REAL dummy array.
[with a complex actual argument - at least that's what I assume this is
referring to]
Note that this hack is and has always been nonstandard. Yes, it will
usually work, and yes I know it has often been done. Those are different
things. In fact, it was often enough done that I recall once thinking
that it must be valid as a special case exception to the type agreement
rules for arguments. But unless I am blind, there has never been such a
special case in the standard. If it's there, I'd like to know. That's
not a request to explain all the systems on which it works and has been
used; I know about that. I am specifically talking about the Fortran
standard(s) and only the standard(s) (and not DF's definition of
"standard".)
I'm slightly reluctant to post to this thread at all. I certainly won't
respond to the OP (specifically, I sure won't respond if he in turn
replies to this). In spite of his claims not to be a troll, if it walks
like a duck and quacks like a duck... Maybe he even honestly thinks he
isn't trolling; in the end, that doesn't matter. That would just
indicate that he doesn't know what counts as trolling.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
glen herrmannsfeldt
(I wrote)
>>For assumed size, it is usual to use a REAL dummy array.
> [with a complex actual argument - at least that's what I assume this is
> referring to]
> Note that this hack is and has always been nonstandard. Yes, it will
> usually work, and yes I know it has often been done. Those are different
> things. In fact, it was often enough done that I recall once thinking
> that it must be valid as a special case exception to the type agreement
> rules for arguments. But unless I am blind, there has never been such a
> special case in the standard.
I don't think I ever found it, either. I do believe that the
standard requires the real and imaginary parts to be stored
sequentially, real part first. (I haven't looked for it recently.)
The main case where I might expect it not to work is when doing
bounds checking. In the case of a dummy dimensioned (1) bounds
checking usually fails, anyway.
Otherwise, how do you separately assign to the real or imaginary
parts of a complex array element?
In PL/I you can do:
REAL(X(I))=REAL(X(J));
in Fortran, it would seem to be:
X(I)=CMPLX(REAL(X(J),AIMAG(X(I),KIND(X))
Maybe compilers can figure that one out.
-- glen
Gib Bogle
What a surprisingly foolish post!
James Giles
...
> In PL/I you can do:
>
> REAL(X(I))=REAL(X(J));
>
> in Fortran, it would seem to be:
>
> X(I)=CMPLX(REAL(X(J),AIMAG(X(I),KIND(X))
As of F2008 you can write:
X(I)%RE = X(J)%RE
(The corresponding component for the imaginary part is
%IM.)
I like that a *lot* better than PL/I's function-like syntax.
I'm hoping this will be a feature implemented sooner than
even parts of F2003.
--
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
"Simplicity is prerequisite for reliability" -- E. W. Dijkstra
Richard Maine
> glen herrmannsfeldt wrote:
> >
> > X(I)=CMPLX(REAL(X(J),AIMAG(X(I),KIND(X))
>
> As of F2008 you can write:
>
> X(I)%RE = X(J)%RE
>
> (The corresponding component for the imaginary part is
> %IM.)
>
> I like that a *lot* better than PL/I's function-like syntax.
> I'm hoping this will be a feature implemented sooner than
> even parts of F2003.
I like this feature also. Among other things, it is also valid if, for
example, the imaginary part is undefined at the time.
And I haven't checked to be sure, but I think that with this feature it
will be perfectly legit to do such things as use x%re as an actual
argument for a dummy real. I can't think of any reason why it wouldn't
be ok. That doesn't work for the existing Fortran real and aimag
intrinsics if the dummy argument mught be modified (and it has a chance
of causing a temporary copy even in cases where the dummy argument is
not modified).
James Giles
...
> And I haven't checked to be sure, but I think that with this feature
> it will be perfectly legit to do such things as use x%re as an actual
An actual argument can be a variable. A variable can be a
designator. And a designator can be a complex-part-designator.
So yes, a complex-part-designator can be used as an actual
argument.
kron...@yahoo.co.uk
Why? Fortran was a great language for maths there is no doubt...but it
has had its day now surely.
Even C++ is being replaced by many industries with C#. Pascal is dead
too and Modula2. I remember them all.
None of them was as good as Fortran but I wouldn't dream of using it
now. Most scientific algorithms have moved across to libraries in
other languages. I expect oldies like myself who were never taught
formal programming except part of a maths syllabus would like to hold
on to it but...no. 15 years ago I would have died for Fortran but now
we have mathematica,matlab,mathcad etc etc why the hell would I bother
at all? For supercomputing maybe but the vast majority of applications
no. Let's examine it closely
Maths...yes definately..far superior to all languages.
Graphics...never.
Embedded systems...never in a million years.
Ascii text...not really
compilers..you kiddin!
AI...never.
So it has one main application..Maths number crunching which was what
it was invented for. If I was simulating with a parallel super-
computer I might use parallel fortran but for most smaller
applications..not on your Nelly!
K.
sgian...@gmail.com
> On Aug 20, 8:56 am, Gib Bogle <bo...@ihug.too.much.spam.co.nz> wrote:
>
> > kronec...@yahoo.co.uk wrote:
> > > Gosh, this was a big surprise. I though Fortran was dead as a Dodo!
> > > Why are people still using it? I was a great fan of it until about
> > > 1997 when I moved to Matlab...then LabView. Why the need to resurect
> > > Fortran? Yes, I know C is shite, has no complex numbers etc but that's
> > > not an excuse.
>
> > > K.
>
> > What a surprisingly foolish post!
>
> Why? Fortran was a great language for maths there is no doubt...but it
> has had its day now surely.
> Even C++ is being replaced by many industries with C#. Pascal is dead
> too and Modula2. I remember them all.
> None of them was as good as Fortran but I wouldn't dream of using it
> now. Most scientific algorithms have moved across to libraries in
> other languages.
As far as I know, many high levels softwares like Matlab and R still
use BLAS et similia which are all F77.
I expect oldies like myself who were never taught
> formal programming except part of a maths syllabus would like to hold
> on to it but...no. 15 years ago I would have died for Fortran but now
> we have mathematica,matlab,mathcad etc etc why the hell would I bother
> at all? For supercomputing maybe but the vast majority of applications
> no. Let's examine it closely
>
> Maths...yes definately..far superior to all languages.
> Graphics...never.
> Embedded systems...never in a million years.
> Ascii text...not really
> compilers..you kiddin!
> AI...never.
>
> So it has one main application..Maths number crunching which was what
> it was invented for. If I was simulating with a parallel super-
> computer I might use parallel fortran but for most smaller
> applications..not on your Nelly!
>
> K.
I think you miss a fundamental point which may answer to your question
(if yours was ever a question).
FORTRAN (as well C C++ etc..) code can be integrated easily into
Matlab, R etc, and many (everyday) scientific computing problems
require the benefits of FORTRAN over the inefficiency of high level
software.
As an aside, some years ago I was involved in a project that required
working with odesolvers. I was using the "powerful" Matlab while my
older colleague was implementing the same work in FORTRAN (actually
F77). Well, the results were different and guess what? Matlab was
wrong as its loss of precision on chaotic trajectories led to
incorrect results.
If you had documented yourself a bit you would not have been
surprised.
Regards,
Simone
Catherine Rees Lay
Exactly.
For the vast majority of applications I'd never use Fortran.
But I don't use Fortran to write the vast majority of applications. I
use Fortran to write applications where I've found that it's the best
language to use. No one language will _ever_ be the answer for every
application, or even for the vast majority, so I'm not sure quite why
you're surprised that a language which, surprise surprise, is good for
some things but not others, is still alive and kicking. Every single
language out there is in exactly the same boat.
And number crunching is hardly _one_ application, or limited to
supercomputers, regardless of the language being used.
--
Catherine Rees Lay
Polyhedron Software Ltd. Registered Office: Linden House,
93 High St, Standlake, Witney, OX29 7RH, United Kingdom.
Registered in England No.2541693. Vat Reg No. GB 537 3214 57
Luka Djigas
mathcad
I find it to be useless for most purposes. As I remember correctly, a
version which was actual few years ago (2, maybe 3 years ago) had a
restriction that matrixes cound't have more than a 100 elements. Don't
know if that changed in the later versions.
I took a matrix, inverted it, and multiplied it with the original one,
and didn't get the 1 matrix (the one with 1ns on the main diagonal, I
don't know how is it called in english).
> etc etc why the hell would I bother
>at all? For supercomputing maybe but the vast majority of applications
>no. Let's examine it closely
>
>Maths...yes definately..far superior to all languages.
>Graphics...never.
>Embedded systems...never in a million years.
>Ascii text...not really
>compilers..you kiddin!
>AI...never.
>
>So it has one main application..Maths number crunching which was what
>it was invented for. If I was simulating with a parallel super-
>computer I might use parallel fortran but for most smaller
>applications..not on your Nelly!
>
Yes, but fortran was never intended for vast majority of applications.
It was never intended for anything *but* number crunching. It was
intended just for that, and still serves its purpose very good.
Personally, I don't recall seeing any other compiled language which is
even remotely as user friendly as fortran for that purpose.
But, let's stop now, shall we ?
In the beginning of the thread there was some discussion whether you
were a troll or not ? It is now obvious that either you are, so that
we should end this discussion, or you're not, but you're so poorly
informed, that you should go and read a little google/wikipedia/books
on the subject.
Best regards
Luka
Gary Scott
> On Aug 20, 8:56 am, Gib Bogle <bo...@ihug.too.much.spam.co.nz> wrote:
>
>>kronec...@yahoo.co.uk wrote:
>>
>>>Gosh, this was a big surprise. I though Fortran was dead as a Dodo!
>>>Why are people still using it? I was a great fan of it until about
>>>1997 when I moved to Matlab...then LabView. Why the need to resurect
>>>Fortran? Yes, I know C is shite, has no complex numbers etc but that's
>>>not an excuse.
>>
>>>K.
>>
>>What a surprisingly foolish post!
>
>
> Why? Fortran was a great language for maths there is no doubt...but it
> has had its day now surely.
That's a very limited view of what Fortran was used for. It was at one
time, the common "systems programming" language (with extension
typically of course) other than assembly for many systems.
> Even C++ is being replaced by many industries with C#. Pascal is dead
> too and Modula2. I remember them all.
> None of them was as good as Fortran but I wouldn't dream of using it
> now. Most scientific algorithms have moved across to libraries in
> other languages. I expect oldies like myself who were never taught
> formal programming except part of a maths syllabus would like to hold
> on to it but...no. 15 years ago I would have died for Fortran but now
> we have mathematica,matlab,mathcad etc etc why the hell would I bother
> at all? For supercomputing maybe but the vast majority of applications
> no. Let's examine it closely
>
> Maths...yes definately..far superior to all languages.
> Graphics...never.
> Embedded systems...never in a million years.
> Ascii text...not really
> compilers..you kiddin!
> AI...never.
>
> So it has one main application..Maths number crunching which was what
> it was invented for. If I was simulating with a parallel super-
> computer I might use parallel fortran but for most smaller
> applications..not on your Nelly!
>
>
> K.
Gary Scott
> kron...@yahoo.co.uk wrote:
>
>> For supercomputing maybe but the vast majority of applications
>> no.
>
>
> Exactly.
>
> For the vast majority of applications I'd never use Fortran.
>
> But I don't use Fortran to write the vast majority of applications. I
> use Fortran to write applications where I've found that it's the best
> language to use. No one language will _ever_ be the answer for every
> application, or even for the vast majority, so I'm not sure quite why
> you're surprised that a language which, surprise surprise, is good for
> some things but not others, is still alive and kicking. Every single
> language out there is in exactly the same boat.
>
> And number crunching is hardly _one_ application, or limited to
> supercomputers, regardless of the language being used.
>
And Fortran is a very good general purpose language suitable for a wide
variety of programming domains.
Gary Scott
This is not even close to actual usage of Fortran. It was widely used
as the main systems programming language in addition to assembly on many
computing systems of the past.
>
> But, let's stop now, shall we ?
> In the beginning of the thread there was some discussion whether you
> were a troll or not ? It is now obvious that either you are, so that
> we should end this discussion, or you're not, but you're so poorly
> informed, that you should go and read a little google/wikipedia/books
> on the subject.
>
> Best regards
> Luka
Luka Djigas
<garyl...@sbcglobal.net> wrote:
>This is not even close to actual usage of Fortran. It was widely used
>as the main systems programming language in addition to assembly on many
>computing systems of the past.
>
Please, elaborate. What do you mean under "main systesm programming
language" ?
Best regards
Luka
Fly Away
> > Yes, but fortran was never intended for vast majority of applications.
> > It was never intended for anything *but* number crunching. It was
> > intended just for that, and still serves its purpose very good.
> > Personally, I don't recall seeing any other compiled language which is
> > even remotely as user friendly as fortran for that purpose.
>
> This is not even close to actual usage of Fortran. It was widely used
> as the main systems programming language in addition to assembly on many
> computing systems of the past.
I guess a more correct statement would be "standard Fortran was never
intended for anything but number crunching." Extensions provided the
functionality that made it possible to use Fortran for other tasks.
IMHO.
Victor.
Fly Away
> Catherine Rees Lay wrote:
> > kronec...@yahoo.co.uk wrote:
>
> >> For supercomputing maybe but the vast majority of applications
> >> no.
>
> > Exactly.
>
> > For the vast majority of applications I'd never use Fortran.
>
> > But I don't use Fortran to write the vast majority of applications. I
> > use Fortran to write applications where I've found that it's the best
> > language to use. No one language will _ever_ be the answer for every
> > application, or even for the vast majority, so I'm not sure quite why
> > you're surprised that a language which, surprise surprise, is good for
> > some things but not others, is still alive and kicking. Every single
> > language out there is in exactly the same boat.
>
> > And number crunching is hardly _one_ application, or limited to
> > supercomputers, regardless of the language being used.
>
> And Fortran is a very good general purpose language suitable for a wide
> variety of programming domains.
>
I disagree. Although, your definition of "general purpose language" is
different.
Victor.
Gary Scott
Meaning the OS APIs were written in Fortran (and assembly) and tailored
specifically for Fortran. Some OS' even carried over Fortrans concept
of logical file numbers and similar features in the JCL.
Gary Scott
I'm using it to access I/O hardware through port read/writes, data
acquisition, low level serial bus (MIL-STD-1553) programming, and
similar "systems programming" tasks. I find that it serves these roles
every bit as well as C, with only a single language extension
(integer/cray/whatever pointers) and some compiler directives. F2003
will all but eliminate my use of those extended features (some day).
The only reason I need them though is that the APIs are written in
another language. They could have been written compatibly but weren't.
So ANY time you want to program using a different language than the
API was written for (a C API and you want to use Ada, PL/1, Smalltalk,
Jovial, Modula, whatever), you would have those interfacing issues to
deal with. True, some languages deal with them better than others, but
Fortran's glacier is about to melt.
>
> Victor.
Richard Maine
> I guess a more correct statement would be "standard Fortran was never
> intended for anything but number crunching."
Since I participated in development of several of the Fortran standards
(and was even editor of 2), and I personally know that I intended it for
other things as well, that's about as direct a disproof of that
statement as there can be.
Fly Away
So pretty much, to use Fortran for "general purpose programming",
whatever that may be other than number crunching, one would either
have to use extensions or call libraries written in other languages.
So I'd rather say that you have "general purpose" compilers that allow
you to perform the above mentioned tasks rather than a general purpose
language.
Victor.
Fly Away
> Fly Away <victor.proso...@gmail.com> wrote:
> > I guess a more correct statement would be "standard Fortran was never
> > intended for anything but number crunching."
>
> Since I participated in development of several of the Fortran standards
> (and was even editor of 2), and I personally know that I intended it for
> other things as well, that's about as direct a disproof of that
> statement as there can be.
Well, that statement might be overly exaggerated in terms of what
Fortran is "intended" for, but what I see is that Fortran is primarily
used for doing heavy computations. Sure enough, my experience is not
as extended as yours, yet I see what I see.
Victor.
Richard Maine
"Intended" is a questionable word to use in such contexts, but if one is
being precise, so far as I can tell, it is humans that have intents
(well, except for things like intent(in) :-). If you want to use the
word "intended" (and it was your choice of word), then I don't see how
you can find a more definitive statement of the intent of one of the
humans involved (and one of the ones most deeply involved) that what he
(that would be me) testifies to. Certainly nobody else can tell you any
better.
I also don't see how I can be exagerating my own intents. Indeed, my
comment was rather middle-of-the-road in that I said I intended it for
other things "as well." Statements like that it was *never* intended for
*anything* sound much more like exagerated words to me.
Perhaps "intended" wasn't what you actually meant.
Gary Scott
I'd say that's quite a misunderstanding.
Fly Away
I don't think the use of the "mis" prefix is right. This is my
understanding based on experience and substantiated by what you said.
This is how I read it.
Victor.
Gary Scott
You seem to be equating ability to interoperate with any random other
programming language as an essential component of "system programming".
It isn't. If the OS API is written in the same language or compatible
with, then ANY compatible language can be used for "system programming".
And there are many examples of operating systems in which Fortran was
used for such purposes, some with no requirement for extensions.
Extensions were commonly provided. However, there are ample examples
in today's most common operating system APIs that effectively constitute
language extensions to C. Microsoft makes a good living out of inventing
proprietary language extensions.
Fly Away
I meant that I was the one who exaggerated. :)
>
> Perhaps "intended" wasn't what you actually meant.
The word "intended" was the choice of Mr. Luka Djigas. I just tried to
soften his statement, keeping the wording and to emphasize that yes,
Fortran can be used for different tasks, even systems programming, but
that would most likely, I would even say, inevitably involve using non-
standard features (pre F2003).
Victor.
Fly Away
> You seem to be equating ability to interoperate with any random other
> programming language as an essential component of "system programming".
> It isn't. If the OS API is written in the same language or compatible
> with, then ANY compatible language can be used for "system programming".
> And there are many examples of operating systems in which Fortran was
> used for such purposes, some with no requirement for extensions.
> Extensions were commonly provided. However, there are ample examples
> in today's most common operating system APIs that effectively constitute
> language extensions to C. Microsoft makes a good living out of inventing
> proprietary language extensions.
Initially, you were talking about "general purpose programming", not
"systems programming".
I guess this comes down to whether a program written in Fortran using
non-standard extensions can support the statement that Fortran is a
good general purpose programming language (GPPL). So basically a
matter of definition of general purpose programming.
Victor.
Gary Scott
General purpose means in part that it can serve successfully in multiple
problem domain areas. I merely provided an example beyond "number
crunching.
Anyway, uncle.
J. F. Cornwall
The main language used for all sorts of applications, as well as many
utilities used by the OS, or as a suite of tools and library routines
provided by the OS for use by applications. That's what *we* used the
term for, at any rate (USAF weather computing facility).
The applications written in Fortran included number-crunching forecast
models, homegrown database systems, real-time communications
(HyperChannel between the mainframes, and assorted external comm line
links to outside systems), and a few other smaller programs for
maintaining routing libraries and so on. There were numerous libraries
of useful routines mostly written in Fortran, some in assembler, and
even a little bit of C.
And, in my current job, we use Fortran and a bit of C to run a water
database with real-time data input from satellite, an entire suite of
applications, and human interface programs - almost all of which is in
Fortran. We use C where it's needed, but I'd say over 95% of the code
is Fortran. Embedded dynamic SQL (Ingres RDBMS), number-crunching
(mainly for statistics), human interface handling, the whole range of
things a general purpose language should cover...
Jim
>
>
>
> Best regards
> Luka
Kevin G. Rhoads
Depending upon one's definition, assembler may be the only "general
purpose programming" language for a machine.
However, if one does not take a ridiculously extreme definition for
"general purpose programming" then other that just assembly may
be considered.
Fortran-77 is as "general purpose" as were Pascal, C, Basic or COBOL-74
in the late '70s through early '90s.
Fortran-66 is as "general purpose" as were Algol-68, PL/I, COBOL in the
'60s and early '70s.
Fortran-90/95 is as general purpose as were C++, Modula-2, Modula-3 in the
'90s.
Fortran was never as good at specialties as were specialty languages, but
neither were C, C++, Pascal, COBOL &c.
There is a reason there were things like AWK, PERL, Lex/Yacc, LISP, SNOBOL,
Simula<various> &c &c.
Is Fortran as good for business-oriented programming as COBOL or PL/1 - NO.
Is C more portable than Fortran - not without LINT, probably not even with LINT.
Is Fortran better for anything? Yes -- high performance numerics, ready portability,
ease of coding (MHOO - YMMV) and when new code compiles correctly one is 80%
there on average, as opposed to 30% there with C. Other people may have other
things they like or think are advantageous about Fortran.
Many people think C is more suited to system programming than is Fortran,
but except for memory pointers, even Fortran-77 was well suited for sys stuff.
And one can make a fairly good argument that pointers, particularly as implemented
in C, are the "root of all errors". Certainly most of the security hole exploits
for modern OSes can be traced to C-ish paradigms for string-handling and
pointers.
I've programmed in many assemblers (360 BAL, IBM 709x, CDC-6x00, PDP-8, 1401,
1620, 8031/8051, x86, PDP-11, 68000) and in Algol (60, 68), COBOL(74), Fortran(IV, 66, 77),
Basic (many flavors), Pascal, LISP, PL/1 (both IBM and Multics), Forth and C (K&R, ANSI-90).
For most things my first choice is Fortran -- usually -77. It is more portable than C,
available on as many platforms, if not more, and programs are ezasier to debug and
get running right. Occasionally I'll subroutines in assembler, but for most things
I don't need to do so. And I have code that I started using with OS/360 & Fortran-G
that has migtrated from Hollerith cards to punched paper tapes to floppies to hard drives
on my PCs.
Is Fortran a general purpose programming language? - dang right it is!
Should you use it? -- that's your choice, not ours. But don't try to convince us
that any ill-informed, prejudicial, knee-jerks are convincing evidence that we
should change. I've heard "Fortran is dead" for decades. Many other languages
came and went in those decades, Fortran is still around and still useful.
The main criticism that I've heard about a language that makes sense is that
Forth is often write-only code. You have to define new verbs, and later no
one knows what they do. I expect that several decades from now there will
be similar criticism of C++ about defining classes (and never adequately
documenting them -- after all code reads (and if you believe that I'd like
to offer to sell you a bridge in the NY area...)).
I worry about all the OO stuff that has lots of defining (and documenting
those defined things depends on individual and group discipline).
So, are you truly a troll? Or will you read and learn and comment on what
you learn?
James Giles
...
> Many people think C is more suited to system programming than is
> Fortran, but except for memory pointers, even Fortran-77 was well
Pointers aren't particularly relevant. F77 ubiquitously supported
extensions that made it acceptable for such purposes (dynamic
memory, non-record-oriented I/O, some bit manipulation).
To write compilers, systems, drivers, or other such code you
should avoid pointers with the same disdain many people have
for GOTOs.
The perception that such tasks require lots of pointers is "cart before
the horse" reasoning. People see systems written that use pointers
excessively and conclude that pointers are necessary for that
kind of programming. I think there's probably some latin
name for that particular fallacy, since that kind of poor reasoning
is quite old indeed.
...
> Is Fortran a general purpose programming language? - dang right it is!
*All* major high-level languages are general purpose. They have
to be. If they were only able to do some specialty, you would never
be able to write workable programs. Consider a common Fortran
program: the finite-differencing code. The number crunching
probably occurs in perhaps 1/1000th of the program. The rest
is input, output, or database stuff designed to push the mesh
through the differencing equations as fast as possible. Most
of the code is *not* number crunching.
Fly Away
I am not trying to convince personally you in anything. I simply don't
care what language you have used, are using now or will be using in
the future. I am discussing things that are of interest to me and
arguing with statements that are either unclear to me or I disagree
with.
> The main criticism that I've heard about a language that makes sense is that
> Forth is often write-only code. You have to define new verbs, and later no
> one knows what they do. I expect that several decades from now there will
> be similar criticism of C++ about defining classes (and never adequately
> documenting them -- after all code reads (and if you believe that I'd like
> to offer to sell you a bridge in the NY area...)).
>
> I worry about all the OO stuff that has lots of defining (and documenting
> those defined things depends on individual and group discipline).
>
> So, are you truly a troll? Or will you read and learn and comment on what
> you learn?
You seem to be arguing with a statement I never made or even intended
to make. I did not say Fortran was dead or even bad. I didn't argue in
favor of any particular language. And I don't really understand why
you are being so aggressive.
I do think that the choice of programming language depends on the
problem. I can't say much about pre-90s era because I was too young at
that time. I don't have a baggage of ancient and dead languages and
OSs that you mentioned, but I don't need to know all that stuff to
have an opinion on what is good or bad these days. If you choose F77
for systems programming today, I feel sorry for you. It's pointless to
have a further discussion on that. Period.
Even if you choose F77 over F90/95/03 for numerical programming today,
why would you do that? If you don't know any post-F77 Fortran, you
simply can't make judgment about how good (or bad) Fortran is in
general in today's world. So it's pointless to have a further
discussion on this either.
I don't consider the case when one has to deal with legacy code here.
I think it's irrelevant to the discussion.
I don't intend to discuss deficiencies of C/C++ here, but however bad
they may be they have their market share.
Victor.
Fly Away
wrote:
> Kevin G. Rhoads wrote:
>
> ...
>
> > Many people think C is more suited to system programming than is
> > Fortran, but except for memory pointers, even Fortran-77 was well
> > suited for sys stuff. [...]
>
> Pointers aren't particularly relevant. F77 ubiquitously supported
> extensions that made it acceptable for such purposes (dynamic
> memory, non-record-oriented I/O, some bit manipulation).
Yup, here we go with extensions again. It nullifies the portability
argument.
>
> To write compilers, systems, drivers, or other such code you
> should avoid pointers with the same disdain many people have
> for GOTOs.
Perhaps, then you should avoid writing "compilers, systems, drivers,
or other such code" instead.
>
> The perception that such tasks require lots of pointers is "cart before
> the horse" reasoning. People see systems written that use pointers
> excessively and conclude that pointers are necessary for that
> kind of programming. I think there's probably some latin
> name for that particular fallacy, since that kind of poor reasoning
> is quite old indeed.
Every tool has advantages and disadvantages. Excessive use of anything
is bad. Pointers are no exception.
Victor.
James Giles
> On Aug 21, 12:49 pm, "James Giles" <jamesgi...@worldnet.att.net>
> wrote:
>> Kevin G. Rhoads wrote:
>>
>> ...
>>
>>> Many people think C is more suited to system programming than is
>>> Fortran, but except for memory pointers, even Fortran-77 was well
>>> suited for sys stuff. [...]
>>
>> Pointers aren't particularly relevant. F77 ubiquitously supported
>> extensions that made it acceptable for such purposes (dynamic
>> memory, non-record-oriented I/O, some bit manipulation).
>
> Yup, here we go with extensions again. It nullifies the portability
> argument.
In those days OS's weren't portable. People would have thought
it a silly idea. Compilers were *obviously* not portable, they
depended on both systems and instruction sets (still do, but with
some commonality available).
Nowdays, all needed features are standard in Fortran. No other
features are needed.
>> To write compilers, systems, drivers, or other such code you
>> should avoid pointers with the same disdain many people have
>> for GOTOs.
>
> Perhaps, then you should avoid writing "compilers, systems, drivers,
> or other such code" instead.
In fact, I've written compilers, and maintained them. Have you?
I what way is your opinion founded on knowledge (personal
experience or otherwise)? Please state, explicitly and clearly,
what features and/or capabilities that Fortran *doesn't* have
that you personally know from direct experience are needed
for systems programming, or compilers, or string manipulation,
or .... Either that, or quit claiming to know what the strengths
of the language are (or aren't).
Kevin G. Rhoads
>I think it's irrelevant to the discussion.
No need to talk to you further then, is there?
Fly Away
> Fly Away wrote:
> > On Aug 21, 12:49 pm, "James Giles" <jamesgi...@worldnet.att.net>
> > wrote:
> >> Kevin G. Rhoads wrote:
>
> >> ...
>
> >>> Many people think C is more suited to system programming than is
> >>> Fortran, but except for memory pointers, even Fortran-77 was well
> >>> suited for sys stuff. [...]
>
> >> Pointers aren't particularly relevant. F77 ubiquitously supported
> >> extensions that made it acceptable for such purposes (dynamic
> >> memory, non-record-oriented I/O, some bit manipulation).
>
> > Yup, here we go with extensions again. It nullifies the portability
> > argument.
>
> In those days OS's weren't portable. People would have thought
> it a silly idea. Compilers were *obviously* not portable, they
> depended on both systems and instruction sets (still do, but with
> some commonality available).
Do you suggest younger people like myself should think the same way as
you did in "those days"?
>
> Nowdays, all needed features are standard in Fortran. No other
> features are needed.
>
> >> To write compilers, systems, drivers, or other such code you
> >> should avoid pointers with the same disdain many people have
> >> for GOTOs.
>
> > Perhaps, then you should avoid writing "compilers, systems, drivers,
> > or other such code" instead.
>
> In fact, I've written compilers, and maintained them. Have you?
> I what way is your opinion founded on knowledge (personal
> experience or otherwise)?
My opinion is based on open source projects like linux kernel, gcc
etc. If you have written and/or maintained something of comparable
value and complexity without using pointers, then I will consider your
stance on pointers more seriously.
Please state, explicitly and clearly,
> what features and/or capabilities that Fortran *doesn't* have
> that you personally know from direct experience are needed
> for systems programming, or compilers, or string manipulation,
> or .... Either that, or quit claiming to know what the strengths
> of the language are (or aren't).
Overall, Fortran seems to have most of the stuff you need. But... Will
you write hardware drivers in Fortran? I don't think so. Will you
write network applications Fortran? I don't think so. Will you write
text processing software in Fortran? I don't think so. Will you write
a GUI library in Fortran? I don't think so. This is just a few
examples. Is it possible to do all those things in Fortran? Yes, if
you call libraries written in other languages. Would it be better to
use more suitable languages for that? Yes, I think so.
None of this implies Fortran is a _bad_ language. I personally enjoy
coding numerical stuff in Fortran and think it's the best tool for
that. But to do quick file manipulation I use shell scripts. To work
with text files, I used Perl. For web programming I used PHP. And so
on. Now I am switching to Python for all kinds of "general purpose
programming". If need be I will use whatever suites the task better
regardless of how much I like something else.
Victor.
Gary Scott
But all these things ARE done, in Fortran, and quite well.
Yes, if
> you call libraries written in other languages. Would it be better to
> use more suitable languages for that? Yes, I think so.
> None of this implies Fortran is a _bad_ language. I personally enjoy
> coding numerical stuff in Fortran and think it's the best tool for
> that. But to do quick file manipulation I use shell scripts. To work
> with text files, I used Perl. For web programming I used PHP. And so
> on. Now I am switching to Python for all kinds of "general purpose
> programming". If need be I will use whatever suites the task better
> regardless of how much I like something else.
>
> Victor.
James Giles
...
>>> Yup, here we go with extensions again. It nullifies the portability
>>> argument.
>>
>> In those days OS's weren't portable. People would have thought
>> it a silly idea. Compilers were *obviously* not portable, they
>> depended on both systems and instruction sets (still do, but with
>> some commonality available).
>
> Do you suggest younger people like myself should think the same way as
> you did in "those days"?
If the times have changed, then a complaint that Fotran *did* require
non-standard features is an irrelevant one. You're the one that keeps
harping on Fortran's past. C was not portable then either. Fortran
was, and is, one of the most portable around.
> My opinion is based on open source projects like linux kernel, gcc
> etc. If you have written and/or maintained something of comparable
> value and complexity without using pointers, then I will consider your
> stance on pointers more seriously.
So, you admit to no knowledge at all, Fine, you would have
a lot of effort if you had admitted cluelessness from the start.
James Giles
> So, you admit to no knowledge at all, Fine, you would have [saved]
Fly Away
Should I hope some examples will follow?
Victor.
James Giles
...
>> But all these things ARE done, in Fortran, and quite well.
>
> Should I hope some examples will follow?
You've not responded to requests for specific examples, and
you've arbitrarily dismissed examples given by others prior to
this. Why would anyone waste further time on your trolling?
Or, do you yet have *specific* features that Fortran lacks that
you think necessary for variouis programming tasks you've
mentioned?
Fly Away
> Fly Away wrote:
>
> ...
>
> >> But all these things ARE done, in Fortran, and quite well.
>
> > Should I hope some examples will follow?
>
> You've not responded to requests for specific examples, and
> you've arbitrarily dismissed examples given by others prior to
> this. Why would anyone waste further time on your trolling?
True, why are you still wasting your time?
Actually, I am not trolling. I am just trying to comprehend some
things I do not understand. One of them is why would people use
Fortran for tasks for which there are plenty of much more suitable
tools? Your discussing things you don't know about me personally, like
my experience and knowledge, is clearly out of scope and not helping
anything.
> Or, do you yet have *specific* features that Fortran lacks that
> you think necessary for variouis programming tasks you've
> mentioned?
I've just reread the thread to make sure that I didn't say that
Fortran lacked any specific features. Sure I didn't say that.
Victor.
James Giles
...
> Actually, I am not trolling. I am just trying to comprehend some
> things I do not understand. One of them is why would people use
> Fortran for tasks for which there are plenty of much more suitable
> tools? Your discussing things you don't know about me personally, like
> my experience and knowledge, is clearly out of scope and not helping
> anything.
On the contrary, you keep making confident assertions and not
backing them up. A clear exposition of your level of knowledge
would go a long way in shaping clear answers. Your "question"
is always accompanied with direct answers of your own (inaccuate
and of an insulting tone).
> I've just reread the thread to make sure that I didn't say that
> Fortran lacked any specific features. Sure I didn't say that.
Yet you claim Fortran is inappropriate for large classes of
programming tasks. You claim so with no evidence, and with
insulting tone.
Fly Away
> Fly Away wrote:
>
> ...
>
> > Actually, I am not trolling. I am just trying to comprehend some
> > things I do not understand. One of them is why would people use
> > Fortran for tasks for which there are plenty of much more suitable
> > tools? Your discussing things you don't know about me personally, like
> > my experience and knowledge, is clearly out of scope and not helping
> > anything.
>
> On the contrary, you keep making confident assertions and not
> backing them up. A clear exposition of your level of knowledge
> would go a long way in shaping clear answers. Your "question"
> is always accompanied with direct answers of your own (inaccuate
> and of an insulting tone).
I simply express my opinion. Sure I have my own answers to those
questions because I've programmed a great deal in Fortran and can
compare it to some other languages. I am just trying to understand why
my answers are not the same as some other people's.
>
> > I've just reread the thread to make sure that I didn't say that
> > Fortran lacked any specific features. Sure I didn't say that.
>
> Yet you claim Fortran is inappropriate for large classes of
> programming tasks. You claim so with no evidence, and with
> insulting tone.
There is a long way from "inappropriate" to "not the most suitable". I
claim the latter you accuse me of claiming the former.
Victor.
James Giles
...
> There is a long way from "inappropriate" to "not the most suitable". I
> claim the latter you accuse me of claiming the former.
Synonyms are "a long way" apart? And you are still ducking the
question: do you or do you not have *specific* reasons to assert
that Fortran is "not the most suitable" language for the several
application domains you've mentioned? I know why I think
it isn't. But I consider it generally more suitable than C or C++
(as examples of a long list of languages I wouldn't wish on
a worst enemy). And while we're at it, why do you believe
that application domain is even relevant to the issue of language
suitability? Have you objective evidence that leads you to
believe so?
ttw...@att.net
>
> Overall, Fortran seems to have most of the stuff you need. But... Will
> you write hardware drivers in Fortran? I don't think so. Will you
> write network applications Fortran? I don't think so. Will you write
> text processing software in Fortran? I don't think so. Will you write
> a GUI library in Fortran? I don't think so. This is just a few
> examples. Is it possible to do all those things in Fortran? Yes, if
> you call libraries written in other languages. Would it be better to
> use more suitable languages for that? Yes, I think so.
> None of this implies Fortran is a _bad_ language. I personally enjoy
> coding numerical stuff in Fortran and think it's the best tool for
> that. But to do quick file manipulation I use shell scripts. To work
> with text files, I used Perl. For web programming I used PHP. And so
> on. Now I am switching to Python for all kinds of "general purpose
> programming". If need be I will use whatever suites the task better
> regardless of how much I like something else.
>
> Victor.- Hide quoted text -
>
> - Show quoted text -
I've written lots of text processing in Fortran. Not all the screen
drivers though. With about 5 or 6 subroutines in assembly, (direct
write to a location on the screen and read what and where was typed),
it wasn't hard to do most of the screen processing in Fortran.
I've also written file compression in Fortran; I only needed special I/
O to implement pipes and redirection from the command line.
HTML is easy to both read and write in Fortran for that matter (I've
done it.)
All that's really needed is a sufficient I/O library. Much computing
consists of just reading and writing (and interpreting) strings of
data. I didn't write the I/O library for these applications though;
James Giles did; in Fortran.
James Giles
I can't think of any way to prevent it. And I can't think of any
way someone on fixed income can survive it.
James Giles
kron...@yahoo.co.uk
What the hell would you want to do that for? Talk about square keys in
round holes!
Is this an intellectual exercise or are you just incapable of learning
c?
K
kron...@yahoo.co.uk
Yes but generally speaking they do improve things a lot. C# is far
easier to read and program in than C++.
Similarly VB.Net is nearly all you need in a language. (except it
lacks Fortrans number crunching like nearly all new languages). For
example, in C# or VB.Net why the hell would you want to put math()
around an expression when you need sine or cos! Similarly for complex
numbers, the Fortran syntax is automatic once it is defined. I realise
that by overloading ones operators this can be achieved with a lot of
trouble in C++ but it is too much trouble.
What we need is a VB.Net(actually C# would be better becuase it can
handle unmanged code) with Fotrans numerical capability. Then you
would have a language that could do anything.
K.
kron...@yahoo.co.uk
What sort of GUI do you have? Or is it only numbers you have as an
output?
K.
kron...@yahoo.co.uk
I spent around 20 years programming in Fortran.You don't have to
convince me of how good it WAS! I am just questioning if we really
need it now. Portability for example. For good or bad reasons the
majority of people around the world use Microsoft. Now many people
hate this fact and Bill Gates etc. Personally I feel this is an
advantage since it has standardised computers. Talk about
portability...modern languages don't need to be in the first place
since there is only MS and Unix to worry about and the Unix crowd are
a minority Asbergers lot in any case.
If you are using a Cray or some such specialist OS then fair enough
but not many of us are in that catagory.
It is simply rubbish to say that one language cannot do everything. C+
+ can and indeed does, either in Unix or MS.
Now I hate the bloody language and maybe you guys do too, but it can
handle everything, maybe not as elegantly doing maths as Fortran of
course.
K.
Richard Maine
[more trolling]
He has graduated from just being ignored in this thread to a place in my
permament kill file. I recommend that others do the same instead of
feeding the troll. As typical of trolls, there is clearly no interest in
learning, communication, or anything positive - just in flaming.
I see he seems to be trolling to start some non-Fortran-related flame
wars here as well. It would be really nice if people would just ignore
it all. To those who choose to participate further, be aware that such
flame wars reflect poorly on *ALL* the participants. To quote from the
movie War Games, "A strange game. The only way to win is not to play."
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
kron...@yahoo.co.uk
Don't flatter yourself man. What is there to learn in Fortran that I
didn't know in 1980!
Still, the Print*,"ssdsdsd" thingy was a good move away from
write(6,...)I could never rememebr which number was read and which was
right!
K.
Gary Scott
it's just as easy, in fact easier than doing it in C. I only had to
create a few API prototypes. The rest of the application will be a breeze.
>
> K
Gary Scott
You can call the OS API directly or you can use one of the many GUI
builders availalbe specifically for Fortran.
>
> K.
James Van Buskirk
news:1im1t5o.4om3rm10o5t80N%nos...@see.signature...
> He has graduated from just being ignored in this thread to a place in my
> permament kill file. I recommend that others do the same instead of
> feeding the troll. As typical of trolls, there is clearly no interest in
> learning, communication, or anything positive - just in flaming.
Telling people whom they should killfile comes off as arrogant. Just
recall the E. Bob had just such a list of people to killfile on his
website but he was himself considered a laughingstock.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Gary Scott
> "Richard Maine" <nos...@see.signature> wrote in message
> news:1im1t5o.4om3rm10o5t80N%nos...@see.signature...
>
>
>>He has graduated from just being ignored in this thread to a place in my
>>permament kill file. I recommend that others do the same instead of
>>feeding the troll. As typical of trolls, there is clearly no interest in
>>learning, communication, or anything positive - just in flaming.
>
>
> Telling people whom they should killfile comes off as arrogant. Just
> recall the E. Bob had just such a list of people to killfile on his
> website but he was himself considered a laughingstock.
>
It was good advice. I just hope my message cancelations took.
Kevin G. Rhoads
>So, you admit to no knowledge at all, Fine, you would have
>a lot of effort if you had admitted cluelessness from the start.
The problem seems less that of cluelessness and more that of
active ignorance. Neither "FlyAway" nor the "kronecker"
persona (whether they be one physical form or two) seems
interested in anything other than promulgating outdated
prejudice in manners apparently shaped toward starting
flaminations.
You can not win an argument with a babbling brook --
or at least that's MHO on this.
Fly Away
> Fly Away wrote:
>
> ...
>
> > There is a long way from "inappropriate" to "not the most suitable". I
> > claim the latter you accuse me of claiming the former.
>
> Synonyms are "a long way" apart? And you are still ducking the
> question: do you or do you not have *specific* reasons to assert
> that Fortran is "not the most suitable" language for the several
> application domains you've mentioned? I know why I think
> it isn't. But I consider it generally more suitable than C or C++
> (as examples of a long list of languages I wouldn't wish on
> a worst enemy). And while we're at it, why do you believe
> that application domain is even relevant to the issue of language
> suitability?
If you call those two synonyms, no wonder you still are not getting my
point. Do you really see no difference or are you just being
expressive?
Ok. Back to the point.
Task - text processing. Fortran doesn't have regular expressions. I
haven't seen any Fortran libraries that do that. This, of course,
doesn't mean they don't exist, but I haven't been able to find one.
Task - file manipulation. Can you create a folder or copy a file in a
portable standard conforming way?
Task - using basic well established algorithms like all kinds of
sorting. To make it portable you would either have to write your own
implementation, i.e. reinvent the wheel, or resort to a library most
likely written in another language that will probably impose licensing
restrictions.
Task - Web programming. I am not sure even how to approach this in
Fortran. I think generating web pages using the write statement would
be weird and unnatural. Accessing web services from Fortran... Or
writing one... How would you do that?
Task - graphics. Third party libraries seem like the only option. Not
that it's different in many other languages, but there are lots more
options available outside the Fortran world. Especially in open-
source.
And the last point is availability of libraries for all kinds of
stuff. Even for numerics there are more options in C/C++, not to
mention other "generic programming" tasks. Why is it that Fortran is
not as popular as C++ or Java? Is it because all software engineers
are stupid or ignorant? I wouldn't believe so.
Basically, I am saying that there are specific tools for specific
tasks. I give Fortran enough credit for what it does well - numerical
computations. All the rest can be more conveniently done in other
languages. When I say conveniently, I mean for a person who is equally
proficient in several languages. If one is stuck in F77 world and
doesn't know other options, how can there be a meaningful discussion
on the matter?
I don't promote one particular language for everything. For "generic
programming" I would prefer one of the scripting languages (Python is
my choice these days, but I appreciate what Ruby, Perl and PHP have to
offer as well). If you want to glue all kinds of stuff together and
benefit from compiler optimization, I'd say C++. Yes, it is
complicated, some concepts are implemented better in other languages,
but yet I can't understand your complete denial of the strengths that C
++ has. Calling C/C++ an enemy is just beyond my comprehension. It's
merely a tool. How can you get so emotional about it?
>>And while we're at it, why do you believe
>>that application domain is even relevant to the issue of language
>>suitability?
I can't make sense of this question... Your wording often confuses me.
If you need to write an application you look for a suitable tool
(language). If you need to put a nail in the wall, you use a hummer,
not a microscope. So a hammer is more suitable for this kind of work
than a microscope. Is this relevant enough?
Victor.
Fly Away
> I disagree. Although, your definition of "general purpose language" is
> different.
>
I must say that I actually wanted to say "your definition is
[probably] different. Not that it would change the further discussion,
but just to make it clear that I didn't mean to be offensive or
anything like that.
Victor.
Fly Away
> >So, you admit to no knowledge at all, Fine, you would have
> >a lot of effort if you had admitted cluelessness from the start.
>
> The problem seems less that of cluelessness and more that of
> active ignorance. Neither "FlyAway" nor the "kronecker"
> persona (whether they be one physical form or two) seems
> interested in anything other than promulgating outdated
> prejudice in manners apparently shaped toward starting
> flaminations.
We are different persons with different levels of what you call
"active ignorance". I have stated what I am interested in above in
discussion with James Giles. And that is not what you say (or think) I
am interested in.
>
> You can not win an argument with a babbling brook --
> or at least that's MHO on this.
You can win (at least an argument with me) by actually arguing rather
than making subjective personal remarks about me.
Cheers,
Victor.
glen herrmannsfeldt
(snip)
> Task - text processing. Fortran doesn't have regular expressions. I
> haven't seen any Fortran libraries that do that. This, of course,
> doesn't mean they don't exist, but I haven't been able to find one.
C doesn't have one, either, but there are some written in C.
You can call them with C interoperability from Fortran.
> Task - file manipulation. Can you create a folder or copy a file in a
> portable standard conforming way?
Standard C, C++, etc., also don't have that.
> Task - using basic well established algorithms like all kinds of
> sorting. To make it portable you would either have to write your own
> implementation, i.e. reinvent the wheel, or resort to a library most
> likely written in another language that will probably impose licensing
> restrictions.
C has qsort. There are enough open source versions with
reasonably licenses. You can call one with C interoperability
from Fortran.
> Task - Web programming. I am not sure even how to approach this in
> Fortran. I think generating web pages using the write statement would
> be weird and unnatural. Accessing web services from Fortran... Or
> writing one... How would you do that?
CGI in Fortran should be about as easy as in most other languages.
> Task - graphics. Third party libraries seem like the only option. Not
> that it's different in many other languages, but there are lots more
> options available outside the Fortran world. Especially in open-
> source.
Call one from Fortran about as easy as those other languages.
> And the last point is availability of libraries for all kinds of
> stuff. Even for numerics there are more options in C/C++, not to
> mention other "generic programming" tasks. Why is it that Fortran is
> not as popular as C++ or Java? Is it because all software engineers
> are stupid or ignorant? I wouldn't believe so.
There are some numerical libraries in C or C++ (two different
languages), but much more written in Fortran. Very little
in Java, still.
(snip)
> I don't promote one particular language for everything. For "generic
> programming" I would prefer one of the scripting languages (Python is
> my choice these days, but I appreciate what Ruby, Perl and PHP have to
> offer as well).
Those and many other interpreted (scripting) languages are
available. Each has its following, and its uses, but
general programming isn't one. All are generally slower
than compiled Fortran or C, but in many cases that isn't
a problem. Matlab and Mathematica are popular for a
wide variety of numerical problems. Do any of those
have an ISO or ANSI standard?
-- glen
James Giles
> Task - text processing. Fortran doesn't have regular expressions. I
> haven't seen any Fortran libraries that do that. This, of course,
> doesn't mean they don't exist, but I haven't been able to find one.
I've written support for them. The code belongs to a former
employer, or I'd just post it. It's not hard. But - it's a library
issue, not a language issue. Or do you think libraries are
part of the language? That's *really* wierd. I've not
recently found a Fortran from which I couldn't call such
library routines if I needed them. (You would probably be
surprised at how little value such things have for tasks such
as compiler construction. Such simplistic library calls don't
have the efficiency or quite the right functionality for lexical
scanning or parsing. Better to stick with a table driven scanner.)
> Task - file manipulation. Can you create a folder or copy a file in a
> portable standard conforming way?
Not in Fortran. Not in any language. The concept of "folder"
(or "directory", "path", etc) is not portable. Some systems haven't
got them. Some systems haven't got files at all. The way different
languages do non-portable things varies. I've not seen a Fortran
that couldn't create directories on sytsems that supported them.
> Task - using basic well established algorithms like all kinds of
> sorting. To make it portable you would either have to write your own
> implementation, i.e. reinvent the wheel, or resort to a library most
> likely written in another language that will probably impose licensing
> restrictions.
Never met a sorting algorithm I couldn't code *more* legibly in
Fortran. Many of the old, and still most used, were *invented*
by Fortran programmers. (Maybe you are confused by the
fact that most publications presented algorithms in Algol?
I've seen places that didn't even *have* an Algol implementation,
and they sent their new algorithms to press written in Algol.
It's kind of like scientists until the 20th century: always publishing
in Latin even though most didn't speak Latin or use it in their
work.)
> Task - Web programming. I am not sure even how to approach this in
> Fortran. I think generating web pages using the write statement would
> be weird and unnatural. Accessing web services from Fortran... Or
> writing one... How would you do that?
I have no I idea what problem you're addressing. I use tools, not
languages, to write web pages. Always have. The "language" is
HTML or XTML augmented with CSS.
Or are you talking about "active content" (that vile reinvention
of animated roadside billboards)? In which case, since there
are only two languages that I know of, and only one widely
supported, that's not really a very good example. If you are
not presented with choices, that fact doesn't demonstrate
any weakness of the languages that you couldn't choose.
Implement Fortran support on web browsers, and we'll
see that it is suitable.
> Task - graphics. Third party libraries seem like the only option. Not
> that it's different in many other languages, but there are lots more
> options available outside the Fortran world. Especially in open-
> source.
Libraries (as mentioned above) are callable from Fortran no matter
what language they're in. Now, if you want to talk about how
to write such libraries more efficiently, more legibly, or with
more reliaility, they should perhaps have been in Fortran (or
something like it) in the first place. I'm not responsible for
the bad decisions of others.
> [...] Yes, it is
> complicated, some concepts are implemented better in other languages,
> but yet I can't understand your complete denial of the strengths that
> C ++ has. Calling C/C++ an enemy is just beyond my comprehension. It's
> merely a tool. How can you get so emotional about it?
You're the emotional one. I'm not particularly interested in C or
C++ anymore because I no longer use them. When I suppored
C compilers, I knew more about it than any three random users
you would care to name. If I have a disrespect for the language,
it's because I know it very well indeed.
The real question, the the one that points to an emotional
issue, is someone coming into a forum for users of a given
language and telling them what they shouldn't be using the
language for. Especially telling people that *have* successfully
written just such applications in Fortran. Many of whom know
and have used dozens of languages and who chose Fortran
because they found it *better* than the alternatives.
>>> And while we're at it, why do you believe
>>> that application domain is even relevant to the issue of language
>>> suitability?
>
> I can't make sense of this question... Your wording often confuses me.
> If you need to write an application you look for a suitable tool
> (language). If you need to put a nail in the wall, you use a hummer,
> not a microscope. So a hammer is more suitable for this kind of work
> than a microscope. Is this relevant enough?
Programming languages aren't hammers or microscopes. The analogy
is so completely bogus that there's no value to glean from it at all.
Programming languages are multiplex tools. Almost all of them have
the same collection of capabilities. Fortran and C, for example, are
practically isomorphic. The set of applications each is suited to is
the *same* set. What distinguishes them is which makes code easier
to write, read, verify, correct, extend, or maintain.
There have been objective experiments to measure the effect of
language features on programmer productivity. (There haven't
been enough of them, and since the results usually gore some
important sacred cows they aren't widely reported. And people
with vested interests to protect lobby against funding them. So,
unfortunately, most are old - but more recent than C.) For
each such tested feature, C pretty much adopts the loser.
Fly Away
> Fly Away wrote:
>
> (snip)
>
> > Task - text processing. Fortran doesn't have regular expressions. I
> > haven't seen any Fortran libraries that do that. This, of course,
> > doesn't mean they don't exist, but I haven't been able to find one.
>
> C doesn't have one, either, but there are some written in C.
> You can call them with C interoperability from Fortran.
Perl, Python, PHP etc. do. (I am not promoting C or any one single
_perfect_ language) Also, think of how much easier it is done in those
scripting languages.
> > Task - file manipulation. Can you create a folder or copy a file in a
> > portable standard conforming way?
>
> Standard C, C++, etc., also don't have that.
Perl, Python, PHP etc. do (see below about scripting standarts). C++
has Boost.
> > Task - using basic well established algorithms like all kinds of
> > sorting. To make it portable you would either have to write your own
> > implementation, i.e. reinvent the wheel, or resort to a library most
> > likely written in another language that will probably impose licensing
> > restrictions.
>
> C has qsort. There are enough open source versions with
> reasonably licenses. You can call one with C interoperability
> from Fortran.
Again, consider scripting languages. C++ has stl, stdlib, Boost.
>
> > Task - Web programming. I am not sure even how to approach this in
> > Fortran. I think generating web pages using the write statement would
> > be weird and unnatural. Accessing web services from Fortran... Or
> > writing one... How would you do that?
>
> CGI in Fortran should be about as easy as in most other languages.
If you had to use cgi for a task, would Fortran be your first choice?
>
> > Task - graphics. Third party libraries seem like the only option. Not
> > that it's different in many other languages, but there are lots more
> > options available outside the Fortran world. Especially in open-
> > source.
>
> Call one from Fortran about as easy as those other languages.
If they have Fortran interface. How many of them do? Especially open-
source.
>
> > And the last point is availability of libraries for all kinds of
> > stuff. Even for numerics there are more options in C/C++, not to
> > mention other "generic programming" tasks. Why is it that Fortran is
> > not as popular as C++ or Java? Is it because all software engineers
> > are stupid or ignorant? I wouldn't believe so.
>
> There are some numerical libraries in C or C++ (two different
> languages), but much more written in Fortran. Very little
> in Java, still.
I guess we wouldn't agree on this one unless we count all available
numerical libraries in all those languages. I guess it differs between
application, my experience shows exactly the opposite. MUCH MORE
software of interest to me is written in C/C++ (btw, I know C is
different from C++ :), but it so happens that one has a choice). Even
the fastest BLAS and LAPACK implementations are written in C and/or
assembler, which doesn't prevent calling it from Fortran. Well, again
I don't have a lot of experience with legacy code.
>
> (snip)
>
> > I don't promote one particular language for everything. For "generic
> > programming" I would prefer one of the scripting languages (Python is
> > my choice these days, but I appreciate what Ruby, Perl and PHP have to
> > offer as well).
>
> Those and many other interpreted (scripting) languages are
> available. Each has its following, and its uses, but
> general programming isn't one.
What's the use of those languages then?
> All are generally slower
> than compiled Fortran or C, but in many cases that isn't
> a problem.
Exactly. Why stick to a complicated compiled languages if you can get
the work done many times faster with a scripting language? That's when
I say there are more suitable tools.
> Matlab and Mathematica are popular for a
> wide variety of numerical problems. Do any of those
> have an ISO or ANSI standard?
Scripting languages typically have one reference implementation that
is de facto a standard.
Victor.
glen herrmannsfeldt
(snip)
>>>Task - text processing. Fortran doesn't have regular expressions.
(snip, I wrote)
>>C doesn't have one, either, but there are some written in C.
>>You can call them with C interoperability from Fortran.
> Perl, Python, PHP etc. do. (I am not promoting C or any one single
> _perfect_ language) Also, think of how much easier it is done in those
> scripting languages.
The perl, python, and PHP interpreters are written in
C or C++, and call a C regexp package. The person porting
the interpreter to your platform has to get it to work.
>>>Task - file manipulation. Can you create a folder or copy a file in a
>>>portable standard conforming way?
>>Standard C, C++, etc., also don't have that.
> Perl, Python, PHP etc. do (see below about
> scripting standarts). C++ has Boost.
Same as above, except that all OS dependence is usually
done with the C preprocessor to select the appropriate
OS dependent code. Someone else went to a lot of
work so that you don't have to. Also, complications
when running on systems that don't have subdirectories.
(snip on sorting)
>>>Task - Web programming. I am not sure even how to approach this in
>>>Fortran. I think generating web pages using the write statement would
>>>be weird and unnatural. Accessing web services from Fortran... Or
>>>writing one... How would you do that?
>>CGI in Fortran should be about as easy as in most other languages.
> If you had to use cgi for a task, would Fortran be your first choice?
If adapting a program already in Fortran, I probably would.
Most likely the CGI part would be relatively small compared
to the computational part.
(snip on graphics)
(snip)
>>There are some numerical libraries in C or C++ (two different
>>languages), but much more written in Fortran. Very little
>>in Java, still.
> I guess we wouldn't agree on this one unless we count all available
> numerical libraries in all those languages. I guess it differs between
> application, my experience shows exactly the opposite. MUCH MORE
> software of interest to me is written in C/C++ (btw, I know C is
> different from C++ :), but it so happens that one has a choice).
In a specific field, you might find more in C or C++.
That would be more true in fields dominated by computer
scientists, and less true for fields dominated by
physical scientists and engineers.
> Even
> the fastest BLAS and LAPACK implementations are written in C and/or
> assembler, which doesn't prevent calling it from Fortran. Well, again
> I don't have a lot of experience with legacy code.
(snip)
> Exactly. Why stick to a complicated compiled languages if you can get
> the work done many times faster with a scripting language? That's when
> I say there are more suitable tools.
In many cases the initial work is done in an interpreted
language such as matlab, R, or Mathematica. The production
versions are rewritten in a compiled language for speed,
and sometimes also to slow down reverse engineering.
>>Matlab and Mathematica are popular for a
>>wide variety of numerical problems. Do any of those
>>have an ISO or ANSI standard?
> Scripting languages typically have one reference implementation that
> is de facto a standard.
That would be nice, but it isn't true. There are always new
versions with new features, and changes to old features.
-- glen
Kevin G. Rhoads
>things I do not understand. One of them is why would people use
>Fortran for tasks for which there are plenty of much more suitable
>tools?
Are you assuming, perhaps, that YOUR definitions of "suitable"
apply to everyone?
I, for one, judge suitability based on how well I know
something. Were I a Pascal enthusiast, I would probably
use Pascal for a lot of things that I presently use Fortran
for -- that does not make Pascal or Fortran more or less
suitable in general -- just for me.
So, what are YOUR standards for suitability?
Kevin G. Rhoads
>than making subjective personal remarks about me.
OK.
What is/are your positions?
My positions include:
1) Fortran is still useful
2) Fortran is suitable for various things, not just numerics
3) C has things that make it prone to issues --pointers being
one example (I am not very interested in discussing this)
4) C++ and object-oriented things, in general, seem to have
potential issues which do not seem to be getting much attention
at present (I am only mildly interested in discussing this)
If any of these seem to be at odds with your present understandings
or positions, then let's discuss.
Sincerely
Kevin
Fly Away
> Fly Away wrote:
> > Task - text processing. Fortran doesn't have regular expressions. I
> > haven't seen any Fortran libraries that do that. This, of course,
> > doesn't mean they don't exist, but I haven't been able to find one.
>
> I've written support for them. The code belongs to a former
> employer, or I'd just post it. It's not hard. But - it's a library
> issue, not a language issue. Or do you think libraries are
> part of the language? That's *really* wierd.
Libraries are a huge part of the reason why one language would be
chosen over another.
> I've not
> recently found a Fortran from which I couldn't call such
> library routines if I needed them. (You would probably be
> surprised at how little value such things have for tasks such
> as compiler construction.
Not all of us write compilers. I just like the power of sed for
various things, but I don't always have it installed.
> > Task - file manipulation. Can you create a folder or copy a file in a
> > portable standard conforming way?
>
> Not in Fortran. Not in any language.
See "Scripting languages".
> The concept of "folder"
> (or "directory", "path", etc) is not portable. Some systems haven't
> got them. Some systems haven't got files at all.
The concept of "folder" and "file" is way too common now to ignore it.
How often does one write software in Fortran for such systems?
Even Fortran reads from and writes to files. That's why you code:
open(unit=100, FILE='file.txt')
> > Task - using basic well established algorithms like all kinds of
> > sorting. To make it portable you would either have to write your own
> > implementation, i.e. reinvent the wheel, or resort to a library most
> > likely written in another language that will probably impose licensing
> > restrictions.
>
> Never met a sorting algorithm I couldn't code *more* legibly in
> Fortran.
I consider coding something that's been implemented a million times
before me by a lot smarter people a waste of time. See "reinventing
the wheel". Besides, what are the chances my implementation could be
better, if not much worse?
> Many of the old, and still most used, were *invented*
> by Fortran programmers. (Maybe you are confused by the
> fact that most publications presented algorithms in Algol?
> I've seen places that didn't even *have* an Algol implementation,
> and they sent their new algorithms to press written in Algol.
> It's kind of like scientists until the 20th century: always publishing
> in Latin even though most didn't speak Latin or use it in their
> work.)
I am too young to know Algol...
>
> > Task - Web programming. I am not sure even how to approach this in
> > Fortran. I think generating web pages using the write statement would
> > be weird and unnatural. Accessing web services from Fortran... Or
> > writing one... How would you do that?
>
> I have no I idea what problem you're addressing. I use tools, not
> languages, to write web pages.
A language is a tool too.
> If you are
> not presented with choices, that fact doesn't demonstrate
> any weakness of the languages that you couldn't choose.
If I am presented with a choice I will have to know beforehand what
tool I have to use. I can't afford to find out the tool was not
suitable for the task post factum. It actually has happened to me...
> Implement Fortran support on web browsers, and we'll
> see that it is suitable.
What is "Fortran support on web browsers"?
> > Task - graphics. Third party libraries seem like the only option. Not
> > that it's different in many other languages, but there are lots more
> > options available outside the Fortran world. Especially in open-
> > source.
>
> Libraries (as mentioned above) are callable from Fortran no matter
> what language they're in.
I am not sure it is always the case. I'd say that Fortran is callable
from most languages.
>
> > [...] Yes, it is
> > complicated, some concepts are implemented better in other languages,
> > but yet I can't understand your complete denial of the strengths that
> > C ++ has. Calling C/C++ an enemy is just beyond my comprehension. It's
> > merely a tool. How can you get so emotional about it?
>
> You're the emotional one. I'm not particularly interested in C or
> C++ anymore because I no longer use them. When I suppored
> C compilers, I knew more about it than any three random users
> you would care to name. If I have a disrespect for the language,
> it's because I know it very well indeed.
You don't have to be _interested_ in a language to avoid cursing it.
> The real question, the the one that points to an emotional
> issue, is someone coming into a forum for users of a given
> language and telling them what they shouldn't be using the
> language for.
Not that it should matter for this particular discussion, but I've
been regularly reading this newsgroup for several years. I haven't
posted much though, because most of discussions were interesting to me
"read only". So it's not like I just accidentally found this thread
and decided to clash with the local folk.
Another point - I am not telling anyone what they should or shouldn't
use. I have an opinion, I express it. You respond. Noone has to make
decisions based on it. If I learn something useful I will consider it.
I am completely open for new knowledge. It's just that I prefer a more
peaceful discussions without personal references :)
> Especially telling people that *have* successfully
> written just such applications in Fortran. Many of whom know
> and have used dozens of languages and who chose Fortran
> because they found it *better* than the alternatives.
That's the key point. They know it better, not because it's superior
to all other languages.
> >>> And while we're at it, why do you believe
> >>> that application domain is even relevant to the issue of language
> >>> suitability?
>
> > I can't make sense of this question... Your wording often confuses me.
> > If you need to write an application you look for a suitable tool
> > (language). If you need to put a nail in the wall, you use a hummer,
> > not a microscope. So a hammer is more suitable for this kind of work
> > than a microscope. Is this relevant enough?
>
> Programming languages aren't hammers or microscopes. The analogy
> is so completely bogus that there's no value to glean from it at all.
Programming languages are tools. Microscopes and hammers are tools.
This analogy is as bogus as your original question.
> Programming languages are multiplex tools. Almost all of them have
> the same collection of capabilities. Fortran and C, for example, are
> practically isomorphic. The set of applications each is suited to is
> the *same* set. What distinguishes them is which makes code easier
> to write, read, verify, correct, extend, or maintain.
That's why some languages become popular and widely used and others
fade and become a small niche language no matter how perfect in theory
they are. ...I am not pointing fingers here.
> There have been objective experiments to measure the effect of
> language features on programmer productivity. (There haven't
> been enough of them, and since the results usually gore some
> important sacred cows they aren't widely reported. And people
> with vested interests to protect lobby against funding them.
So it's a conspiracy against Fortran, right?
Cheers,
Victor.
Fly Away
> >You can win (at least an argument with me) by actually arguing rather
> >than making subjective personal remarks about me.
>
> OK.
>
> What is/are your positions?
>
> My positions include:
> 1) Fortran is still useful
I would even omit the "still".
> 2) Fortran is suitable for various things, not just numerics
Suitable - yes. But whether it is more suitable than some other
language depends on the task in hand and various other reasons.
> 3) C has things that make it prone to issues --pointers being
> one example (I am not very interested in discussing this)
Every language has issues and limitations. As far as I can see,
numerous projects do not find those issues too critical to completely
avoid C (or any other language that has issues). Otherwise, I wouldn't
be writing this from Firefox installed in a Linux PC.
> 4) C++ and object-oriented things, in general, seem to have
> potential issues which do not seem to be getting much attention
> at present (I am only mildly interested in discussing this)
It's a trade-off. There are not perfect tools. If the strengths of it
overcome the weaknesses, and more importantly let one get the work
done better than in another language, why discard it? There are of
course questions like "who judges the language X isn't better", but
well, not much you can do about it. One weighs his options and goes
with the one he thinks is better.
Cheers,
Victor.
LR
>> You can win (at least an argument with me) by actually arguing rather
>> than making subjective personal remarks about me.
>
> OK.
>
> What is/are your positions?
>
> My positions include:
> 1) Fortran is still useful
> 2) Fortran is suitable for various things, not just numerics
Well, sorry, I mostly do C++ so I'll sneak in a C++ FAQ ;)
http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.5
> 3) C has things that make it prone to issues --pointers being
> one example (I am not very interested in discussing this)
> 4) C++ and object-oriented things, in general, seem to have
> potential issues which do not seem to be getting much attention
> at present (I am only mildly interested in discussing this)
I'm curious about what you mean about the OO stuff. If you mean
specifically C++ and OO have problems, as opposed to say COBOL and OO or
Fortran and OO then I'm less curious.
> If any of these seem to be at odds with your present understandings
> or positions, then let's discuss.
I'm not the person you were responding to, and also, I suspect some part
of this might be OT here. On that basis if you want to email me, feel free.
LR
James Giles
>> I've written support for them. The code belongs to a former
>> employer, or I'd just post it. It's not hard. But - it's a library
>> issue, not a language issue. Or do you think libraries are
>> part of the language? That's *really* wierd.
>
> Libraries are a huge part of the reason why one language would be
> chosen over another.
And which library is it that Fortran can't call? None? That's
what I thought too.
>> I've not
>> recently found a Fortran from which I couldn't call such
>> library routines if I needed them. (You would probably be
>> surprised at how little value such things have for tasks such
>> as compiler construction.
> Not all of us write compilers. I just like the power of sed for
> various things, but I don't always have it installed.
Sed is not something I would use Fortran to do. 99.99% of
all sed-like operations I do ar in a text editor. No language
involved at all. You can't oppose Fortran for things no one
recommends it for. That's silly.
>>> Task - file manipulation. Can you create a folder or copy a file in
>>> a portable standard conforming way?
>>
>> Not in Fortran. Not in any language.
> See "Scripting languages".
I've seen them. They aren't portable. The don't run at all on
systems that don't support the environment they assume. Were'nt
you the one that dismissed Fortran because it couldn't do things
portably?
Besides, no one uses Fortran as a scripting language. Again, you
can't criticize Fortran users (like you have repeatedly done) for
things that they aren't even doing.
>> The concept of "folder"
>> (or "directory", "path", etc) is not portable. Some systems haven't
>> got them. Some systems haven't got files at all.
> The concept of "folder" and "file" is way too common now to ignore it.
> How often does one write software in Fortran for such systems?
> Even Fortran reads from and writes to files. That's why you code:
> open(unit=100, FILE='file.txt')
And it's also why Fortran (and C, and C++, etc.) have explicit caveats
that the features involved aren't necessarily portable.
>> Never met a sorting algorithm I couldn't code *more* legibly in
>> Fortran.
> I consider coding something that's been implemented a million times
> before me by a lot smarter people a waste of time. See "reinventing
> the wheel". Besides, what are the chances my implementation could be
> better, if not much worse?
Which is also why I also use off the shelf components whenever
I can - and *from* Fortran, if that's the language I'm using. How
does this demonstrate and deficiency in Fortran?
...
>> I have no I idea what problem you're addressing. I use tools, not
>> languages, to write web pages.
>
> A language is a tool too.
It's a tool building tool, not a web page builting tool.
>> If you are
>> not presented with choices, that fact doesn't demonstrate
>> any weakness of the languages that you couldn't choose.
>
> If I am presented with a choice I will have to know beforehand what
> tool I have to use. I can't afford to find out the tool was not
> suitable for the task post factum. It actually has happened to me...
Wait a minute, you were the one that criticized Fortran users for
not moving to more modern things. Now you're recommending that
choices be disregarded that don't match your preconcieved notions?
And what do you do if *none* of the choices match you prior
experience? That happend a lot in computing.
>> You're the emotional one. I'm not particularly interested in C or
>> C++ anymore because I no longer use them. When I suppored
>> C compilers, I knew more about it than any three random users
>> you would care to name. If I have a disrespect for the language,
>> it's because I know it very well indeed.
>
> You don't have to be _interested_ in a language to avoid cursing it.
I don't have encyclopedic knowledge of the Harry Potter
universe: so what curse have I uttered? I have direct knowledge
of language design issues that I'm willing to share. C happens
to be a convenient counterexample to proper design principles
that I know sespecially well. I suppose other badly designed
languages would suit the purpose as well. I don't feel like
learning new bad languages just to have an additional counter-
example.
> Another point - I am not telling anyone what they should or shouldn't
> use. I have an opinion, I express it. You respond. Noone has to make
> decisions based on it. If I learn something useful I will consider it.
> I am completely open for new knowledge. It's just that I prefer a more
> peaceful discussions without personal references :)
Then you should adopt that attitude in your own articles.
>> Especially telling people that *have* successfully
>> written just such applications in Fortran. Many of whom know
>> and have used dozens of languages and who chose Fortran
>> because they found it *better* than the alternatives.
>
> That's the key point. They know it better, not because it's superior
> to all other languages.
What part of the preceeding paragraph didn't you read? I said
nothing about what language people knew better. In fact,
I said that many have used a large variety of languages. It
might be that I know C better that Fortran (I've certainly
spent more effort and time trying to interpret the standard).
I said that such people chose Fortran because they foud it
to be *better*, not because the found it more familiar. Many
people may do that too, but it's not valid to assume that
familiarity is the basis of their choice.
...
>> Programming languages are multiplex tools. Almost all of them have
>> the same collection of capabilities. Fortran and C, for example, are
>> practically isomorphic. The set of applications each is suited to is
>> the *same* set. What distinguishes them is which makes code easier
>> to write, read, verify, correct, extend, or maintain.
>
> That's why some languages become popular and widely used and others
> fade and become a small niche language no matter how perfect in theory
> they are. ...I am not pointing fingers here.
Popularity and quality are not in any way correlated in computing.
If you believe they are, you have to explain the popularity of
Windows.
>> There have been objective experiments to measure the effect of
>> language features on programmer productivity. (There haven't
>> been enough of them, and since the results usually gore some
>> important sacred cows they aren't widely reported. And people
>> with vested interests to protect lobby against funding them.
>
> So it's a conspiracy against Fortran, right?
So, *you're* the one that prefers "more peaceful discussions
without personal references". Sure. I think you may be the
guy trying to sell bridges in New York City we always hear
about. Sometimes you almost sound like you have serious
intent - then you resort to statements that almost justify
killfiling.
Make up your mind. Are you really interested in a discussion,
or are you really trolling. Stop pretending to both.
Fly Away
> Fly Away wrote:
>
> (snip)
>
> >>>Task - text processing. Fortran doesn't have regular expressions.
>
> (snip, I wrote)
>
> >>C doesn't have one, either, but there are some written in C.
> >>You can call them with C interoperability from Fortran.
> > Perl, Python, PHP etc. do. (I am not promoting C or any one single
> > _perfect_ language) Also, think of how much easier it is done in those
> > scripting languages.
>
> The perl, python, and PHP interpreters are written in
> C or C++, and call a C regexp package. The person porting
> the interpreter to your platform has to get it to work.
Fortran compilers are written in some other languages too. (At least
some of them are.)
>
> >>>Task - file manipulation. Can you create a folder or copy a file in a
> >>>portable standard conforming way?
> >>Standard C, C++, etc., also don't have that.
> > Perl, Python, PHP etc. do (see below about
>
> > scripting standarts). C++ has Boost.
>
> Same as above, except that all OS dependence is usually
> done with the C preprocessor to select the appropriate
> OS dependent code. Someone else went to a lot of
> work so that you don't have to.
That's exactly what I am looking for - less work to do. That's what
make one too "more suitable" than another.
> (snip on graphics)
> (snip)
>
> >>There are some numerical libraries in C or C++ (two different
> >>languages), but much more written in Fortran. Very little
> >>in Java, still.
> > I guess we wouldn't agree on this one unless we count all available
> > numerical libraries in all those languages. I guess it differs between
> > application, my experience shows exactly the opposite. MUCH MORE
> > software of interest to me is written in C/C++ (btw, I know C is
> > different from C++ :), but it so happens that one has a choice).
>
> In a specific field, you might find more in C or C++.
> That would be more true in fields dominated by computer
> scientists, and less true for fields dominated by
> physical scientists and engineers.
I am a computational physicist. I don't know exactly who writes the
libraries I was referring to, but I would guess they are some kind of
applied math/science guys, not pure computer scientists at all.
> > Even
> > the fastest BLAS and LAPACK implementations are written in C and/or
> > assembler, which doesn't prevent calling it from Fortran. Well, again
> > I don't have a lot of experience with legacy code.
>
> (snip)
>
> > Exactly. Why stick to a complicated compiled languages if you can get
> > the work done many times faster with a scripting language? That's when
> > I say there are more suitable tools.
>
> In many cases the initial work is done in an interpreted
> language such as matlab, R, or Mathematica. The production
> versions are rewritten in a compiled language for speed,
> and sometimes also to slow down reverse engineering.
All I am talking about is "some cases", not "all cases". In some cases
there is only "initial work". No production version is intended.
>
> >>Matlab and Mathematica are popular for a
> >>wide variety of numerical problems. Do any of those
> >>have an ISO or ANSI standard?
> > Scripting languages typically have one reference implementation that
> > is de facto a standard.
>
> That would be nice, but it isn't true. There are always new
> versions with new features, and changes to old features.
I personally haven't been hit by this problem. Major version changes
are not that frequent. Unless it's from an unusable version 1.0 to a
moderately acceptable version 2.0.
Victor.
Fly Away
> Fly Away wrote:
> > On Aug 22, 3:15 pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
> ...
> >> I've written support for them. The code belongs to a former
> >> employer, or I'd just post it. It's not hard. But - it's a library
> >> issue, not a language issue. Or do you think libraries are
> >> part of the language? That's *really* wierd.
>
> > Libraries are a huge part of the reason why one language would be
> > chosen over another.
>
> And which library is it that Fortran can't call? None? That's
> what I thought too.
know any and that means there are none?
> >> I've not
> >> recently found a Fortran from which I couldn't call such
> >> library routines if I needed them. (You would probably be
> >> surprised at how little value such things have for tasks such
> >> as compiler construction.
> > Not all of us write compilers. I just like the power of sed for
> > various things, but I don't always have it installed.
>
> Sed is not something I would use Fortran to do. 99.99% of
> all sed-like operations I do ar in a text editor. No language
> involved at all. You can't oppose Fortran for things no one
> recommends it for. That's silly.
I said "the power of sed", not sed itself. Speaking of silly, good
luck on doing, for example, search and replace on thousands of files
in a text editor.
>
> >>> Task - file manipulation. Can you create a folder or copy a file in
> >>> a portable standard conforming way?
>
> >> Not in Fortran. Not in any language.
> > See "Scripting languages".
>
> I've seen them. They aren't portable. The don't run at all on
> systems that don't support the environment they assume. Were'nt
> you the one that dismissed Fortran because it couldn't do things
> portably?
What mythical systems are you referring to? Refrigerators, hair-
dryers? Scripting languages are portable across systems - that's one
of their major advantages. They are no less portable than Fortran
these days.
> >> I have no I idea what problem you're addressing. I use tools, not
> >> languages, to write web pages.
>
> > A language is a tool too.
>
> It's a tool building tool, not a web page builting tool.
It is a tool. What you use it for is none of my concern. You can
generate web pages with it or you can generate other tools that
generate web pages. That's not what I was talking about.
>
> >> If you are
> >> not presented with choices, that fact doesn't demonstrate
> >> any weakness of the languages that you couldn't choose.
>
> > If I am presented with a choice I will have to know beforehand what
> > tool I have to use. I can't afford to find out the tool was not
> > suitable for the task post factum. It actually has happened to me...
>
> Wait a minute, you were the one that criticized Fortran users for
> not moving to more modern things. Now you're recommending that
> choices be disregarded that don't match your preconcieved notions?
First you learn something, then you apply it. No "pre-concieved
notions" involved.
> And what do you do if *none* of the choices match you prior
> experience?
Then you are not qualified for the job. It's that simple.
> That happend a lot in computing.
I don't believe it happens as often as you imply. One doesn't face an
extraordinary problem every single day.
> > You don't have to be _interested_ in a language to avoid cursing it.
>
> I don't have encyclopedic knowledge of the Harry Potter
> universe: so what curse have I uttered?
Avada kedavra. :)
> > Another point - I am not telling anyone what they should or shouldn't
> > use. I have an opinion, I express it. You respond. Noone has to make
> > decisions based on it. If I learn something useful I will consider it.
> > I am completely open for new knowledge. It's just that I prefer a more
> > peaceful discussions without personal references :)
>
> Then you should adopt that attitude in your own articles.
I am trying my best, but with you as an opponent it's a bit of a
challenge.
>
> >> Especially telling people that *have* successfully
> >> written just such applications in Fortran. Many of whom know
> >> and have used dozens of languages and who chose Fortran
> >> because they found it *better* than the alternatives.
>
> > That's the key point. They know it better, not because it's superior
> > to all other languages.
>
> What part of the preceeding paragraph didn't you read? I said
> nothing about what language people knew better.
My bad. I sometimes scan through text too fast. That's my "thing".
> ...
>
> >> Programming languages are multiplex tools. Almost all of them have
> >> the same collection of capabilities. Fortran and C, for example, are
> >> practically isomorphic. The set of applications each is suited to is
> >> the *same* set. What distinguishes them is which makes code easier
> >> to write, read, verify, correct, extend, or maintain.
>
> > That's why some languages become popular and widely used and others
> > fade and become a small niche language no matter how perfect in theory
> > they are. ...I am not pointing fingers here.
>
> Popularity and quality are not in any way correlated in computing.
> If you believe they are, you have to explain the popularity of
> Windows.
That's a long story and off-topic, but I don't think it was so
unreasonable. Nowadays it is, but historically I think it was
logical.
> >> There have been objective experiments to measure the effect of
> >> language features on programmer productivity. (There haven't
> >> been enough of them, and since the results usually gore some
> >> important sacred cows they aren't widely reported. And people
> >> with vested interests to protect lobby against funding them.
>
> > So it's a conspiracy against Fortran, right?
>
> So, *you're* the one that prefers "more peaceful discussions
> without personal references". Sure.
I think the popularity of computer languages is more or less
explainable without referring to lobbyists. That's my point.
> I think you may be the
> guy trying to sell bridges in New York City we always hear
> about.
I wish I lived in NYC. Maybe some day I will. I have a friend there,
maybe he is the guy?
> Sometimes you almost sound like you have serious
> intent - then you resort to statements that almost justify
> killfiling.
I always have serious intent. But some of your statements just tick me
off.
>
> Make up your mind. Are you really interested in a discussion,
> or are you really trolling. Stop pretending to both.
Let's just stick to serious discussion.
Cheers,
Victor.
James Giles
...
> I said "the power of sed", not sed itself. Speaking of silly, good
> luck on doing, for example, search and replace on thousands of files
> in a text editor.
It was one command in a text editor a friend of mine wrote.
The editor was written in Fortran. Benchmarked faster than
sed too.
> What mythical systems are you referring to? Refrigerators, hair-
> dryers? Scripting languages are portable across systems - that's one
> of their major advantages. They are no less portable than Fortran
> these days.
And no more. By your own hand, your previous statements
are disproven. If scripting languages are adequagtely portable
for your needs, then so are the features of Fortran.
> It is a tool. What you use it for is none of my concern. You can
> generate web pages with it or you can generate other tools that
> generate web pages. That's not what I was talking about.
And since you continue with vague inuendo and personal
attacks instead of specifics, we still don't really know what
you *are* talking about.
>>> [...]It's just
>>> that I prefer a more peaceful discussions without personal
>>> references :)
>>
>> Then you should adopt that attitude in your own articles.
> I am trying my best, but with you as an opponent it's a bit of a
> challenge.
I don't know why. You're the one that began (and continue)
with attacks on other people's competence.
> I think the popularity of computer languages is more or less
> explainable without referring to lobbyists. That's my point.
I don't. And see no evidence that popularity is correlated
to quality in any part of the computing industry - not just
languages, but systems, applications, etc. And I still regard
popularity as irrelevant to any discussion of language design
quality.
Kevin G. Rhoads
>> potential issues which do not seem to be getting much attention
>> at present (I am only mildly interested in discussing this)
>
>I'm curious about what you mean about the OO stuff. If you mean
>specifically C++ and OO have problems, as opposed to say COBOL and OO or
>Fortran and OO then I'm less curious.
AFAIK (and I'm no expert on OO stuff) all OO involves defining
new objects -- there are two issues I see as problematic with that.
1) to do OO right requires a lot of upfront work BEFORE coding,
most managers will not tolerate that, many coders can't either
2) defining new objects means that unless they are fully documented
the result is write-only code -- FORTH was criticised for this --
again, most managers will not tolerate time "wasted" in extensive
documentation and many coder have not the discipline
That's my set of worries re OO in any language in VERY BRIEF
terms.
As for OT --clf is rather forgiving of OT stuff and as Fortran
becomes more OO, OO issues are relevant (MHOO)
Sincerely
Kevin
LR
>>> 4) C++ and object-oriented things, in general, seem to have
>>> potential issues which do not seem to be getting much attention
>>> at present (I am only mildly interested in discussing this)
>> I'm curious about what you mean about the OO stuff. If you mean
>> specifically C++ and OO have problems, as opposed to say COBOL and OO or
>> Fortran and OO then I'm less curious.
>
> AFAIK (and I'm no expert on OO stuff)
I don't consider myself to be an expert either.
> all OO involves defining new objects --
Well, yes, but, would it be equally fair to say that, all structured
programming involves defining loops?
> there are two issues I see as problematic with that.
>
> 1) to do OO right requires a lot of upfront work BEFORE coding,
I'd say it does sometimes, don't some problems not using OO require
that? OTOH, it can be an iterative, one step at a time, thing. Frankly
I think some advocates of OO are way too interested in process and a
little too disinterested in results. (Please don't flame me.) I like
what OO can buy me.
Requires might be too strong a word. Encourages perhaps? Maybe
encourages you to think about how to write more effectively?
> most managers will not tolerate that, many coders can't either
In my limited experience thinking before coding can be a useful thing
and managers will tolerate it and even be happier for it. Programmers
too, IMO. But YMWV.
>
> 2) defining new objects means that unless they are fully documented
> the result is write-only code --
Why is this different compared to non OO code? Personally, I'd say it's
easier to write reasonable OO code than non OO code. And one of the
goals of OOP is to allow old code to behave in new ways with zero or
minimal changes.
But my experience with OOP is limited to one or two languages.
Also, I think it's possible to write bad code in any language.
> FORTH was criticised for this --
But not with OO, right? I don't think FORTH was OO. I think it may
have had some other problems. Not all languages are equally readable.
Although, this is probably subjective.
> again, most managers will not tolerate time "wasted" in extensive
> documentation and many coder have not the discipline
And no one will read it anyway and writing in English (or your favorite
human language) is hard.
But maybe extensive is the wrong thing to look for here. Brevity is the
soul of wit, might apply to documentation even more than prose. Maybe.
And shouldn't this be an incentive to all of us to write code that is
clearer even if it's not documented?
> That's my set of worries re OO in any language in VERY BRIEF
> terms.
Ok, thanks. I'm wondering if you've ever used an OO language (loosely
defined, since this seems to be a matter of some contention)? Or even
done OO without an OO language?
It took me a while to see how useful it could be.
> As for OT --clf is rather forgiving of OT stuff and as Fortran
> becomes more OO, OO issues are relevant (MHOO)
I'll try not to sneak in too many more C++ FAQs. ;)
LR
kron...@yahoo.co.uk
Pascal was dead when it was invented mate! By the admission of its
creator it was a "teaching language" and was never intended to be used
for something usefull. That much we can agree on.
K.D
kron...@yahoo.co.uk
1) Agree..for a limited and very small group of enthusiasts.
2) Sort of agree but it's a bit like saying that a fish could be used
as a baseball bat.
3) Totally agree and that's why C# was invented by MS.
4) OO langauages are the only way to go. That much I have learned in
the last 5 years or so.
K.D
James Giles
...
> Ok, thanks. I'm wondering if you've ever used an OO language (loosely
> defined, since this seems to be a matter of some contention)? Or even
> done OO without an OO language?
I haven't been contributing in this subthread, but it seems to
me the major problems with OO are due to that part of it
that OO promoters are trying to distance themselves from:
inheritance. There's little evidence to support the claim that
inheritance increases productivity. I think it's inherently
counterproductive.
Of course, what's left of OO if inheritance is not considered
doesn't seem significant. I can't find an adequate definition
of OO that presents any basis for clear discussion.
It is interesting that lots of the interest in Fortran "OO" features
concentrates on CLASS(*) - which explicitly disregards inheritance.
And it's not clear that it really has much to do with OO at all.
LR
> LR wrote:
> ...
>> Ok, thanks. I'm wondering if you've ever used an OO language (loosely
>> defined, since this seems to be a matter of some contention)? Or even
>> done OO without an OO language?
>
> I haven't been contributing in this subthread, but it seems to
> me the major problems with OO are due to that part of it
> that OO promoters are trying to distance themselves from:
> inheritance.
Sorry, but I'm not sure that I've heard about this. It seems to me that
inheritance is pretty important to OO. Not that OO can't be useful
without it.
> There's little evidence to support the claim that
> inheritance increases productivity. I think it's inherently
> counterproductive.
My personal experience has been otherwise. But I don't have objective
evidence for this, ie I didn't measure my experience. Of course, like
most other things it can be abused, but it can be very useful. Why do
you think inheritance is inherently counterproductive?
> Of course, what's left of OO if inheritance is not considered
> doesn't seem significant.
I'm not sure about that. Encapsulation and methods (member functions)
would seem to be useful even without inheritance. But better with
inheritance IMO.
> I can't find an adequate definition
> of OO that presents any basis for clear discussion.
I sometimes think that a major problem with OO is that it seems like a
collection of dizzying jargon in search of a solution.
Hopefully that'll calm down a bit with time.
But it seems like many OO advocates want to dump people into the deep
end. The full immersion method. I think it's better to dip a toe in
and see what its like first.
But I don't think you're wrong. I think the definitions I've seen are a
little fuzzy too. Perhaps because the technology is still developing.
I guess also, from my perspective, a definition is useful, but it's a
little like trying to appreciate music from a definition of it. Not a
perfect analogy.
> It is interesting that lots of the interest in Fortran "OO" features
> concentrates on CLASS(*) - which explicitly disregards inheritance.
> And it's not clear that it really has much to do with OO at all.
I'm not familiar with Fortran's OO model. But inheritance isn't the
only way to accomplish the same trick. Java has interface to get around
its lack of (Java advocates might say avoid the problems with) multiple
inheritance.
I don't think the point is the mechanism you use to get to polymorphism,
so long as you get there.
Does Fortran support inheritance or interface?
LR
Richard Maine
> I sometimes think that a major problem with OO is that it seems like a
> collection of dizzying jargon in search of a solution.
Indeed. It took a long time before I saw a presentation that finally
clicked for me and helped me understand at least some of what was going
on, but had formerly been lost to me in the maze of terminology. Once it
clicked, I realized I had been doing some of that for ages, but I hadn't
known that what I was already doing counted as OO. I also hadn't
realized that compilers could actually help me do it instead of get in
the way.
> But it seems like many OO advocates want to dump people into the deep
> end. The full immersion method. I think it's better to dip a toe in
> and see what its like first.
Agree 100%. More than that if possible. It can be a useful tool, but
those who think it is the solution to all of the world's problems are...
well... let's just say that I disagree with them.
This was reflected in the OO stuff added to f2003. There were people who
wanted to pretty much tear the language apart and redo it as an OO
language, with everything centered around that. That approach didn't fly
at all (thankfully; I thihk it would have been a big mistake).
Instead, some OO features were added where they seemed to fit into and
complement the existing language. Of course, people can (and probably
will) debate whether that was well done, but that was definitely the
idea. I might say it was your toe dip instead of a full immersion.
> Does Fortran support inheritance or interface?
Inheritance, yes. I don't know what you mean by interface - probably an
OO term that I don't know. Fortran has something called an interface,
but it dates from f90 and isn't normally considered an OO feature. I
doubt that is what you are talking about, though I suppose it is
possible. Fortran's interface isn't normally called an OO feature, but
if I back off far enough, I can see a relationship, so maybe that is it.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
LR
> LR <lr...@superlink.net> wrote:
>
>> I sometimes think that a major problem with OO is that it seems like a
>> collection of dizzying jargon in search of a solution.
>
> Indeed. It took a long time before I saw a presentation that finally
> clicked for me and helped me understand at least some of what was going
> on, but had formerly been lost to me in the maze of terminology. Once it
> clicked, I realized I had been doing some of that for ages, but I hadn't
> known that what I was already doing counted as OO. I also hadn't
> realized that compilers could actually help me do it instead of get in
> the way.
I had a similar experience. I understand that lots of programmers once
they get through the communication problems have a similar reaction,
something along the lines of, Oh. Yes. That's right.
I've never been able to figure out why it seems to get explained in such
an incomprehensible way, perhaps a misplaced desire for formalism.
>> But it seems like many OO advocates want to dump people into the deep
>> end. The full immersion method. I think it's better to dip a toe in
>> and see what its like first.
>
> Agree 100%. More than that if possible. It can be a useful tool, but
> those who think it is the solution to all of the world's problems are...
> well... let's just say that I disagree with them.
I sometimes get the feeling that some people forget that it's supposed
to help you reach an end, it's isn't the end itself.
>
> This was reflected in the OO stuff added to f2003. There were people who
> wanted to pretty much tear the language apart and redo it as an OO
> language, with everything centered around that. That approach didn't fly
> at all (thankfully; I thihk it would have been a big mistake).
I agree. I think this is similar to the evolution of C++. Build on
what came before. Although Fortran has a longer tradition of this. Also,
it lets the language users decide for themselves how much OO they want
to do, and maybe even more importantly, doesn't leave them stranded.
> Instead, some OO features were added where they seemed to fit into and
> complement the existing language. Of course, people can (and probably
> will) debate whether that was well done, but that was definitely the
> idea. I might say it was your toe dip instead of a full immersion.
I suspect with experience the toe dip will turn into wading in the
shallow end.
>> Does Fortran support inheritance or interface?
>
> Inheritance, yes. I don't know what you mean by interface - probably an
> OO term that I don't know. Fortran has something called an interface,
> but it dates from f90 and isn't normally considered an OO feature. I
> doubt that is what you are talking about, though I suppose it is
> possible. Fortran's interface isn't normally called an OO feature, but
> if I back off far enough, I can see a relationship, so maybe that is it.
The term as I was using it is a Java thing and I'm no Java programmer so
I would hesitate to explain it in detail. I did a quick search and found
this, http://pclc.pace.edu/~bergin/patterns/multipleinheritance.html
If I may I'll rephrase and extend part of my question, does Fortran
support multiple inheritance? Or Java inheritance? Perhaps some other
way of accomplishing this?
LR
Richard Maine
> If I may I'll rephrase and extend part of my question, does Fortran
> support multiple inheritance? Or Java inheritance? Perhaps some other
> way of accomplishing this?
No, it doesn't support multiple inheritance. That was advocated by some
people, but was pretty strongly objected to by others (and a majority).
I won't try to present the details of the arguments as I'm not well
schooled in them. But my understanding is that the general tennor of the
argument was that multiple inheritance added excessive complications and
had little benefit, at least compared to the cost. I believe that the
general argument was that the purpose could better be achieved, at least
in Fortran, by what I think is known as embedding. Anyway, I've been
able to see how I would do some of the oft-mentioned things.
That is, for example, suppose you have a type my_type that is in some
inheritance tree and you want to make a linked list (or any other such
structure) of objects of type my_type. My understanding is that a
multiple inheritance approach would be to make my_type additionally
inherit from list_type (or whatever it is that you defined the lists
with). Instead, you make a type my_list_type that inherits from
list_type and has a single additional component of type my_type.
I don't know whether that's sufficient explanation. I certainly wouldn't
have understood it myself several years ago, but I'm assuming from
context that you know a lot of the terminology (likely better than I
do). I "decent" job of presenting it would take a bit more time than I
want to put into this posting right now.
I don't do Java, so I don't know what Java inheritance would be.
fj
I like JAVA interfaces : JAVA, like FORTRAN 2003, implements only
single inheritance but has another useful feature (interface) which
allows programmers to declare that a given object type must respect a
(or several) particular behavior (calles interface). A JAVA interface
is a king a abstract type which is associated to a list of routine
signatures.
And it is possible to build up an array of objects implementing a
particular abstract type. These objects have any type but they
implement all the same kind of routines.
From my point of view, this simple feature would have been more useful
than inheritance.
Richard Harter
<james...@worldnet.att.net> wrote:
[snip]
>I don't have encyclopedic knowledge of the Harry Potter
>universe: so what curse have I uttered? I have direct knowledge
>of language design issues that I'm willing to share. C happens
>to be a convenient counterexample to proper design principles
>that I know sespecially well. I suppose other badly designed
>languages would suit the purpose as well. I don't feel like
>learning new bad languages just to have an additional counter-
>example.
[snip]
Is there any chance that you might list some of these design
principles where C made the wrong choice and fortran made the
right choice? This bystander would like to have his mind
illuminated.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
J. F. Cornwall
> On Aug 22, 1:34 am, "J. F. Cornwall" <JCornw...@cox.net> wrote:
>
>>Luka Djigas wrote:
>>
>>>On Wed, 20 Aug 2008 10:53:48 -0500, Gary Scott
>>><garylsc...@sbcglobal.net> wrote:
>>
>>>>This is not even close to actual usage of Fortran. It was widely used
>>>>as the main systems programming language in addition to assembly on many
>>>>computing systems of the past.
>>
>>>Please, elaborate. What do you mean under "main systesm programming
>>>language" ?
>>
>>The main language used for all sorts of applications, as well as many
>>utilities used by the OS, or as a suite of tools and library routines
>>provided by the OS for use by applications. That's what *we* used the
>>term for, at any rate (USAF weather computing facility).
>>
>>The applications written in Fortran included number-crunching forecast
>>models, homegrown database systems, real-time communications
>>(HyperChannel between the mainframes, and assorted external comm line
>>links to outside systems), and a few other smaller programs for
>>maintaining routing libraries and so on. There were numerous libraries
>>of useful routines mostly written in Fortran, some in assembler, and
>>even a little bit of C.
>>
>>And, in my current job, we use Fortran and a bit of C to run a water
>>database with real-time data input from satellite, an entire suite of
>>applications, and human interface programs - almost all of which is in
>>Fortran. We use C where it's needed, but I'd say over 95% of the code
>>is Fortran. Embedded dynamic SQL (Ingres RDBMS), number-crunching
>>(mainly for statistics), human interface handling, the whole range of
>>things a general purpose language should cover...
>>
>>Jim
>>
>>
>>
>>
>>>Best regards
>>>Luka
>
>
> What sort of GUI do you have? Or is it only numbers you have as an
> output?
>
> K.
Who the hell needs a GUI? We do just fine with Unix xterm display
windows and a character-based interface. Not every program needs to be
graphical to be successful...
Jim
Gary Scott
:) well they do in my environment...but it's extremely easy to add one,
even a fully featured one with some of the gui builders available.
>
> Jim
--
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
Jan Vorbrüggen
>>> you write hardware drivers in Fortran? I don't think so. Will you
>>> write network applications Fortran? I don't think so. Will you write
>>> text processing software in Fortran? I don't think so. Will you write
>>> a GUI library in Fortran? I don't think so. This is just a few
>>> examples. Is it possible to do all those things in Fortran?
>> But all these things ARE done, in Fortran, and quite well.
>
> Should I hope some examples will follow?
The first implementations of GKS.
Loads of software controlling data acquisition via CAMAC et seq.
Network applications? Too numerous to recollect details.
The IBM F77 compiler was written in itself.
Device drivers are a special case - the OSes until perhaps the early
nineties didn't provide suitable functionality to abstract the hardware
quirks to make this productive in anything but assembler, BLISS or,
later, C. With something as the current Windows DDK based on its HAL, it
should no longer matter what language you use - but I suspect all of
those who know current hardware enough to write a driver for it have
been raised on C, and know no other (or better).
Jan