Fortran Myths & Disinformation Wanted
Craig T. Dedo
I am developing a list of popular myths and disinformation about the Fortran
programming language that are widely circulated in the programming community.
All of the following are beliefs I have heard personally. So far, I have
these:
1. Fortran is 3 way IF statements and one-trip DO loops.
2. Fortran encourages unstructured code and spaghetti-style control flow.
3. Fortran can't do Windows.
4. Fortran is unportable. If you really want portability, you should write
your program in C.
5. Fortran is only for scientific and engineering applications.
6. The only real fortran is FORTRAN 77 (or, FORTRAN 66).
7. Fortran can't call system routines.
8. You can't do character string operations easily in Fortran.
9. Only Microsoft makes a PC-based Fortran compiler of any importance.
10. Fortran is a dead language. No one uses it any more to write important
applications.
I would like to expand the list as much as possible. What other myths have
you heard? Please send them to me and/or post them on comp.lang.fortran.
--
----------
Sincerely,
Craig T. Dedo Internet: Craig...@mixcom.com
Elmbrook Computer Services Voice Phone: (414) 783-5869
17130 W. Burleigh Place Fax Phone: (414) 783-5928
Brookfield, WI 53005 Disclaimer: These opinions are mine alone.
USA They do NOT represent any organization.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin (1759)
Jos Bergervoet
>Dear Readers:
> I am developing a list of popular myths and disinformation about the Fortran
>programming language that are widely circulated in the programming community.
> [.. skipping impressive list ..]
> I would like to expand the list as much as possible. What other myths have
>you heard? Please send them to me and/or post them on comp.lang.fortran.
There was an "humoristic" article some years ago, titled:
Real programmers don't use Pascal
The real programmers in that story used FORTRAN and did a lot of things
which may not yet be on your list. See:
http://www.offspin.demon.co.uk/funny/realprog.html
-- Jos
REAL PROGRAMMERS DON'T USE PASCAL
Back in the good old days-- the "Golden Era" of computers-- it
was easy to separate the men from the boys (sometimes called "Real
Men" and "Quiche Eaters" in the literature). During this period, the
Real Men were the ones who understood computer programming, and the
Quiche Eaters were the ones who didn't. A real computer programmer
said things like "DO 10 I=1,10" and "ABEND" (they actually talked in
capital letters, you understand), and the rest of the world said ...
James Giles
Craig T. Dedo wrote in message <36B9B8FF...@mixcom.com>...
>Dear Readers:
> I am developing a list of popular myths and disinformation about the Fortran
>programming language that are widely circulated in the programming community.
>these:
> 1. Fortran is 3 way IF statements and one-trip DO loops.
> 2. Fortran encourages unstructured code and spaghetti-style control flow.
> 3. Fortran can't do Windows.
> 4. Fortran is unportable. If you really want portability, you should write
>your program in C.
> 5. Fortran is only for scientific and engineering applications.
> 6. The only real fortran is FORTRAN 77 (or, FORTRAN 66).
> 7. Fortran can't call system routines.
> 8. You can't do character string operations easily in Fortran.
> 9. Only Microsoft makes a PC-based Fortran compiler of any importance.
> 10. Fortran is a dead language. No one uses it any more to write important
>applications.
I have been preparing such a list, with responses, but it's large and
I haven't finished it. My list is called ECPK (Every C Progammer Knows).
You left out a few (and here are some of my responses to some of those
you mention). There are more (that I just haven't got to). Maybe someone
else will fill-in where I've omitted.
------------------------------------------------------------------
ECPK that a major Venus probe (or some spacecraft) blew up because
of a Fortran DO I=1.4 style error.
Not true. A space probe was lost because of a single character error.
But it was an error in transcribing a formula. Fortran wasn't involved
(or even used). Most other programming languages have contexts which
allow single character errors as well. C has many. The Fortran one
expressed here is unlikely since most loops vary from 1 to a variable!
ECPK (Every C Programmer Knows) that Fortran programs can only use
uppercase.
Well, this has not been true for many years. Prior to F90, the standard only
mentioned one case, but as a practical matter most implementations have
allowed both upper- and lowercase whenever both were available on
the hardware/system the compiler was resident on.
Fortran does have the specific advantage that its implementations are not
case sensitive. Even before F90 (which specifically says that case is not
significant if both cases are allowed), no Fortran I'm aware of made was
case sensitive. (G77 now has an compiler option to allow case-sensitivity.)
Case sensitive languages are generally more error prone. And, in
the old days, many systems didn't have character sets that included both
cases. I never saw a C implementation on the old CDC 60-bit machines,
possibly because its 6-bit character set didn't have both cases. Most
Fortran programs could be moved to such systems with little difficulty.
ECPK that Fortran statements must begin in column seven. Not before
and not after.
This has never been true. You could always indent beyond column
seven if you chose. I have worked in places where we weren't allowed
to do so. On one Air Force contract, the captain decided that no
extraneous spaces, blank lines, empty comments, or anything else
were to be allowed. We also had to declare variables in alphabetical
order - regardless of their mutual dependencies - and line up declarations
in columns. All these rules were intended to make everyone's style
consistent and increase legibility of "other people's code". The fact
that all the rules were actually the worst decisions you could make
didn't seem to phase him. This is not a valid reason to criticize the
language, this guy would probably have done the same thing in any
programming language.
A related problem (that really is a language defect) that C programmers
*don't* usually know is that Fortran (77 and before) silently ignores
everything after column 71. This was fine when everyone used keypunches
that could be set to automatically skip to the next card at that point. But
with the advent of glass terminals and text editors is was a constant source
of subtle errors. Now why is it that C programmers are never really aware
of the *real* defects of Fortran?
ECPK that Fortran's variables are limited to, at most, six characters.
This is true as far as it goes. Of course, F90 allows variables, externals,
essentially all names to be 31 characters in length (and permits underscores).
Prior to F90, many implementations allowed more than six characters: most
allowed eight, some allowed more than that. This made your code less
portable (you'd have to systematically change all your long variables to
shorter names). But, people used to expect rather more difficult work
to port their codes than just renaming a few variables anyway. Anyone
writing a code for a Cray (in those days) expected that it would probably
never run on any other machine - too many machine specific features.
This is not to defend short variable name limits - it should have been
changed in F77 - but it's not as bad as all that. Especially considering:
At the same time Fortran's standard limited variables to six characters,
C had no standard yet at all and K&R (first edition) was considered the
authority. Yet, K&R stated that only the first eight characters of an
identifier were significant - even though identifiers of any length were
allowed! This is an appallingly bad language design. Identifiers that
were intended to be different, but which were the same in the first
eight characters were silently treated as the same. Identifiers for
external symbols were usually significant to fewer than eight characters
(often six, since the linkers were designed for Fortran). This was much
worse than the enforced Fortran limit because it wasn't enforced. It was
not eliminated until the C standard (which was about the same time as f90).
ECPK that you can't write structured programs in Fortran.
This and the next two points are strongly related. Indeed, this comes
in several dozen guises, so just three is already a simplification.
Structured Programming was a phrase first popularized by E. W. Dijkstra
(and others) in the late 60's and early 70's. It referred to a style of writing
programs that most now generally call "iterative refinement". This is a
technique that can be applied to any program and any programming
language. Perhaps the most widely read introduction to this concept
is the book "Structured Programming" [1].
I have had at least one C++ fanatic claim that iterative refinement was now
obsolete and that object oriented design principles have superceeded it.
This is not correct. Iterative refinement is the basic underlying principle
of object oriented design. Indeed, the first widespread introduction most
people had to Simula (the first OOP) was in the book "Structured Programming"
mentioned above. In fact, if you know how it's done internally, you can
do object oriented programming in any language (if you couldn't, it would
be impossible to compile it to machine-code on non-OO hardware). What
an OOP language does is make several of the activities considerably easier.
Perhaps because Dijkstra was the principal proponent of structured programming
and also was among the earliest to comment on the negative effects of GOTOs [2],
the phrase "structured programming" has acquired the incorrect definition of
"GOTO-less programming". This leads to the following point.
ECPK that using GOTOs is an inherently bad thing that automatically
makes spaghetti out of your program.
In his article [3], Knuth addresses this issue point-blank. It isn't specifically
a Fortran vs. C issue, but it often arises in that context. I think that [2] and
[3] are the only references to the GOTO-less programming debate anyone
should ever have to read. They pretty much say it all, except:
In terms of programmer productivity, GOTOs are not *inherently* bad.
They can be abused quite easily, and that's the real problem. But, there
are things known from direct experiments which are worse. The "Hare"
experiments in the 70's and related studies demonstrated that judicious
use of GOTOs was actually better for programmer productivity than
block structured languages using "begin..end" scoping rules for grouping
statements for control. See articles [4], [5], [6], and [7].
The "Hare" experiments deserve to be famous (or infamous), but are instead
known only by a few. The old-guard language design elite preferred the "elegant"
solution of making begin - end tokens make a sequence of statements into a single
one (syntactically) and then having control constructs only apply to single statements.
The "Hare" experiments (and other papers and studies) demonstrated this was
not a good idea. Hence the relatively unknown status of the work (the "gurus"
didn't like the result).
The authors of the "Hare" experiments clearly preferred the begin-end design
themselves and repeatedly concluded that it was simpler psychologically
than GOTOs (as you will see if you read the referenced articles). Still, some
of the evidence tells against begin-end style. In [1], the test subjects in the
second study made about 1.5 times as many errors (92 vs. 60, combining
both syntax and logic errors) using Begin-end style vs. the users of a GOTO
(JUMP) mechanism. Further, the errors were more persistent (1.5 times as
long to correct them) using Begin-end style vs. GOTOs.
Why were the users of Begin-end style less successful than the users of GOTOs
in these simple tests? Because the 'begin' and 'end' are anonymous - any 'begin'
can match any 'end' and it's not hard to lose track is a deeply nested program.
GOTOs are the reverse, each one names the unique label to which it refers.
Each label does not (necessarily) correspond to a unique GOTO, but you've
at least got the specific identification one-way.
The third mechanism tried in the "Hare" experiments was a nested, block
structured syntax in which the statements were *not* delimited by the
anonymous begin-end pairs, but were clearly identified. This mechanism
was so clearly superior to either begin-end style constructs or GOTOs
no language designed from scratch since then has used begin-end syntax.
Several have been designed to be backward compatible to other begin-end
style languages though.
C is worse than even most other begin-end style languages in that it spells
the delimiters with the slight "visibility challenging" characters {and}. This
further aggravates the anonymity problem with legibility problems. F90
uses a variant on the other block nesting mechanism, DOs end with END DOs
and never with END IFs; etc.. And F90 permits blocks to be named in
order to further remove anonymity from the delimiters. (See, I did manage
to make this directly relevant to C vs. Fortran.)
ECPK that Fortran forces you to use GOTOs all the time.
This is a fair characterization of F66. You could do counted iterations
without GOTOs (you still needed a label) with the DO statement, but
other than that you needed GOTOs. It's not quite as fair with respect
to F77. At least F77 has block IFs. Still, to do CASE or WHILE
constructs you need a GOTOs. It is certainly not a fair characterization
of F90 or beyond. Even so, I heard people claim that Fortran had no
block IF as recently as 1993! That's hardly a well researched position
to take.
ECPK that Fortran has no character manipulation capabilities.
Since Fortran 77, Fortran has had better capabilities in this respect
than C. It has, built into the language, the ability to extract substrings
and concatenate. The whole standard C collection of character
manipulation functions can be duplicated in Fortran (those that aren't
already present) in an afternoon. Fortran is actually a pretty good
language for text manipulation.
----------------------------------------------------------------------------------
[1] Structured Programming; Dijkstra, Dahl, and Hoare; Academic Press, 1972.
[2] GOTO Statement Considered Harmful; Dijkstra; Communications of the
ACM; March 1968; pp. 147-148. (widely reprinted)
[3] Structured Programming with GOTO Statements; Knuth; Computing Surveys;
December 1974; pp. 261-301. (widely reprinted)
[4] Jumping to Some Purpose; Arblaster, Sime, Green; The Computer Journal;
Vol. 22, No. 2, pp. 105-109.
[5] Scope Marking in Computer conditionals - a Psychological Evaluation; Arblaster,
Green, Guest; Int. Journal of Man-Machine Studies (1977) 9, 107-118.
[6] "GOTO Considered Harmful" Considered Harmful; Communications of the ACM;
March 1987, pp. 195-196. (Also see letters to Communications for the rest
of that year for rebuttals and/or agreements.)
[7] Modern Coding Practices and Programmer Performance; Sheppard, Curtis, Millman,
and Love; IEEE Computer, December 1979; pp. 41-49.
Dan Nagle
Craig T. Dedo wrote:
>
<snip intro>
> 1. Fortran is 3 way IF statements and one-trip DO loops.
Fortran is full of subtle traps for the unsuspecting programmer.
C has rarely used features known only by Very Good Programmers.
> 2. Fortran encourages unstructured code and spaghetti-style
> control flow.
Fortran programs written before modern coding techniques were
discovered, written by non-programmers and still in use is proof
of Fortran's inferiority.
The lack of pointers means Fortran can't have "interesting" data
structures. The C-pointer adds flexibility, never complexity.
> 3. Fortran can't do Windows.
Unix will soon go the way of MVS. Linux doesn't exist. WinNT is
the only way to network PC's.
> 4. Fortran is unportable. If you really want portability,
> you should write your program in C.
C is the most efficient language because it's closest to the hardware.
There are no preprocessors for Fortran, because cpp mangles
fixed format Fortran source code.
> 5. Fortran is only for scientific and engineering
> applications.
There are no jobs in science and engineering. Besides, coding
yet another GUI for yet another database so yet another dry cleaner
can operate at _maximum_ efficiency is more of a challenge.
Floating point isn't an interesting datatype. That's why the C.S. dept.
has moved _far_ beyond it to really neat things, such as linked lists,
B-trees, etc.
> 6. The only real fortran is FORTRAN 77 (or, FORTRAN 66).
The concepts of depreciated, obsolescent and deleted features
only _prove_ that Fortran is an ancient language. C, of course,
is completely backward compatible for maximum portability. Unlike
the Fortran standards committee, the C standards committee has
never made a mistake.
The only global data mechanism in Fortran is the unreliable
COMMON block. C's file scope rules together with include files
make for a much easier to understand scope system, especially
if the programmer remembers to use an #ifdef to check to see
if the include file has already been include'd.
> 7. Fortran can't call system routines.
Fortran has no graphics libraries, no message passing libraries, etc.
There are no programing utilities to help a Fortran programmer.
Netlib doesn't exist since it didn't come from Micro$oft.
> 8. You can't do character string operations easily in
> Fortran.
Library calls are easier to code and easier to read than inline code.
The C++ class browser in the IDE means you'll always understand the
string classes of the current project.
> 9. Only Microsoft makes a PC-based Fortran compiler of any
> importance.
There are no good development environments for Fortran. Most Fortran
compilers don't even come with an editor, and you have to use the C
debugger which doesn't understand COMMON.
> 10. Fortran is a dead language. No one uses it any more to
> write important applications.
Now that vector processors are dying out, Fortran will go with them.
Blocking for cache re-use is nothing like vectorization. Besides,
C's closeness to the hardware makes blocking in C far easier,
especially with multi-level caches.
That's why the binding for OpenMP for Fortran came out a year
before the binding for C.
C++ classes represent "reusable" software. A library written in 1967
and in use continually since then is no proof of reusability, nor
reliability.
>
> I would like to expand the list as much as possible. What
> other myths have
> you heard? Please send them to me and/or post them on
> comp.lang.fortran.
Done herewith.
Of course, rereading MAD MAgazine's _Snappy Answers to Stupid
Questions_ helps put one in the proper mindset ;-)
<snip sig>
--
Cheers!
Dan Nagle dna...@erols.com
Toon Moene
> I am developing a list of popular myths and disinformation about the Fortran
> programming language that are widely circulated in the programming community.
> All of the following are beliefs I have heard personally. So far, I have
> these:
> 1. Fortran is 3 way IF statements and one-trip DO loops.
> 2. Fortran encourages unstructured code and spaghetti-style control flow.
> 3. Fortran can't do Windows.
> 4. Fortran is unportable. If you really want portability, you should write
> your program in C.
> 5. Fortran is only for scientific and engineering applications.
> 6. The only real fortran is FORTRAN 77 (or, FORTRAN 66).
> 7. Fortran can't call system routines.
> 8. You can't do character string operations easily in Fortran.
> 9. Only Microsoft makes a PC-based Fortran compiler of any importance.
> 10. Fortran is a dead language. No one uses it any more to write important
> applications.
>
> I would like to expand the list as much as possible. What other myths have
> you heard?
11. You can't write operating systems in Fortran.
12. You can't write games in Fortran.
13. You can't write graphics programs in Fortran.
14. You can't write compilers in Fortran (Oh, well - Craig really didn't
try very hard ...)
--
Toon Moene (to...@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: for...@gnu.org; egcs: egcs...@cygnus.com
Martin Ambuhl
>
> Dear Readers:
> I am developing a list of popular myths and disinformation about the Fortran
> programming language that are widely circulated in the programming community.
> All of the following are beliefs I have heard personally. So far, I have
> these:
> 1. Fortran is 3 way IF statements and one-trip DO loops.
> 2. Fortran encourages unstructured code and spaghetti-style control flow.
> 3. Fortran can't do Windows.
> 4. Fortran is unportable. If you really want portability, you should write
> your program in C.
> 5. Fortran is only for scientific and engineering applications.
> 6. The only real fortran is FORTRAN 77 (or, FORTRAN 66).
> 7. Fortran can't call system routines.
> 8. You can't do character string operations easily in Fortran.
> 9. Only Microsoft makes a PC-based Fortran compiler of any importance.
> 10. Fortran is a dead language. No one uses it any more to write important
> applications.
>
> I would like to expand the list as much as possible. What other myths have
You are emphasizing expansion at the expense of truth. In particular,
over a history of 35 years of programming I have never heard #1, #3, #4,
#5, #6, #7, or #9. #2 and #8 reflect a reality about much legacy
Fortran code and are probably widely believed. If someone asserted #10,
I would be suspicious of his general computing knowlege.
You should also know that COBOL suffers much more than Fortran in this
respect. I suspect that the Fortran community is replete with people
who make ugly noises about COBOL that are more misinformed than any of
the items you list for Fortran. The analog to #10 is frequently found,
even though the code-base for COBOL outstrips any other language.
I also know that frequently anti-C postings are made in comp.lang.c
which demonstrate that the version of C the posters know is about 1972,
certainly before the 1989 standard. If Fortran partisans can insist
that C is still at pre-standard 1972 levels, then surely they have no
room to squeal if others think Fortran ossified to F77 or F66.
--
Martin Ambuhl (mam...@earthlink.net)
Note: mam...@tiac.net will soon be inactive
Ron Shepard
<Craig...@mixcom.com> wrote:
>Dear Readers:
> I am developing a list of popular myths and disinformation about
the Fortran
>programming language that are widely circulated in the programming community.
[...]
Fortran arrays always start at 1, instead of 0, which would be more useful.
Fortran multi-D arrays are referenced backwards; it makes more sense for
the last index to vary the fastest. Also, multi-D arrays are never used
in real applications, so the language doesn't need them anyway.
It is legal to reference "array(n)" in an array that has been declared
"dimension array(n)"; the "n-1" element should be the last element.
You must use upper case in fortran, otherwise it is nonstandard (and
therefore nonportable too). Also, it should be spelled FORTRAN.
Fortran does not have a "select case" statement, so it is impossible to
write structured code. [same argument for if-then-else, do-while,
exit-cycle, etc.]
Fortran I/O does not allow access to unstructured byte streams, so it is
impossible to write portable programs.
Fortran does not support bit operations, so it is impossible to write
portable code.
Fortran compilers are invoked with different commands, so it is impossible
to write portable makefiles.
Fortran compilers are always written in C or Pascal, therefore these other
languages must be better.
Integer division "i/j" in fortran, especially involving negative operands,
always rounds toward zero; for increased efficiency, it would be better to
let the processor decide which way to round, as in done in C/C++.
Array operations, such as A+B, A-B, A*B, A/B, etc., are redundant.
Besides, it is always more efficient to code these operations as explicit
loops.
$.02 -Ron Shepard
Christoph Nahr
wrote:
> Real programmers don't use Pascal
>
>The real programmers in that story used FORTRAN and did a lot of things
>which may not yet be on your list. See:
>
> http://www.offspin.demon.co.uk/funny/realprog.html
>
Thanks for the pointer! Offspin has three other articles in their
"funny" section that are all worth the read, see bottom of their
computing page at http://www.offspin.demon.co.uk/compute.html .
I particularly like The King And The Toaster which is an excellent
statement on object-oriented programming. :-)
--
Chris Nahr (cnahr@ibmnet, insert dot after ibm to reply by e-mail)
Please don't e-mail me if you post! PGP key at wwwkeys.ch.pgp.net
Mumit Khan
James Giles <james...@worldnet.att.net> wrote:
>I have been preparing such a list, with responses, but it's large and
>I haven't finished it. My list is called ECPK (Every C Progammer Knows).
>You left out a few (and here are some of my responses to some of those
>you mention). There are more (that I just haven't got to). Maybe someone
>else will fill-in where I've omitted.
Don't forget to add the following:
ECPK that EFP (every FORTRAN Programmer) spends more time talking about
C than about FORTRAN.
Regards,
Mumit
ps: nope, I didn't forget to add the smiley.
bg...@my-dejanews.com
> "Craig T. Dedo" wrote:
> > 1. Fortran is 3 way IF statements and one-trip DO loops.
> > 2. Fortran encourages unstructured code and spaghetti-style control flow.
> > 3. Fortran can't do Windows.
> > 4. Fortran is unportable. If you really want portability, you should write
> > your program in C.
> > 5. Fortran is only for scientific and engineering applications.
> > 6. The only real fortran is FORTRAN 77 (or, FORTRAN 66).
> > 7. Fortran can't call system routines.
> > 8. You can't do character string operations easily in Fortran.
> > 9. Only Microsoft makes a PC-based Fortran compiler of any importance.
> > 10. Fortran is a dead language. No one uses it any more to write important
> > applications.
> You are emphasizing expansion at the expense of truth. In particular,
> over a history of 35 years of programming I have never heard #1, #3, #4,
> #5, #6, #7, or #9. #2 and #8 reflect a reality about much legacy
> Fortran code and are probably widely believed. If someone asserted #10,
> I would be suspicious of his general computing knowlege.
And yet #10 is one of the most commonly heard claims about Fortran, so
I for one would not blame Craig for listing it.
#8 is a statement about the language itself, not about particular
applications written in it. It has been a wrong statement since 1978,
and even more so since 1991 (TRIM, ADJUSTL, etc.) At least if your
comparison is with C, Pascal, Ada, etc. If you are comparing to
Snobol or Perl, that's another story.
I don't think I've heard the others verbatim, but certainly some of
the things I've heard (and read on this newsgroup) came very close.
> You should also know that COBOL suffers much more than Fortran in this
> respect. I suspect that the Fortran community is replete with people
> who make ugly noises about COBOL that are more misinformed than any of
> the items you list for Fortran. The analog to #10 is frequently found,
> even though the code-base for COBOL outstrips any other language.
There has been a fair amount of Cobol (with mixed case, for the same
reasons as Fortran) advocacy over on comp.lang.ada recently.
That said, #10 is a statement not about the size of the code base (we
all know there is a lot of legacy code in both Fortran and Cobol) but
about its current rate of growth.
> I also know that frequently anti-C postings are made in comp.lang.c
> which demonstrate that the version of C the posters know is about 1972,
> certainly before the 1989 standard. If Fortran partisans can insist
> that C is still at pre-standard 1972 levels, then surely they have no
> room to squeal if others think Fortran ossified to F77 or F66.
Do those postings in comp.lang.c really come from Fortran users?
And is this thread at all about squealing? I thought it was about
identifying common misconceptions to be debunked in an information
campaign. There is no reason the supporters of C and Cobol couldn't
do the same, to the benefit of us all. (There is already a thread
on comp.lang.ada discussing ways of encouraging the use of Ada.
That is perhaps more aggressive than the one we have here, in that
the goal is to increase Ada _market share_ whereas our only immediate
interest seems to lie in increasing _respect_ for Fortran.)
Jos Bergervoet
>You are emphasizing expansion at the expense of truth. In particular,
>over a history of 35 years of programming I have never heard #1, #3, #4,
>#5, #6, #7, or #9. #2 and #8 reflect a reality about much legacy
>Fortran code and are probably widely believed. If someone asserted #10,
>I would be suspicious of his general computing knowlege.
It may be at the expense of truth, but Craig was explicitely asking
for myths and disinformation. Nothing was said about them being true!
Today of course, nobody really believes these myths any longer. But by
collecting them one can become famous, like Homer, or the Grimm brothers.
-- Jos
Craig T. Dedo
Jos Bergervoet wrote:
>
> Martin Ambuhl <mam...@earthlink.net> writes:
>
> >You are emphasizing expansion at the expense of truth. In particular,
> >over a history of 35 years of programming I have never heard #1, #3, #4,
> >#5, #6, #7, or #9. #2 and #8 reflect a reality about much legacy
> >Fortran code and are probably widely believed. If someone asserted #10,
> >I would be suspicious of his general computing knowlege.
>
> It may be at the expense of truth, but Craig was explicitely asking
> for myths and disinformation. Nothing was said about them being true!
>
> Today of course, nobody really believes these myths any longer. But by
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> collecting them one can become famous, like Homer, or the Grimm brothers.
>
> -- Jos
Nobody??? You obviously do not live in the same world that I live in. As I
mentioned in my introduction, I have **personally** heard each of these at
least once. And, I should add, the people who spouted these did so with a
straight face.
I prepared the original list last November as part of preparation for a talk
on Fortran 90, 95, and F2K to the local (Milwaukee, WI) chapter of the IEEE.
As an introduction to the talk I presented the list as a True/False test on
what people really know about Fortran. In spite of the fact that the audience
was largely quite knowledgeable about Fortran, over half of the audience
agreed that "Fortran is only for scientific and engineering applications" and
"It is difficult to do character operations easily in Fortran".
I have talked with a lot of people who have never actually programmed in
Fortran. Yet, they "know" that all of these myths about Fortran are true!
Usually, though not always, they learned this "knowledge" from their Computer
Science professors.
For example, a few months ago I was talking with a young man who recently
earned his BSCS degree. He told me emphatically that character operations
were inherently difficult. His professors told him that. Of course, he had
done all of his class assignments in C and C++. He had no direct experience
with any other language.
I have had many other similar experiences. In most of the cases, the persons
who "know" what Fortran is like learned all that they know from one comparison
course of of several programming languages. In almost all of these cases, the
version of Fortran that was presented was usually F66. Nothing about any
later versions of Fortran.
Tony T. Warnock
> Martin Ambuhl <mam...@earthlink.net> writes:
>
> >You are emphasizing expansion at the expense of truth. In particular,
> >over a history of 35 years of programming I have never heard #1, #3, #4,
> >#5, #6, #7, or #9. #2 and #8 reflect a reality about much legacy
> >Fortran code and are probably widely believed. If someone asserted #10,
> >I would be suspicious of his general computing knowlege.
>
> It may be at the expense of truth, but Craig was explicitely asking
> for myths and disinformation. Nothing was said about them being true!
>
> Today of course, nobody really believes these myths any longer. But by
> collecting them one can become famous, like Homer, or the Grimm brothers.
>
> -- Jos
They are only believed in academia and by managers.
James Giles
Jos Bergervoet wrote in message ...
...
>It may be at the expense of truth, but Craig was explicitely asking
>for myths and disinformation. Nothing was said about them being true!
>
>Today of course, nobody really believes these myths any longer. But by
>collecting them one can become famous, like Homer, or the Grimm brothers.
Well, this very thread is actually a branch of a discussion which began in
December with an article titled "Why Fortran" which I quote below.
Obviously some people do still believe these "myths".
>> There is this question that I often ask around but that until now I
>> haven't received a satisfactory answer to.
>>
>> My question is: why use Fortran? I had to learn Fortran 77 recently to
>> develop numerical analysis programs. Most of the time I spent on my
>> programs was dedicated to getting around some constraints of Fortran:
>> arrays whose index start at 1, only 1 type of loop, the necessity of GOTO
>> statements, etc etc. The standard argument I get as to why mathematicians
>> use Fortran is speed and efficiency; it seems to me that C or one of its
>> derivatives, even Pascal, would do the job as efficiently and much more
>> clearly. With all these restrictions in variable names, and all these
>> inconvenient branching statements, a Fortran program must be next to
>> impossible to industrially debug/maintain/update 10 years after it was
>> written. I am puzzled as to why Fortran is still so widely used. Is it
>> because some of the early applications were written in Fortran and now it
>> is too much of a hassle to convert them, and thus the work keeps being
>> done in this language? Or is there some other point that I am totally
>> missing?
--
J. Giles
Craig T. Dedo
James Giles wrote:
>
> Well, this very thread is actually a branch of a discussion which began in
> December with an article titled "Why Fortran" which I quote below.
> Obviously some people do still believe these "myths".
>
> <snip>
> --
> J. Giles
Unfortunately, you are mistaken. I missed the thread "Why Fortran" in
December since I was working out of town at the time. I started the thread on
my own initiative so that I could enlarge the collection that I had already
developed.
nor...@mech.eng.usyd.edu.au
: Dear Joe and Readers:
: Jos Bergervoet wrote:
:>
:> Martin Ambuhl <mam...@earthlink.net> writes:
:>
:> Today of course, nobody really believes these myths any longer. But by
: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: Nobody??? You obviously do not live in the same world that I live in. As I
: mentioned in my introduction, I have **personally** heard each of these at
: least once. And, I should add, the people who spouted these did so with a
: straight face.
<snip>
: I have talked with a lot of people who have never actually programmed in
: Fortran. Yet, they "know" that all of these myths about Fortran are true!
: Usually, though not always, they learned this "knowledge" from their Computer
: Science professors.
<snip>
Four years ago I took a supercomputing course split between the
maths/engineering/computer science faculties at another university in
Sydney. The computer scientist lecturer wrote Fortran IV code that he
constantly refered to as "ForTrash" (I admit, the stuff he wrote looked
like trash). On cue the computer science undergrads would snigger
as if he had just told a smutty joke. Another set of minds brainwashed.
He also told them you couldn't do character operations in Fortran. Now
whilst within the scope of there learning, coding on a Cray, character
operations arn't vectorised, that statement is far from the truth.
--
Stuart Norris nor...@mech.eng.usyd.edu.au
Mechanical Engineering,University of Sydney,NSW 2006 wk:+(61 2) 9351-2272
http://www.maths.unsw.edu.au/~norris hm:+(61 2) 9326-5276
Martin Ambuhl
> And is this thread at all about squealing? I thought it was about
> identifying common misconceptions to be debunked in an information
> campaign. There is no reason the supporters of C and Cobol couldn't
> do the same, to the benefit of us all.
My point was that I have been programming in Fortran for over 30 years
and have never heard a number of these "common misconceptions." They
are not "common". There does seem to be some sort of paranoia in this
newsgroup. In the other comp.lang.* newsgroups I very rarely see
complaints about others bad-mouthing their languages. This form of
whining seems largely a property of comp.lang.fortran. Neither do the
anti-C postings in comp.lang.fortran have any parallel of anti-Fortran
postings in comp.lang.c. It is time for us Fortran programmers to grow
up, stop whining, and write code.
Dave Tholen
> Neither do the anti-C postings in comp.lang.fortran have any parallel
> of anti-Fortran postings in comp.lang.c.
It seems to me that the anti-Fortran people make the effort to show up
here rather than the anti-C people going to comp.lang.c.
> It is time for us Fortran programmers to grow up, stop whining, and
> write code.
It seems to me that the anti-Fortran people need to grow up. Indeed,
that's generally true of anyone who needs to go trolling in another
newsgroup just to stir up trouble. A great example is all the Windows
fanatics who show up in the OS/2 newsgroups.
Gregory G. Woodbury
>bg...@my-dejanews.com wrote:
>
>> And is this thread at all about squealing? I thought it was about
>> identifying common misconceptions to be debunked in an information
>> campaign. There is no reason the supporters of C and Cobol couldn't
>> do the same, to the benefit of us all.
>
>My point was that I have been programming in Fortran for over 30 years
>and have never heard a number of these "common misconceptions." They
>are not "common".
All that indicates is that *you* don't know about them. I've been
programming fortran for *40* years, (I also do C, C++, etc...) and I've
heard every one of these misconceptions multiple times over the years.
--
Gregory G. "Wolfe" Woodbury `-_-' Owner/Admin: wolves.durham.nc.us
ggw at wolves.durham.nc.us U Erstwhile co-moderator of:
soc.religion.unitarian-univ
"The Line Eater is a boojum snark." Hug your wolf. (Thanks Peter.)
Dan Nagle
Gregory G. Woodbury wrote:
>
<snip requited material>
> All that indicates is that *you* don't know about them. I've been
> programming fortran for *40* years, (I also do C, C++, etc...) and I've
> heard every one of these misconceptions multiple times over the years.
>
I've been programming in Fortran for a long time, too, and I've heard
most, if not all, of this misinformation. (I also code in C/C++
where appropriate.)
For example, at a DoD HPC center where I was recently consulting,
I heard Ph.D. (C.S.) folks maintain, with a straight face, that
the _only_ reason Fortran programs execute faster than C/C++
programs is because Fortran codes are in the benchmarks, and so
get attention from the vendors' benchmark analysts. They maintain
that there's no inherent advantage given Fortran by its anti-aliasing
rules, etc.
To the contrary, given the profit motive and the scarcity and cost of
benchmark resources, I'll bet many benchmarkers don't do much more
than make the code work, and find the best set of compiler switches.
I have done some commercial benchmarking myself, I know the sort
of resource decisions the VP Sales or benchmark manager have to make.
I'm especially amused and disgusted to hear, over and over, that,
compared to Fortran, C is both 1) closer to the hardware (and
therefore faster) and 2) more portable.
Since these are otherwise intelligent people, one can only assume
these statements are the result of indoctrination while in school.
Part of the cost of hiring a BSCS for a scientific or engineering
programming job is un-doing the indoctrination.
Peter Shenkin
Mumit Khan <kh...@hp2.xraylith.wisc.edu> wrote:
>In article <79cqkl$b...@bgtnsc02.worldnet.att.net>,
>James Giles <james...@worldnet.att.net> wrote:
>>I haven't finished it. My list is called ECPK (Every C Progammer Knows).
>>You left out a few (and here are some of my responses to some of those
>>you mention). There are more (that I just haven't got to). Maybe someone
>>else will fill-in where I've omitted.
>
>
>ECPK that EFP (every FORTRAN Programmer) spends more time talking about
>C than about FORTRAN.
If there are Nf Fortran programmers and Nc C programmers, we'd expect
the amount of time spent by Fortran programmers talking about Fortran
to go as Nf**2. We'd expect the amount of time they talk about C
to go as Nf*Nc.
In order for the proposition to be true, the condition is that Nc>Nf.
This is certainly the case, so this particular ECPK factoid is probably
true. (All in the limit of large N's, of course.)
-P.
-P.
--
*** "Freedom's just another word for nothing left to lose." (B. Yeltsin)***
* Peter Shenkin; Chemistry, Columbia U.; she...@still3.chem.columbia.edu *
* MacroModel URL: http://www.cc.columbia.edu/cu/chemistry/mmod/mmod.html *
Peter Shenkin
Martin Ambuhl <mam...@earthlink.net> wrote:
>.... Neither do the
>anti-C postings in comp.lang.fortran have any parallel of anti-Fortran
>postings in comp.lang.c. It is time for us Fortran programmers to grow
>up, stop whining, and write code.
But it's natural for persecuted minorities to be somewhat sensitive
and even militant. :-)
Ken Plotkin
<mam...@earthlink.net> wrote:
>You are emphasizing expansion at the expense of truth. In particular,
>over a history of 35 years of programming I have never heard #1, #3, #4,
>#5, #6, #7, or #9. #2 and #8 reflect a reality about much legacy
>Fortran code and are probably widely believed. If someone asserted #10,
>I would be suspicious of his general computing knowlege.
I've been doing Fortran for about the same number of years, and I've
heard most of them. #10 is the most common, followed by #2. (I
personally believe in #6, but that's another story. :-) )
A couple of years ago we (the group of a couple of dozen engineers I
work with) tried hiring a "real" programmer. Some of the candidates,
who were very well qualified, expressed astonishment that anybody was
still using Fortran. They thought it had died years ago.
>
>You should also know that COBOL suffers much more than Fortran in this
>respect. I suspect that the Fortran community is replete with people
[snip]
I'll bet it does, and even more unfairly. But it wasn't always like
that. In the mid-60s, when I was cutting my teeth on Fortran and
hanging around the keypunch room, discussions would come up as to
whether one could make a living as a programmer. The consensus was
that you could make a little side money doing Fortran, mostly from
grad students or professors who were inept or arrogant, but the way to
the *real* money was to learn COBOL and work for a bank or a big
company.
Ken Plotkin
Ken Plotkin
<Craig...@mixcom.com> wrote:
> Unfortunately, you are mistaken. I missed the thread "Why Fortran" in
>December since I was working out of town at the time. I started the thread on
>my own initiative so that I could enlarge the collection that I had already
>developed.
I think you can tune in here at almost any time and find a post with
more or less the same assertions. It's refreshing findg them listed
properly as myths, rather than presented as fact or as part of an
obvious troll.
Ken Plotkin
Andrei A. Dergatchev
> >ECPK that EFP (every FORTRAN Programmer) spends more time talking about
> >C than about FORTRAN.
>
> If there are Nf Fortran programmers and Nc C programmers, we'd expect
> the amount of time spent by Fortran programmers talking about Fortran
> to go as Nf**2. We'd expect the amount of time they talk about C
> to go as Nf*Nc.
>
> In order for the proposition to be true, the condition is that Nc>Nf.
I guess the analys above is a bit too linear for our relativistic century. It's
observed phenomenon that when Nc>NcBIG Nc=Nc-Nc++ (part of C
programmers start to talk about ++; so we can't anymore compare Nf with
Nc). Moreover, as it's only 24 hours in day both functions should show
eat&sleep time artifacts. And as those programmers distributed over
whole planet there should be inclusion of timezone effects too :-)
>
> This is certainly the case, so this particular ECPK factoid is probably
> true. (All in the limit of large N's, of course.)
And how about a density of programmers per room at very large Ns ;-) ?
Andrei
>
>
> -P.
James Giles
Martin Ambuhl wrote in message <36BC008F...@earthlink.net>...
...
>My point was that I have been programming in Fortran for over 30 years
>and have never heard a number of these "common misconceptions." They
>newsgroup. In the other comp.lang.* newsgroups I very rarely see
>complaints about others bad-mouthing their languages. This form of
>anti-C postings in comp.lang.fortran have any parallel of anti-Fortran
>postings in comp.lang.c. It is time for us Fortran programmers to grow
>up, stop whining, and write code.
Isn't it interesting that you see the evidence and come to the opposite
conclusion than what it indicates? The reason that you don't see many threads
in the C newsgroups defending the language against disinformation is that users
of other languages are not so childish as to spread disinformation in the first
place. If you want to complain about whining, try directing your attention
to those who initiate these threads: C programmers who come to this
newgroup with false criticisms (though, some are honestly misinformed
themselves - perhaps the criticism should be directed at those who teach
such junk and should know better).
In over 25 years of (mostly) doing programming assistance (help-desk) kind
of work, I've heard most of these common misconceptions large numbers
of times (indeed more, my list was only about half complete). I've even heard
these things come from Computing Science professors. (There's an F90
tutorial on a web site which repeats the Venus probe story!) Who knows
how many students each of these professors managed to convince of these
falsehoods?
If you haven't heard all, or at least most of these misconceptions over the years
it merely means that you have not paid attention to language design issues and
discussions. That is where the issue arises. This newsgroup has seen several
threads about each of the misconceptions mentioned in just the last few years.
All these threads had active participation by C supporters who actually believed
the misconception they were defending.
Now, it's true that people on this newsgroup tend to overreact sometimes (as
seen by the volume of traffic in this thread itself). I'm as guilty as the next one.
In that light, I think the present effort to collect a list of the most common
misconceptions so that we can direct people to the list an just subsequently
ignore them is a good idea. A long thread of discussion is not necessary if
the full response to the issue is already posted to a web site somewhere.
--
J. Giles
Jim McMahon
<snip>
>I'm especially amused and disgusted to hear, over and over, that,
>compared to Fortran, C is both 1) closer to the hardware (and
>therefore faster) and 2) more portable.
>Since these are otherwise intelligent people, one can only assume
>these statements are the result of indoctrination while in school.
>Part of the cost of hiring a BSCS for a scientific or engineering
>programming job is un-doing the indoctrination.
><snip sig>
>--
>Cheers!
>Dan Nagle dna...@erols.com
I guess I'm lucky. My BS program in CS never taught me any such
thing, but rather taught me enough to recognize a fallacy when I see
one. Surely the program I went to wasn't the only one including comp
architecture.
Being ordinary and nothing special is a full-time job.
mcma...@flash.net (Jim McMahon in real life)
Jos Bergervoet
>> If there are Nf Fortran programmers and Nc C programmers, we'd expect
>> [ snip ]
>> In order for the proposition to be true, the condition is that Nc>Nf.
>
> And how about a density of programmers per room at very large Ns ;-) ?
At such large densities, they must be in a solid-state phase. Classical
Science (CS-types) would describe their density by a Maxwell-Boltzmann
distribution. Real programmers, however, are SC-types (Semi-Conductors, of
N or P-type.) Therefore they must obey Fermi-Dirac statistics, otherwise
they might end up all using the same programming language.
They always form two groups, separated by a band gap. In the Conduction
band there are only a few (C programmers.) In the Valence band (Fortran V
programmers) they are very dense. For them, the dynamics is described by
the few holes that are left (in punch-cards.)
-- Jos
bg...@my-dejanews.com
> My point was that I have been programming in Fortran for over 30 years
> and have never heard a number of these "common misconceptions." They
> are not "common".
All is relative. Certainly I don't expect to hear them at a party
(there are much better topics for conversation). But they are common
within that subset of the population who's had an introductory
programming class in college but hasn't moved on to doing serious
work in a field where Fortran is widely used. Those people probably
outnumber Fortran users ten to one or so. Mostly this is harmless
because they don't really need to be accurately informed on Fortran;
but that's a bit like saying that tuberculosis is mostly harmless
because so many carriers remain healthy.
> There does seem to be some sort of paranoia in this
> newsgroup. In the other comp.lang.* newsgroups I very rarely see
> complaints about others bad-mouthing their languages. This form of
> whining seems largely a property of comp.lang.fortran.
As I think I mentioned earlier, comp.lang.ada has its share.
I don't follow the others (not even comp.lang.c, although I do use C
for a number of things myself) closely enough to comment further.
> Neither do the
> anti-C postings in comp.lang.fortran have any parallel of anti-Fortran
> postings in comp.lang.c. It is time for us Fortran programmers to grow
> up, stop whining, and write code.
In what language?
Besides, I'm ever more reluctant to write new code these days.
Reuse is the name of the game (or should be). In any language.
Perhaps that's what programming classes should focus on: how
to design a good library.
Martin Ambuhl
> The reason that you don't see many threads
> in the C newsgroups defending the language against disinformation is that users
> of other languages are not so childish as to spread disinformation in the first
> place.
Actually, this is not quite true. I may have overstated how little
spreading of disinformation there is. These days, C is out of favor
with the faddists. I think a large amount of the cluelessness about
Fortran came from a specific generation of "C programmers", namely those
from the period in which it had a priveledged vogue in the computing
world. In the current world, the chasers after fashion are going to
Java and C++. This means that most of the active C programmers I see,
although obviously YMMV, are more sophisticated, and are very likely
multi-lingual, including Fortran.
There are large numbers of Java, C++, and Visual Basic, along with some
niche language people who enjoy posting inflammatory posts. I know that
the usual approach in comp.lang.c is to ignore the content of such posts
and tell those posters to start their flamewars elsewhere.
>If you want to complain about whining, try directing your attention
> to those who initiate these threads: C programmers who come to this
> newgroup with false criticisms
I agree completely with the sentiment, although, as I indicated, I think
that these days C-raiders are less likely than some others.
If I were not a Fortran programmer, as well as a user of other
languages, I would never post in comp.lang.fortran. Fortran
programmers, like programmers in other languages, do find occasional
difficulties in using their language for certain tasks. They have no
reason to put up with people who have purely destructive reasons for
posting.
Faddish and niche language users are often much more likely to be poorly
informed about the master languages. Fortran is the master language in
numerical applications, and often well suited to other kinds of
programming. Cobol is the master language in financial applications,
and often used satisfactorily in other contexts. Ada is another
language that has suffered unfairly.
You should know that there are a number of posters here who are also
frequent posters in comp.lang.c. I have never seen an anti-Fortran
posting from any of them.
>(though, some are honestly misinformed
> themselves - perhaps the criticism should be directed at those who teach
> such junk and should know better).
>
> In over 25 years of (mostly) doing programming assistance (help-desk) kind
> of work, I've heard most of these common misconceptions large numbers
> of times (indeed more, my list was only about half complete). I've even heard
> these things come from Computing Science professors. (There's an F90
> tutorial on a web site which repeats the Venus probe story!) Who knows
> how many students each of these professors managed to convince of these
> falsehoods?
>
> If you haven't heard all, or at least most of these misconceptions over the years
> it merely means that you have not paid attention to language design issues and
> discussions.
This is inflammatory and absolute bullshit. I have been involved in
writing compilers for six different languages. Perhaps it is precisely
because I HAVE paid attention to language design issues and discussions
that I am not surrounded by idiots.
Dan Nagle
Jim McMahon wrote:
>
> Dan Nagle <dna...@erols.com> wrote:
>
<snip requoted material>
> I guess I'm lucky. My BS program in CS never taught me any such
> thing, but rather taught me enough to recognize a fallacy when I see
> one. Surely the program I went to wasn't the only one including comp
> architecture.
>
<snip sig>
You may well be luckier than you think. I've repeatedly heard
the Fortran misinformation (hereinafter FM) from CS folks from
recent BSCSs to experienced PhDs.
Along with FM, the most recent BSCS I've dealt with (I was supposed
to mentor the him) didn't know what IEEE 754 was. The only Math
he had, beyond freshman calculus, was a choice of Formal Algebra or
Discrete Equations. He had not one hour of Numerical Analysis.
I may have posted this before, but I gave him the task of adding
epsilon()/2. to 0. 1e8 times, and then adding 1. versus adding
epsilon()/2. to 1. 1e8 times. He needed some time to figure out
why the answers differed (and he's a very bright fellow).
BTW, Ada has the same problem. The thread Re: C++ v. Java v. Ada
has been running for some weeks now. Currently, the C++ advocates
are trying to make the case the terseness and safety are correlated,
and that wordiness in a language makes programs hard to read and
understand, if I understand the arguments correctly.
James Giles
Martin Ambuhl wrote in message <36BD50DE...@earthlink.net>...
>James Giles wrote:
...
>> If you haven't heard all, or at least most of these misconceptions over the years
>> it merely means that you have not paid attention to language design issues and
>> discussions.
>
>This is inflammatory and absolute bullshit. I have been involved in
>writing compilers for six different languages. Perhaps it is precisely
>because I HAVE paid attention to language design issues and discussions
>that I am not surrounded by idiots.
Point 1: Let's see if I have your position about what constitutes
"inflammatory" behavior correct. You are saying that telling us
all that we are merely whining is not inflammatory? You are saying
that introducing abusive language is not inflammatory. But you are
saying that expressing an opinion in a civil and polite tone *is*
inflammatory? I disagree.
Point 2: I was talking about the study of language design, not the
study of languages or their implementation. There's no doubt about
it: knowing several languages is a prerequisite to the study of language
design. And knowing how languages and their features are implemented
is also an important part of your background if you want to *start*
studying language design.
But, the study of language design only starts with those skills. You must
also learn how other people program: from absolute novice to grizzled
veteran. You must discover what kind of mistakes they make and how
differing language designs effect this. You must learn how they debug.
How succesful are they? How long does it take? How would a change in
the language's features effect this? You must learn how (or if) users are
managing to reuse previously written code (surveys indicate that C++ users
don't reuse any more code than people programming in more coventional
languages). If they aren't reusing code, why not? Etc.. The study of
language design is largely an exercise in applied ergonomics. Knowing
the technical side of language features and implementation is only the
starting point. I knew and used perhaps two dozen languages and
worked on three different compilers before I even *began* studying
language design.
Point 3: After reconsidering my previous statement, I still stand by it.
I don't think it's actually possible to make an even cursory study of
language design (unless you avoid the subject of Fortran entirely)
without running across many, if not most of the myths & disinformation
discussed in this thread. The first SIGPLAN conference or POPL
symposium you attend will undoubtedly expose you to several,
otherwise intelligent, people who actually believe most of this stuff.
Point 4: After reconsidering your original position I disagree even more
about the value of this thread. I did consider it merely a tool to collect
information to use to debunk common complaints that surface here.
However, after the above analysis, I realized that the kinds of things
people complain about and the nature of their criticisms says a lot about
what they consider important about languages. It is another (admittedly
minor) resource in the study of language design. It's a quite valid thing
to discuss. So, this thread is far from "whining", but actually has value
in two different ways.
--
J. Giles
Peter Loftus
seems in the years since I left school the meaning of affect and effect have
reversed their meaning.
James Giles wrote in message <79kvni$i...@bgtnsc03.worldnet.att.net>...
snip
Carsten A. Arnholm
bg...@my-dejanews.com wrote in message
<873e4jk...@bglbv.my-dejanews.com>...
>Martin Ambuhl <mam...@earthlink.net> writes:
<snip>
>> Neither do the
>> anti-C postings in comp.lang.fortran have any parallel of anti-Fortran
>> postings in comp.lang.c. It is time for us Fortran programmers to grow
>> up, stop whining, and write code.
>
>In what language?
>
>Besides, I'm ever more reluctant to write new code these days.
>Reuse is the name of the game (or should be). In any language.
>Perhaps that's what programming classes should focus on: how
>to design a good library.
Why is it that people that people often talk about how to write reusable
code when they discuss re-use, rather than how to re-use existing code?
Remember that for code to be reusable, it must first be usable. One
advantage old code has, is that it has been proven to be useful. The
challenge should be to re-use it in a new context, even if it has some
flaws. For example you can re-use legacy Fortran code in a C++ program, see
http://home.sol.no/~arnholm/cppf77.htm
The language wars seem pointless, in my opinion. Use what suits you and your
problem best. It's like religion, I have my own preference, but I have to
accept other poeple's opinions also.
Carsten A. Arnholm
arn...@online.no
http://home.sol.no/~arnholm/
James Giles
Peter Loftus wrote in message <_rpv2.18340$Jz1.6...@news2.voicenet.com>...
>This thing has wandered far enough afield, but just to keep it going, it
>seems in the years since I left school the meaning of affect and effect have
>reversed their meaning.
I plead guilty. However, used as a transitive verb, 'effect' means "to bring
about, accomplish" and 'affect' means "to act upon, influence". In the context
I used the word either interpretation is meaningful (barely). I admit I lazily
spell both meanings with an 'e'. A bad habit, but not my worst.
--
J. Giles
Martin Ambuhl
>
> Martin Ambuhl wrote in message <36BD50DE...@earthlink.net>...
> >James Giles wrote:
> ...
> >> it merely means that you have not paid attention to language design issues and
> >> discussions.
> >
> >This is inflammatory and absolute bullshit. I have been involved in
> >writing compilers for six different languages. Perhaps it is precisely
> >because I HAVE paid attention to language design issues and discussions
> >that I am not surrounded by idiots.
>
> Point 1: Let's see if I have your position about what constitutes
> "inflammatory" behavior correct.
Don't be purposely obtuse. You insulted someone doing systems
programming and language development by saying that "you have not paid
attention to language design issues and discussions." Had you
excercised some elementary language skills and read my post you know
what I meant.
> You are saying that telling us
> all that we are merely whining is not inflammatory?
If you regard it inflammatory to call whining by its proper name, that's
your problem.
You are saying
> that introducing abusive language is not inflammatory.
When you introduce gratuitous insults, you invite whatever you get.
When your insult is not only wrong, but based on no data, it can hardly
be wrong to call it bullshit. If your statement is offended, let it
post. No one called you anything.
> saying that expressing an opinion in a civil and polite tone *is*
> inflammatory? I disagree.
Insults are not civil and polite. I agree civil and politely expressed
opinions are not inflammatory. Your pointed, incoreect, and baseless
insults are inflammatory and you should apologize for them rather than
pretending to be on some high moral ground.
James Giles
Martin Ambuhl wrote in message <36BEADFE...@earthlink.net>...
...
>Don't be purposely obtuse. You insulted someone doing systems
>programming and language development by saying that "you have not paid
>attention to language design issues and discussions." Had you
>excercised some elementary language skills and read my post you know
>what I meant.
I intended no insult and posted none. It is quite clear that you have
not paid any attention to language design issues or you would immediately
grasp the following point: systems programming and language development
are interesting, useful, and related activities, but they aren't language *design*.
It is quite possible for someone to do systems programming and language
development quite professionally for many years and not have spent so much
as a second considering language design (though this is one of the reasons we
have some badly designed languages around - C for example). I see nothing
insulting about pointing that out. Language design is a pretty obscure corner
of computing (though it shouldn't be in my opinion) and to lack background in
it is no reflection on your skills at all.
>When you introduce gratuitous insults, you invite whatever you get.
>When your insult is not only wrong, but based on no data, it can hardly
>be wrong to call it bullshit. If your statement is offended, let it
>post. No one called you anything.
Find anything I've said that's objectively insulting and I'll take it
back. It is still my opinion, based on plenty of data, that it's not
possible to have studied language design in even a cursory fashion
and not have heard most of the myths and disinformation this thread
discusses. At least, not if Fortran is among the languages whose
design is studied.
--
J. Giles
Larry Meadows
>Peter Loftus wrote in message <_rpv2.18340$Jz1.6...@news2.voicenet.com>...
>>This thing has wandered far enough afield, but just to keep it going, it
>>seems in the years since I left school the meaning of affect and effect have
>>reversed their meaning.
[snip]
I always thought that 'affect' was one of those things that
psychiatrists said about their patients...
as in 'I found that his affect was blunted after I gave him 500mg of
Thorazine (TM)'
lfm
bg...@my-dejanews.com
> BTW, Ada has the same problem. The thread Re: C++ v. Java v. Ada
> has been running for some weeks now. Currently, the C++ advocates
> are trying to make the case the terseness and safety are correlated,
> and that wordiness in a language makes programs hard to read and
> understand, if I understand the arguments correctly.
So C++'s advocates are Devil's advocates?
I'll have to read that thread more closely. I confess I've been
skipping over some of the subthreads. Certainly the rationale behind
Ada's (and Cobol's) verbosity is that it makes the code easier for
people other than the author to read and understand. To be arguing
the opposite is, well, rather eccentric.
Which brings me to Carsten Arnholm's question in this thread:
why is there so much talk of how to write reusable code and so
little of how to reuse existing code? I think he may have a point,
in that one should *also* teach how to make effective use of
existing code. However, writing reusable code is undoubtedly a much
harder exercise than reusing well-written code, and therefore requires
more practice.
I find that my reuse of other people's code is often limited by the
following factors:
1. Lack of documentation. I have to read the source in order to figure
out what the code does. Comments are scarce and not necessarily up to
date. Even if they are, it is unwise for me to rely on that assumption.
2. Lack of generality. The code has input data or problem-specific
shortcuts hardwired into it. If I want to reuse it on a different
problem, I must sometimes make changes in non-obvious places.
3. Lack of trust. To a large extent this follows from the lack of
documentation, but there is more to it. If the code is sloppily
written (that's not the same thing as unreadable, although the
two are correlated) my confidence in the author's abilities is
diminished.
Teaching people how to avoid those pitfalls in any new code they
write will make code reuse much easier for everyone.
Martin Ambuhl
>
> Martin Ambuhl wrote in message <36BEADFE...@earthlink.net>...
> ...
> >Don't be purposely obtuse. You insulted someone doing systems
> >programming and language development by saying that "you have not paid
> >attention to language design issues and discussions." Had you
> >excercised some elementary language skills and read my post you know
> >what I meant.
>
> I intended no insult and posted none.
Very good. When I say that you have obviously no familiarity with truth
or with the standards of discourse, I mean no insult and post none.
> It is quite clear that you have
> not paid any attention to language design issues or you would immediately
> grasp the following point:
Since your statement "that you have not paid any attention to language
design issues" has less correspondence to fact, shows less familiarity
with the addressed subject, and less research than do any of the cited
myths about Fortran, it is clear that your standard for assertions finds
nothing objectionable about any of the myths about Fortran.
Serguei Patchkovskii
: James Giles wrote:
: > It is quite clear that you have
: > not paid any attention to language design issues or you would immediately
: > grasp the following point:
: Since your statement "that you have not paid any attention to language
: design issues" has less correspondence to fact, shows less familiarity
: with the addressed subject, and less research than do any of the cited
: myths about Fortran, it is clear that your standard for assertions finds
: nothing objectionable about any of the myths about Fortran.
Guys, could you please sort it out somewhere in private?
/Serge.P
James Giles
Martin Ambuhl wrote in message <36BF40DD...@earthlink.net>...
...
>Very good. When I say that you have obviously no familiarity with truth
>or with the standards of discourse, I mean no insult and post none.
You would also be wrong. I know enough about truth and the standards
of discourse to know that indignation is not evidence. You have twice tried
to bluff you way through without addressing the *content* of my position
by just venting your indignaton.
...
>Since your statement "that you have not paid any attention to language
>design issues" has less correspondence to fact, shows less familiarity
>with the addressed subject, and less research than do any of the cited
>myths about Fortran, it is clear that your standard for assertions finds
>nothing objectionable about any of the myths about Fortran.
The more you protest, the more convinced I am. If you had any background
which involved any knowledge of the ergonomics of languages, you'd
have mentioned it by now. The fact that you haven't indicates that you don't
have such background. You could claim that ergonomics has nothing to do
with the subject of language design. If you did that most would disagree,
but at least you'd have a consistent position to defend. But to merely restate
that I'm wrong is not a valid argument.
Why don't you just admit it? You are an implementor and systems programmer
and any ideas you have about language design are merely based upon your own
tastes rather than on any study of ergonomics or wide experience with large
numbers of other programmers. There's no stigma attached to that. Most
people have made no effort to study the ergomomic issues of programming.
--
J. Giles
ess...@ix.netcom.com
> They are only believed in academia and by managers.
What a comforting thought -- that's all it takes to assure the path to
extinction. What future is there once you "poisson" all the children!??
_
B.Voh
ess...@ix.netcom.com
> >> My question is: why use Fortran? I had to learn Fortran 77 recently to
> >> develop numerical analysis programs. Most of the time I spent on my
> >> programs was dedicated to getting around some constraints of Fortran:
> >> arrays whose index start at 1, only 1 type of loop, the necessity of GOTO
A second reading seems to confirm just how deep the indoctrination is. The young
thing didn't come to this opinion by doing but by immersion in the academic
vapor. Had she only done a single array app she would have learned just how
annoying, indeed counter intuitive, is the rigidity of zero based indexing
constraint -- hilarious, if not sad, is her (learned) mindset, falsity and
all, that start at 1 is a *constraint* while the start at 0 is a *C*ementex*
blast.
--
Dr.B.Voh
-----------------------------------------------
Modeling * Simulation * Analysis
http://www.netcom.com/~essoft
-----------------------------------------------