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.D...@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.

  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

------------------------------------------------------------------

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.

The lack of pointers means Fortran can't have "interesting" data
structures.  The C-pointer adds flexibility, never complexity.

There are no preprocessors for Fortran, because cpp mangles
fixed format Fortran source code.

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.

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.

There are no programing utilities to help a Fortran programmer.
Netlib doesn't exist since it didn't come from Micro$oft.

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.

Of course, rereading MAD MAgazine's _Snappy Answers to Stupid
Questions_ helps put one in the proper mindset ;-)

<snip sig>

--

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.

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.

ECPK that EFP (every FORTRAN Programmer) spends more time talking about
C than about FORTRAN.

Regards,
Mumit

#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.

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.

Today of course, nobody really believes these myths any longer. But by
collecting them one can become famous, like Homer, or the Grimm brothers.

        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.

--
----------
Sincerely,
Craig T. Dedo                   Internet:    Craig.D...@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.

--
----------
Sincerely,
Craig T. Dedo              Internet:    Craig.D...@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.

:       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.

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.

<snip sig>

--

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.

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.

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.

Andrei