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
-----------------------------------------------
Carsten A. Arnholm
bg...@my-dejanews.com wrote in message
<87emo0y...@bglbv.my-dejanews.com>...
>Dan Nagle <dna...@erols.com> writes:
>
>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.
This is an interesting observation. The most important aspect of reusable
code may not always be the code itself, but the way it is commented or
otherwise documented. Therefore, when discussing how to write reusable code
one should also discuss how it should be documented.
A very important thing in the long run is that documentation will become
detached from the source code. My experience is that the only documentation
that will be maintained is the documentation that is in source code comment
format.
>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.
If you have to change it, it may be usable, but perhaps not very re-usable.
Reuse by cut-and-paste is the "lowest" form of reuse. Ideally, the code that
you are re-using should not be touched, because then you take over the
responsibility for its maintenance. Often, it is possible to avoid this. If
the interface contains problem-specific short-cuts, you may be able to hide
that in a (well written?) layer of your own.
>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.
Trust in the code should also come from its past performance. If it has
worked well for a number of years, if its interface is well described, it
could be re-used even if the code looks sloppy ("sloppy" may be a subjective
term?). Other than that, I totally agree.
Robert O'Dowd
>
> 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
> 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.
>
Having monitored a number of comp.lang.* newsgroups for a while, I
believe
the problem is that advocates of other languages are more likely to
troll through comp.lang.fortran with statements such as "the language
is obsolete; why not use language X?". I would submit that few FORTRAN
programmers would post a troll to (say) comp.lang.c. Although I don't
monitor COBOL related newsgroups [I don't work in a domain suited to
COBOL],
I suspect they would encounter similar trolls.
Isn't that a problem that this thread aimed to address? The fact is,
there is a fair amount of misconception --- some positive but mostly
negative --- on the strengths and weaknesses of FORTRAN vs other
languages. Let's get these misconceptions (whether common or otherwise)
out in the open, and address them honestly. And give serious
programmers the information they need to make informed choices between
languages or on the use of multi-language programming.
-<Automagically included trailer>
Robert O'Dowd Ph +61 (8) 8259 6546
MOD/DSTO Fax +61 (8) 8259 5139
P.O. Box 1500 Email:
robert...@dsto.defence.gov.au
Salisbury, South Australia, 5108
Disclaimer: Opinions above are mine and may be worth what you paid for
them
Robert Corbett
No, they are C++ advocates.
>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.
Of course, Fortran programmers have been practising code reuse for
the past 40 years. Fortran libraries such as EISPACK, LINPACK and
LAPACK have been the model of code reuse. In addition, there are
collections of source codes such as TOMS (nee CALGO).
The simple fact is that it is very hard to write high-quality
codes for scientific computing. If a routine one needs is already
available, it is hard to justify the effort of writing such codes
oneself.
Sincerely,
Robert Corbett
Martin Ambuhl
> Having monitored a number of comp.lang.* newsgroups for a while, I
> believe
> the problem is that advocates of other languages are more likely to
> troll through comp.lang.fortran with statements such as "the language
> is obsolete; why not use language X?".
>I would submit that few FORTRAN
> programmers would post a troll to (say) comp.lang.c. Although I don't
> monitor COBOL related newsgroups [I don't work in a domain suited to
> COBOL],
> I suspect they would encounter similar trolls.
This is absolutely true. Mature progamming languages tend to be used by
more mature progammers. This rule is not, of course, absolute.
Fortran, Cobol, PL/1 programmers fall into this group. Their newsgroups
tend to be targets of trolls; the programmers tend not to troll.
At one time C and Ada were faddish languages. Children with
half-digested statements from their lecturers often would troll other
groups. For the most part, C and Ada are no longer stylish and those
languages and their programmers have graduated in to the mature group.
C++ and Java are the languages de jour in many departments. Not only do
student programmers troll other places, but misquote in their own
newsgroups what they think they have been taught.
Other problems arise from hobbyists who think that Visual Basic and
Windows define the world. Similarly, niche languages like Forth and
Smalltalk produce a small group of trollers.
>
> Isn't that a problem that this thread aimed to address? The fact is,
> there is a fair amount of misconception --- some positive but mostly
> negative --- on the strengths and weaknesses of FORTRAN vs other
> languages. Let's get these misconceptions (whether common or otherwise)
> out in the open, and address them honestly. And give serious
> programmers the information they need to make informed choices between
> languages or on the use of multi-language programming.
I agree. However, it seems that the population from which Fortran
programmers have traditionally come is very likely to still be exposed
to Fortran. The nonce-programmers who are now filling CS departments
will soon be stockbrokers. They used to major in Business Math.
Certainly anyone interested in High Performance Computation will be
exposed to Fortran in all its glory.
Kenneth G. Hamilton
opposed
to a personal insult to anyone's grandmother), but another one is:
XX. There are no bit manipulation operations in Fortran.
Craig T. Dedo wrote:
> 3. Fortran can't do Windows.
The truly comical thing is that Fortran is actually _better_ at Windows
than C. As the late great Microsoft demonstrated with their QuickWin,
the Fortran OPEN and CLOSE statements are natural ways of opening and
closing a window in a GUI environment. I sometime wonder if MS didn't
ditch Fortran in order to avoid facing the fact that an extension of
QuickWin would make it much easier for Windows programming than the
language that they were using by fiat.
When I refer to extensions to QuickWin, I am thinking of such things as
naming a window's callback function with a clause in the OPEN
statement. Another would be to continue the use of user-specified
logical unit numbers to address the windows, rather than the handle
mechanism (where the mystery value is known only at run time).
> 4. Fortran is unportable. If you really want portability, you should write
> your program in C.
If you want a real hoot, ask a C programmer how he would perform
character string manipulations on a machine that is not byte
addressable. (I did that in the Watcom booth at a "Software
Development" show one time; the blood visibly drained from the face of
one of the company's founders.) They have the PDP-11 architecture
etched into the language, and fail to consider what they would do with
something like a CDC 7600: no bytes, 60-bit "floats," and very slow
"doubles.". The Fortran CHARACTER variable type is as portable as they
come.
> 5. Fortran is only for scientific and engineering applications.
Geez, somebody should have told those guys at Perkin-Elmer that it was
impossible. Salford, too.
> 6. The only real fortran is FORTRAN 77 (or, FORTRAN 66).
And they spell "Fortran" in ALL CAPS, inorder to show that they are so
clueless that they haven't even read the _first_ page of the standard,
where X3J3 declared the word to be a proper noun rather than an acronym.
> 7. Fortran can't call system routines.
This one has annoyed me since the early days of the PC. Syetm call
routines are loaded into the libraries for C (and in the past, Pascal),
but not Fortran. Then, even some of the compiler makers repeat this
line as an excuse for not including the same routines in their Fortran
libraries. This is a perfect example of a self-fulfilling prophesy.
Another excuse is:
7A. The ANSI spec didn't require us to put it in the Fortran
product.
It didn't require them to put it in the other boxes, either, but they
did it.
> 8. You can't do character string operations easily in Fortran.
See above.
> 9. Only Microsoft makes a PC-based Fortran compiler of any importance.
Microsoft? Who's that? Don't they specialize in a knock-off of Java,
but one that doesn't satisfy the Sun standard? And how can they run a
company where nobody in management can remember what he meant in his
memos? *We* have a language that is do powerful that it scared Bill
Gates away!
Oh, yes, then there's the one about how only by explicitly declaring all
the variables is it possible to detect misspelled variables. You hear
that one from folks who have never used a comiler that included the
error messages:
"Variable <name> is used but never given a value."
and
"Variable <name> is given a value but never used."
and
"Variable <name> is declared but never used."
It turns out that modern compilers can identify all the really bad
issues involving misspelled variables. (Whether the compiler makers
want to emit these helpful messages or not is another question.) Nobody
wants to admit that the real reason with the Algol family of languages
requires the user to declare all the variables is to make it easier for
the compiler writer. And, as everybody in semicolonland knows, the sole
purpose of a computer is to support a compiler, and that compilers are
never used except to write new compilers. Therefore, shifting work from
the compiler writer to the compiler user makes perfect sense because
there are more people in the first set than the second, and the customer
is always wrong.
Tony T. Warnock
Carsten A. Arnholm
<36C0562A...@cic-mail.lanl.gov>...
This is getting fishy ....
ca
Myron A Calhoun
<<... to hear that, compared to Fortran, C is both 1) closer to the
<<hardware (and therefore faster) and 2) more portable.
<mcma...@flash.net (Jim McMahon) writes:
<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.
The BS in CS program at Kansas State University changed its "Computer
Organization and Programming" class a few years ago so that its major
emphasis is now "let's look at the dis-assembled output of the compiler
to see just how C code is translated/mapped into the hardware's instruction
set". There is really no interest in how capable the hardware might be;
just "how does C translate".
--Myron.
--
# Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
# PhD EE (Professor Emeritus) "Barbershop" tenor. CDL(PTX) W0PBV (785) 539-4448
# NRA Life Member and Certified Instructor (Home Firearm Safety, Rifle, Pistol)
Jim Klein
don't over punctuate their code with semicolons.
Jim Klein
Jos Bergervoet
>> and that wordiness in a language makes programs hard to read and
>> understand, if I understand the arguments correctly.
> 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.
Mathematics, for instance, is much more terse than programming languages.
And I'm sure the mathematicians have tried alternatives (like natural
language). They've found that it simply is more clear when it's short!
Fortran can also be fairly terse, if you just use the f77 way:
function f(a, x)
g(x) = 1-a*x**2
f = sin(g(2*x)) - cos(g(x/2))
end
Some would say that you shouldn't use the statement-function, should use
explicit typing, longer names, and maybe more hype-talk.
But I think the above is the best, even if that means agreeing with C++
advocates. I think the "verbosity rationale" is coming from CS types :-)
Yours eccentrically,
Jos
Richard Maine
> Fortran can also be fairly terse, if you just use the f77 way:
...
> Some would say that you shouldn't use the statement-function, should use
> explicit typing, longer names, and maybe more hype-talk.
...
> I think the "verbosity rationale" is coming from CS types :-)
I have 3 degrees in engineering (the last one being pretty heavy in
mathematics), but none in computer science. I haven't even taken more
than a small handful of computer science classes. I'll admit I taught
one once, but it was in numerical analysis, so that's practically
engineering. (Even used floating point. :-)).
I certainly do think verbosity can go overboard. I personally never
spell out "dimension", preferring the syntax that avoids that keyword;
and I have other places where my personal style is more on the terse
than the verbose side. So describing my preferences as "verbosity"
is probably overly general.
But in spite of my lack of formal CS training, I'm very strong in my
preference for explicit declaration. This comes not so much from any
part of my academic background as from the innumerable times I've
helped users find bugs that wouldn't have happened (or would have been
trivial to find) if they had used explicit declaration. I think I
lost count when it overflowed the 16-bit registers in my mind. Whatever
the count was, its one more as of 10 minutes ago. (That case was
combined with the use of fixed source form, so that the user didn't
notice that all except the first letter of the variable name was after
column 72).
And that's not even counting all the old bugs I kept finding in my own
code from the days before I finally "repented the sons of my youth".
I confess. Lord, I have sinned many times. But I won't do it again.
Well....not that one anyway. :-)
--
Richard Maine
ma...@altair.dfrc.nasa.gov
James Giles
Jos Bergervoet wrote in message ...
...
>Mathematics, for instance, is much more terse than programming languages.
>And I'm sure the mathematicians have tried alternatives (like natural
>language). They've found that it simply is more clear when it's short!
>
> g(x) = 1-a*x**2
> f = sin(g(2*x)) - cos(g(x/2))
> end
I believe you're using the word "terse" incorrectly. The correct word
for brevity that's not confusing is "succinct". The difference between
something that's succinct and something that's terse is difficult to
define in a precise way. It's perhaps more a psychological distinction
than a technical one. Usually terseness involves the removal of too
many of the redundancies that are present in any writing whose
presence is required to clearly understand the content. In C, for
example, people often put lots of content, including several assignments,
into a single expression. This is not much shorter than a code in which
the assignments are all made on a separate line, but it tends to be *much*
less legible.
Terse presentations tend to require even more commentary and
description than verbose ones. Succinctness is some compromise
in between. The naming of a common part of the expression is
a perfectly sound step. It makes the program shorter yet also
provides a name and a definition that can be separately discussed
and understood. It helps to reduce the complexity of the expression
into small, easier to understand parts.
I have no complaint about short names so long as the context is not
overly filled with them. Lots of short names can be confusing (as
most old-style BASIC programmers will remember).
Verbose languages and terse languages are both undesirable. They
go overboard on the extremes. The fact that the specific characteristics
that make a language feature verbose or terse are difficult to precisely
specify is what makes language design more than just a technical
construction job.
--
J. Giles
Martin Ambuhl
>
> >
> >Some would say that you shouldn't use the statement-function, should use
> >explicit typing, longer names, and maybe more hype-talk.
> >
>
> Do shortcuts such as
>
> i++ = ++j ;
>
> present in C/C++ really improve readability?
Probably not. It is not legal code in C or C++. And there is no such
language as C/C++, unless you just invented it so your example would be
legal somewhere.
Michael Kagalenko
]>I certainly do think verbosity can go overboard. I personally never
]>spell out "dimension", preferring the syntax that avoids that keyword;
]>and I have other places where my personal style is more on the terse
]>than the verbose side.
]I have wondered why the ALLOCATABLE keyword is necessary
]for allocatable arrays. It seems to me that a declaration such as
]
]
]real :: x,y(n),z(:,:)
]
]could be interpreted unambiguously as declaring
]
]x as a real scalar
]y has having n elements, where n is a parameter or an argument in
] the procedure where the declaration appears
]z is an allocatable array that can be used after it appears in an ALLOCATE
] statement.
If this code occurs in a subroutine, then z() could be an argument, not
allocatable array. So this declaration is ambiguous.
Michael Kagalenko
]Fortran programmers are better human beings, in general, because they
]don't over punctuate their code with semicolons.
Hey, but that's no myth, - we really are ! :-)
James Van Buskirk
Mike Prager wrote in message <36c10f1...@news.slip.net>...
>I was at first astounded that F90 uses the un-abbreviated word
>"dimension" but abbreviates "length" to "len". Might we have "dim" in
>F2000?
More than likely. It is a useful enough intrinsic that the
committee probably doesn't want to break code like:
Program Dimuend
write(*,*) dim((/1,2,3,4,5/),(/5,4,3,2,1/))
end Program Dimuend
by deleting it.
Bukic
>Some would say that you shouldn't use the statement-function, should use
>explicit typing, longer names, and maybe more hype-talk.
>
>But I think the above is the best, even if that means agreeing with C++
>advocates. I think the "verbosity rationale" is coming from CS types :-)
Do shortcuts such as
i++ = ++j ;
present in C/C++ really improve readability?
Vivek Rao
Bukic
>spell out "dimension", preferring the syntax that avoids that keyword;
>and I have other places where my personal style is more on the terse
>than the verbose side.
I have wondered why the ALLOCATABLE keyword is necessary
for allocatable arrays. It seems to me that a declaration such as
real :: x,y(n),z(:,:)
could be interpreted unambiguously as declaring
x as a real scalar
y has having n elements, where n is a parameter or an argument in
the procedure where the declaration appears
z is an allocatable array that can be used after it appears in an ALLOCATE
statement.
Vivek Rao
Mike Prager
<ma...@altair.dfrc.nasa.gov> wrote:
>I certainly do think verbosity can go overboard. I personally never
>spell out "dimension", preferring the syntax that avoids that keyword;
I was at first astounded that F90 uses the un-abbreviated word
"dimension" but abbreviates "length" to "len". Might we have "dim" in
F2000?
Mike Prager
from Northern California
James Giles
I tend to agree with Richard Maine. I haven't used the dimension
keyword since before the Fortran 77 standard came out. I think
the keyword should be deleted from the standard entirely. But then,
I never liked the LEN= specifications either. I prefer to affix the length
to each character variable declared.
However, what I find most verbose about the present standard is
the rather longish interface specifications. I wonder what could be
done there?
--
J. Giles
Oleg Krivosheev
look, mom, dinosaurs !!!
don't worry, son, they're GOOD dinosaurs...
;)
OK
Martin Ambuhl
>
> Jim Klein (kdpo...@kdpoptics.com) wrote
> ]Fortran programmers are better human beings, in general, because they
> ]don't over punctuate their code with semicolons.
>
> Hey, but that's no myth, - we really are ! :-)
Cute. Fortran programmers are better human beings than English majors,
for whom the ', -' sequence would be spelled ';'.
Devon Prichard
>
> But in spite of my lack of formal CS training, I'm very strong in my
> preference for explicit declaration. This comes not so much from any
> part of my academic background as from the innumerable times I've
> helped users find bugs that wouldn't have happened (or would have been
> trivial to find) if they had used explicit declaration. I think I
> lost count when it overflowed the 16-bit registers in my mind. Whatever
> the count was, its one more as of 10 minutes ago. (That case was
> combined with the use of fixed source form, so that the user didn't
> notice that all except the first letter of the variable name was after
> column 72).
>
> And that's not even counting all the old bugs I kept finding in my own
> code from the days before I finally "repented the sons of my youth".
> I confess. Lord, I have sinned many times. But I won't do it again.
> Well....not that one anyway. :-)
"repented the sons of my youth" sounds like a child support problem,
not a programming problem... but if you had declared IMPLICIT NONE
at the top of your post and explicitly defined all of your variables,
you would have caught this... ;)
and I've heard many excuses for why the "elder statesmen" here
have "selective memory", but now I realize its just a
word length problem... ;)
---------------------------------------------------------------------------
Dr. Devon Prichard, Lockheed Martin d.s.pr...@larc.nasa.gov
Applying computer technology is simply finding the
right wrench to pound in the correct screw.
---------------------------------------------------------------------------
Serguei Patchkovskii
: I tend to agree with Richard Maine. I haven't used the dimension
: keyword since before the Fortran 77 standard came out. I think
: the keyword should be deleted from the standard entirely. But then,
Well, I do find DIMENSION rather useful in cases where I want to
have an array of the default type determined by IMPLICIT somewhere.
This is really useful when you have to move between architectures
with 4- and 8-byte REALs, and want to minimized changes to the
source code. Admittedly, in Fortran-90 KIND-types make it even
easier (and, with SELECTED_{REAL|INT}_KIND, more portable). However,
most of the production codes I have to work with are still Fortran-77,
and will remain this way for the foreseeable future.
Regards,
/Serte.P
Richard Maine
> James Giles (james...@worldnet.att.net) wrote:
>
> : I tend to agree with Richard Maine. I haven't used the dimension
> : keyword since before the Fortran 77 standard came out. I think
> : the keyword should be deleted from the standard entirely. But then,
>
> Well, I do find DIMENSION rather useful in cases where I want to
> have an array of the default type determined by IMPLICIT somewhere.
> This is really useful when you have to move between architectures
> with 4- and 8-byte REALs, and want to minimized changes to the
> source code.
I never used this practice, even in f77. I see your concept, but I
don't personally think it a big enough benefit to justify the costs.
The cost of using implicit is just too high (cost in terms of the
debugging required). And to make this work, you not only have to
use implicit, you have to use *NOTHING* but implicit. Never declare
any variables explicitly, but instead let the implicit rules
dictate your variable names.
If you find it acceptable considering your own requirements, then ok.
But I wouldn't (and didn't) do it myself.
Yes, I needed to move codes between architectures with different
default real sizes (including ones that didn't use bytes at all). I
used a few different approaches over the years. one of them was to
write the code with "double precision" declarations and then make sure
that a global search and replace of "double precision" by "real" would
convert the code. I had to be careful about several things in the
code to make sure this would work. (Most notably, avoid literal
floating point constants in problem contexts like as actual
arguments). Doing the global replace was easy enough, particularly
since I was consistent about the columns the "double precision" was
in. I think I once even had a Fortran program to do it for me. All
sort of a bother, but it worked. These days, of course, I use f90
kinds and life is much simpler.
--
Richard Maine
ma...@altair.dfrc.nasa.gov
Werner Schulz
James Giles wrote in message <79r6mh$5...@bgtnsc02.worldnet.att.net>...
>
>Mike Prager wrote in message <36c10f1...@news.slip.net>...
>>On 09 Feb 1999 11:13:32 -0800, Richard Maine
>><ma...@altair.dfrc.nasa.gov> wrote:
>>
>>>I certainly do think verbosity can go overboard. I personally never
>>>spell out "dimension", preferring the syntax that avoids that keyword;
>>
>>I was at first astounded that F90 uses the un-abbreviated word
>>"dimension" but abbreviates "length" to "len". Might we have "dim" in
>>F2000?
>
>keyword since before the Fortran 77 standard came out. I think
>the keyword should be deleted from the standard entirely. But then,
>to each character variable declared.
I am somewhat surprised by this attitude towards the dimension keyword.
I don't like it either but for very different reasons. I think the
description of dimension (and pointers) as attributes and the syntax in
F90 is just not consistent.
An array is a generic data type and should be declared as such, taking two
parameters, the type of its elements and a rank declaration, something like
this
pseudocode:
ARRAY( REAL, rank=2) :: x
ARRAY( person ) :: people ! person is a user-derived datatype,
implicit rank=1
(Yes, bounds are missing but I just want to get the idea across.)
Also, pointers are a generic datatype and should be declared in a similar
way.
And in one swoop, it is very easy to declare an array of pointers or a
pointer to an
array:
POINTER( ARRAY(real, rank=1)) :: p ! pointer to an array
ARRAY( POINTER(real), rank=1) :: ap ! array of pointers to real
variables
None of the F90 detours to get these things out are needed.
Pointers(Pointers(...)) is not allowed.
>However, what I find most verbose about the present standard is
>the rather longish interface specifications. I wonder what could be
>done there?
That's bothered me for a long time since it requires the user to specify
various things
in up to three different places.
Why can't we have syntax for overloaded functions like this:
module X
contains
FUNCTION(T), PUBLIC :: "+"(a,b) result(c)
T, intent(in) :: a, b ! T is some type declaration
T :: c
! some operation with a and b
END FUNCTION "+"
end module X
instead of
module Y
INTERFACE OPERATOR(+)
MODULE PROCEDURE myadd
END INTERFACE
PUBLIC :: OPERATOR(+)
contains
FUNCTION myadd(a,b) result(c)
T, intent(in) :: a,b
T :: c
! some operation with a and b
END FUNCTION myadd
end module Y
It's a much better to keep declarations together that belong together than
spreading them out
over several lines of code. This is verbosity instead of succinctness. I see
even more evidence
of just plain and unnecessary wordiness in F200x.
Cheers,
Werner Schulz
Computer Consultant
Tessella Support Services plc (www.tessella.co.uk)
4 Wellington Street, Cambridge CB1 1HZ
Disclaimer: The opinion expressed here is that of the author and not
necessarily that of Tessella.
Michael Kagalenko
]>
]> Jim Klein (kdpo...@kdpoptics.com) wrote
]> ]Fortran programmers are better human beings, in general, because they
]> ]don't over punctuate their code with semicolons.
]>
]> Hey, but that's no myth, - we really are ! :-)
]
]Cute. Fortran programmers are better human beings than English majors,
]for whom the ', -' sequence would be spelled ';'.
Fortran programmers are better human beings then C programmers, for
whom x**y is
#include <math.h>
pow(double x, double y);
bg...@my-dejanews.com
> Mathematics, for instance, is much more terse than programming languages.
> And I'm sure the mathematicians have tried alternatives (like natural
> language). They've found that it simply is more clear when it's short!
Yes, but only up to a point. The essential attribute of mathematical
notations is not compactness but rigor. Verbosity is the least of
natural language's problems: ambiguity is much worse.
I'll add that I personally would find a mathematics textbook without
natural-language explanations (of what the symbols stand for,
to begin with; and of what the purpose of a sequence of algebraic
manipulations is) to be rather indigestible. I know this is a minority
view among mathematics and physics students, and that the typical
homework a grader is confronted with is all formulae and no words;
but that is *not* what I call readable. (I have similar problems with
some scientific papers: if they are badly written, in style or
in internal organization, I lose patience reading them. Yes, I can
figure it out given enough time; but time is precious.)
> Fortran can also be fairly terse, if you just use the f77 way:
>
> function f(a, x)
> g(x) = 1-a*x**2
> f = sin(g(2*x)) - cos(g(x/2))
> end
That example is a little too simple to be interesting. Anyway,
here is the Ada 95 version:
with Ada.Numerics.Elementary_Functions;
use Ada.Numerics.Elementary_Functions;
function F (A, X: Float) return Float is
function G (X: Float) return Float is
begin
return 1.0-A*X**2;
end G;
begin
return Sin(G(2.0*X))-Cos(G(X/2.0));
end F;
Yes, it is somewhat wordier but not excessively so.
> Some would say that you shouldn't use the statement-function, should use
> explicit typing, longer names, and maybe more hype-talk.
The only thing I definitely would say is that explicit typing is a
good thing.
Longer names? Maybe for F itself, but G, A, X seem just fine.
The statement function has this problem: it looks too much like
an assignment to an array element. The advantage of writing it out
as an internal procedure is that its nature is made explicit.
Fortran 90/95 has perhaps a slight advantage over Ada, in that the
definition of G would come *after* the main body of F. At least some
people seem to think that this order makes for more readable code.
Another thing I like about the Ada version is the use of "begin" to
separate the declarative part from the executable statements.
Fortran's CONTAINS plays a similar role, but unfortunately only
vis-à-vis internal procedures. In Jos's original example, such
a separation would clearly show "g(x)=1-a*x**2" to be a statement
function definition (declarative) and not an assignment to an array
element (executable). I would at least have added a blank line there.
> But I think the above is the best, even if that means agreeing with C++
> advocates. I think the "verbosity rationale" is coming from CS types :-)
Readability was a design goal of Cobol long before the term "Computer
Science" was coined, and long before GOTOs were declared harmful.
It was also a design goal of Ada, though the target readership was
rather different (other programmers, not necessarily the suits higher
up the hierarchy). In Ada's case, "CS types" may well have been
involved. But the claim is not that verbosity is desirable per se
(it isn't), but rather that certain syntactic features of a computer
language can make it more or less readable by humans.
nor...@mech.eng.usyd.edu.au
: I certainly do think verbosity can go overboard. I personally never
: spell out "dimension", preferring the syntax that avoids that keyword;
It saves typing when you have 20 arrays of the same size
REAL, DIMENSION(l,m,n) :: a,b,c,d,e,f, etc etc
--
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
James Giles
Werner Schulz wrote in message <79t5i6$pcb$1...@uranium.btinternet.com>...
...
>I am somewhat surprised by this attitude towards the dimension keyword.
>I don't like it either but for very different reasons. I think the
>description of dimension (and pointers) as attributes and the syntax in
>F90 is just not consistent.
>An array is a generic data type and should be declared as such, taking two
>parameters, the type of its elements and a rank declaration, something like
>this
>pseudocode:
> ARRAY( REAL, rank=2) :: x
> ARRAY( person ) :: people ! person is a user-derived datatype,
>implicit rank=1
>(Yes, bounds are missing but I just want to get the idea across.)
But, I really consider the bounds (at least) of an array to be an attribute
of the variable, not a part of its type. If not, then an allocatable array
would have different *type* every time you deallocated it and allocated
again with different bounds. Try to statically type-check that!
Also, where would you specify the bounds in the above syntax? I can't
think of any reasonable place that both: associates the bounds with each
variable individually; and is not redundant with the description you've already
given.
Besides, I often want to declare related variables on the same statement
even though they have differing ranks:
REAL :: A(10), B(10,20), C(20) ! A.dot.B yields a C
...
>Also, pointers are a generic datatype and should be declared in a similar
>way.
>And in one swoop, it is very easy to declare an array of pointers or a
>pointer to an
>array:
> POINTER( ARRAY(real, rank=1)) :: p ! pointer to an array
> ARRAY( POINTER(real), rank=1) :: ap ! array of pointers to real
>variables
>
>None of the F90 detours to get these things out are needed.
>Pointers(Pointers(...)) is not allowed.
Well, I take the rather radical position that pointers should be removed
from the standard entirely. So it's hard for me to work up any enthusiasm
for any different ways of treating them.
...
>>However, what I find most verbose about the present standard is
>>the rather longish interface specifications. I wonder what could be
>>done there?
>
>That's bothered me for a long time since it requires the user to specify
>various things
>in up to three different places.
>Why can't we have syntax for overloaded functions like this:
>
>module X
>contains
> FUNCTION(T), PUBLIC :: "+"(a,b) result(c)
> T, intent(in) :: a, b ! T is some type declaration
> T :: c
> ! some operation with a and b
> END FUNCTION "+"
>end module X
This is called parametric polymorphism (at least, this is one of the
things parametric polymorphism does). I like it. I still think it should
be considered more important to include into the standard than OOP.
Even better would be a more fully developed style of parametric
polymorphism in which you could describe and apply constraints to
a parametrically stated data type:
Subroutine quick_sort(array)
Type(ordered->T), intent(in) :: array(:)
... some implementation of quicksort ...
End Subroutine quick_sort
Here, T can be any type provided it meets the constraint that it's ordered.
And, the procedure could easily be typechecked to insure it uses no operations
on the arguments that aren't defined within the definition of the constraining
Phylum. You would elsewhere have described what 'ordered' meant:
Phylum ordered :: P
Logical Function "<" (a,b)
P, intent(in) :: a, b
End Function "<"
Logical Function ">"(a,b)
... ! interface specifications for all ordering operators
...
End Phylum ordered
Here we've said that a type is considered ordered if (and only if) there
are relational operators defined on the type. (I used the name "Phylum"
for this concept, though it's probably too cute. Haskell uses the keyword
"class" for this concept, but this leads to confusion with OOP - which this
definitely is not.)
Obviously you could define phyla for any set of algebraic properties you
desire. When you call a given generic procedure, the constraint(s) tell
both you and the compiler what algebraic properties the arguments
must possess and the compiler can very easily test (statically) that the
constraints are met.
That's a very quick (and superficial) description of a part of parametric
polymorphism. I hope it at least conveys the basic idea. For what it's
worth.
--
J. Giles
Bukic
>]for allocatable arrays. It seems to me that a declaration such as
>]
>]
>]real :: x,y(n),z(:,:)
>]
>]could be interpreted unambiguously as declaring
>]
>]x as a real scalar
>]y has having n elements, where n is a parameter or an argument in
>] the procedure where the declaration appears
>]z is an allocatable array that can be used after it appears in an ALLOCATE
>] statement.
>
> allocatable array. So this declaration is ambiguous.
>
If you had a subroutine,
subroutine foo(w,n) ! proposed Fortran syntax
real :: w(:,:),x,y(n),z(:,:)
the dimensions of w would be determined by the program unit
calling the subroutine, and z, which is not an argument, would
be allocatable. So I think that with the proper rules, the declaration
is not ambiguous.
Vivek Rao
Dan Tex1
>>
>> function f(a, x)
>> g(x) = 1-a*x**2
>> f = sin(g(2*x)) - cos(g(x/2))
>> end
>
>That example is a little too simple to be interesting. Anyway,
>here is the Ada 95 version:
>
>with Ada.Numerics.Elementary_Functions;
>use Ada.Numerics.Elementary_Functions;
>
>function F (A, X: Float) return Float is
>
> function G (X: Float) return Float is
> begin
> return 1.0-A*X**2;
> end G;
>begin
> return Sin(G(2.0*X))-Cos(G(X/2.0));
>end F;
>
>Yes, it is somewhat wordier but not excessively so.
>
I've heard some good things about Ada. However, I've never seen any Ada code
until now. Looking at the example above though.... for simple mathematical
manipulations at least... I think I'll stick with Fortran. I find the above
Ada example to be a bit too verbose and "non-natural" to read. Is the rest of
the language like that?
Dan :-)
Dan Tex1
>
> REAL, DIMENSION(l,m,n) :: a,b,c,d,e,f, etc etc
>
>--
>Stuart Norris nor...@mech.eng.usyd.edu.au
I generally prefer:
REAL a(m,n), b(l), .....
However... I do like having the option to do what Stuart has shown when it
seems appropriate. It can certainly make altering code much simpler when
all one wants to do is change the arrays dimensions.
Dan :-)
Kenneth G. Hamilton
>
> I was at first astounded that F90 uses the un-abbreviated word
> "dimension" but abbreviates "length" to "len". Might we have "dim" in
> F2000?
Sorry, Mike, but we already have DIM. Check the back of a manual -
it's the positive difference function, one of those obscure library
elements.
Kenneth G. Hamilton
>
> Fortran programmers are better human beings then C programmers, for
> whom x**y is
>
> #include <math.h>
>
> pow(double x, double y);
Funny that you should mention exponentiation. Have you seen how
C does X**I ? They have to cast I as a "double", and then call "pow".
The result is that, instead of a fast repeated-multiplication trick
(one discovered by the Chinese several thousand years ago), they
wind up calling a double precision logarithm and exponential.
ROFL!
Jim Klein
Jim Klein
Richard Maine
> >]I have wondered why the ALLOCATABLE keyword is necessary
> >]for allocatable arrays....
> If you had a subroutine,
>
> subroutine foo(w,n) ! proposed Fortran syntax
> real :: w(:,:),x,y(n),z(:,:)
>
> the dimensions of w would be determined by the program unit
> calling the subroutine, and z, which is not an argument, would
> be allocatable. So I think that with the proper rules, the declaration
> is not ambiguous.
So you would disallow allocatable dummy arguments (there being no
way to declare them)? This would make many people unhappy. The
TR allowing them just recently got approved (and I see NAG has
already implemented it). There were lots of requests for such
a feature.
If dummy arguments can be allocatable, then it looks to me like you
still have an ambiguity here.
--
Richard Maine
ma...@altair.dfrc.nasa.gov
Martin Ambuhl
It might help if we get this right. Bashing languages without an
exponentiation operator is fine. We've been doing it for a long time;
much longer than C has been around, in fact. Nonetheless, the bashing
should not be uninformed.
Michael Kagalenko is of course wrong. 'pow(double x, double y);' is a
declaration of some function returning an int. It is neither a legal
invocation of any function, nor a legal declaration of the <math.h>
pow() function. The legal form of the invocation is 'pow(x,y)', and the
legal form of the declaration is already included from <math.h>.
Similarly, Kenneth Hamilton is wrong. There is no requirement that
pow() use a logarithm and exponential operation in this situation.
This is a purely quality of implementation issue. Just as the Fortran
'**' operator need not do such a silly thing. I suggest Kenneth
Hamilton get a decent copy of the math library before trying to use C.
The only "ROFL" is that he would decide to engage in uninformed
bashing.
Ron Shepard
<mam...@earthlink.net> wrote:
>Bukic wrote:
>> Do shortcuts such as
>>
>> i++ = ++j ;
>>
>> present in C/C++ really improve readability?
>
>Probably not. It is not legal code in C or C++. And there is no such
>language as C/C++, unless you just invented it so your example would be
>legal somewhere.
Obviously he meant "==" instead of "=". ;-) I think in C that any random
sequence of characters is, at most, one keystroke away from being legal
code, and usually there are several different single keystrokes that can
be used to statisfy this statement.
$.02 -Ron Shepard
ess...@ix.netcom.com
> >> Fortran can also be fairly terse, if you just use the f77 way:
> >>
> >> function f(a, x)
> >> g(x) = 1-a*x**2
> >> f = sin(g(2*x)) - cos(g(x/2))
> >> end
> >
> >That example is a little too simple to be interesting. Anyway,
> >here is the Ada 95 version:
> >
> >with Ada.Numerics.Elementary_Functions;
> >use Ada.Numerics.Elementary_Functions;
> >
> >function F (A, X: Float) return Float is
> >
> > function G (X: Float) return Float is
> > begin
> > return 1.0-A*X**2;
> > end G;
> >begin
> > return Sin(G(2.0*X))-Cos(G(X/2.0));
> >end F;
> >
>
> I've heard some good things about Ada. However, I've never seen any Ada code
> until now. Looking at the example above though.... for simple mathematical
> manipulations at least... I think I'll stick with Fortran. I find the above
> Ada example to be a bit too verbose and "non-natural" to read. Is the rest of
> the language like that?
It gets worse exponentially -- a few years back I saw a rotational dynamics problem
OOPed in ADA and in a "Fortran style**" ADA -- thirty pages of code vs page and a
half, that would've shrunk further had it been in Fortran... Just like a picture
is worth a thousand words, so are the little parallel code snippets that should
periodically be shipped to disciples elsewhere... after all, seeing is believing!?
** Before giving in to the packaging urge and start hiding everything in sight in
where_in_hell_is _that damn_thing_package. Oh yes, they love verbosity -- you're
lucky if you can find some actual code here and there...
--
Dr.B.Voh
-----------------------------------------------
Modeling * Simulation * Analysis
http://www.netcom.com/~essoft
-----------------------------------------------
ess...@ix.netcom.com
> function f(a, x)
> g(x) = 1-a*x**2
> f = sin(g(2*x)) - cos(g(x/2))
> end
>
> Some would say that you shouldn't use the statement-function, should use
> explicit typing, longer names, and maybe more hype-talk.
>
> But I think the above is the best, even if that means agreeing with C++
> advocates. I think the "verbosity rationale" is coming from CS types :-)
Agree**N!! My kind of code style exactly -- straight to the point and
without giving a damn if the milkman can read it... Correction, though --
you're not agreeing with C++ers, more like the other way around. That
function was legal long before C++ was born.
--
bv
Mike Silva
stinkbomb into comp.lang.ada. Is this something EFPK?
Werner Schulz
>>An array is a generic data type and should be declared as such, taking two
>>parameters, the type of its elements and a rank declaration, something
like
>>this
>>pseudocode:
>> ARRAY( REAL, rank=2) :: x
>> ARRAY( person ) :: people ! person is a user-derived datatype,
>>implicit rank=1
>>(Yes, bounds are missing but I just want to get the idea across.)
>
>But, I really consider the bounds (at least) of an array to be an attribute
>of the variable, not a part of its type. If not, then an allocatable array
>would have different *type* every time you deallocated it and allocated
>again with different bounds. Try to statically type-check that!
I never said nor implied that the bounds of an array would be part of the
type!
That would be disastrous.
BUT, and that was my main point which obviously did not come across,
an ARRAY is a generic datatype, like POINTER, TABLE, LIST, TREE,
STACK, QUEUE, etc., and my notation would provide a uniform syntax for it:
ARRAY(real) :: X
POINTER(real) :: X
TREE(real) :: X
etc.
That IS my aim.
Since the bounds of an array, in the most general declaration, are a
run-time
property, then they should be set in an initialization statement. That is
maybe not quite
as convenient as current Fortran, but I rather go for the principle than for
too many
exceptions from the rules. Yes, it does introduce a little bit of redundancy
in the
declaration, and then so be it:
ARRAY( real, rank=2) :: X = ARRAY%allocate(1:10,-5:5)
ARRAY( real, rank=2) :: X = (/ ... /) ! array constructor
! in line with current user-derived TYPE syntax
! this array is allocatable by default
! or even a redundant shorter form
ARRAY( real, rank=2) :: X(1:10,-5,5)
>Also, where would you specify the bounds in the above syntax? I can't
>think of any reasonable place that both: associates the bounds with each
>variable individually; and is not redundant with the description you've
already
>given.
>
>Besides, I often want to declare related variables on the same statement
>even though they have differing ranks:
>
> REAL :: A(10), B(10,20), C(20) ! A.dot.B yields a C
Yes, a matter of taste. I don't like it very much myself since I rather
declare
them separately:
ARRAY(real) :: A(10) ! what is A comes here
ARRAY(real) :: B(10,20) ! B's meaning
ARRAY(real) :: C(20) ! C = A x B where C is the blablabla
Much better for documentation. Even better, of course, to use parameters for
the bounds.
>>Also, pointers are a generic datatype and should be declared in a similar
>>way.
>>And in one swoop, it is very easy to declare an array of pointers or a
>>pointer to an
>>array:
>> POINTER( ARRAY(real, rank=1)) :: p ! pointer to an array
>> ARRAY( POINTER(real), rank=1) :: ap ! array of pointers to real
>>variables
>>
>>None of the F90 detours to get these things out are needed.
>>Pointers(Pointers(...)) is not allowed.
>
>Well, I take the rather radical position that pointers should be removed
>from the standard entirely. So it's hard for me to work up any enthusiasm
>for any different ways of treating them.
I don't share your radical position on pointers, sometimes they are very
very
useful. Though I agree that F90/95 and esp. F200x make quite a number of
uses unnecessary and that is good so. Because in those cases pointers are
only used because allocatable arrays are not available. But try to write a
balanced
tree without pointers. It's a much more complicated job without pointers.
And not
necessarily more efficient.
What I would like to see in F200x is the abolition of the UNDEFINED state
for
pointers and some necessary changes, a trivial example but it demonstrates
the point:
POINTER(real) :: p, q
ALLOCATE(p)
p = 1.0
q => p
DEALLOCATE(p)
Here p should only be nullified but not free the memory that q is pointing
to. q has
an equal right to the target. That would be much safer. It also implies
garbage collection.
That would make Fortran even better. Not in real life, but in programming I
want somebody
else to do the dirty work of cleaning up the memory ...
>> <SNIP>
>>Why can't we have syntax for overloaded functions like this:
>>
>>module X
>>contains
>> FUNCTION(T), PUBLIC :: "+"(a,b) result(c)
>> T, intent(in) :: a, b ! T is some type declaration
>> T :: c
>> ! some operation with a and b
>> END FUNCTION "+"
>>end module X
>
>This is called parametric polymorphism (at least, this is one of the
>things parametric polymorphism does). I like it. I still think it should
>be considered more important to include into the standard than OOP.
<a lot of snip>
While agree srongly with you about generic procedures (and classes including
constrained genericity, I would just write T<= ORDERED to convey the
constraint
and maybe inheritance) that again was not my point here. Just replace all
occurences of T with REAL and compare the F90 syntax with mine. In any vote
on
this I would bet that F90 syntax looses.
Actually the INTERFACE syntax in F90 is virtually superfluous everywhere.
Everything
can be done much more concisely using attributes.
The point is that F90/95/200x just does not extend the variable declaration
syntax to procedures, modules, etc. Procedures also have attributes,
PUBLIC/PRIVATE is a very obvious one, PURE etc comes also to mind.
It seems so obvious to write
FUNCTION [, attributes] :: func-name( arguments )
Another example: The declaration of abstract (or deferred) class procedures
in F200x is done this way:
PROCEDURE [, PASS_OBJ] :: F => NULL(FOO)
where
FOO is declared elsewhere when all that is needed is to write
FUNCTION, ABSTRACT :: F(X)
real, intent(in) :: X
! no body of executable statements, only dummy arguments
are declared.
END FUNCTION F
inside the class declaration. This conveys immediately the kind of function
that is deferred while the earlier F200x draft declaration is nearly empty
of any meaning.
What kind of procedure? Function or subroutine
Does the procedure have arguments? How many? What are their types?
Why refer to a function declared elsewhere?
Isn't it very strange syntax? NULL(FOO)
Why do we need => here?
Nothing of substance is conveyed, one has to look elsewhere for any kind of
important
information. I would say this a very good example of how NOT to design a
language.
Another example: the IEEE handling is leading to the addition of some new
syntax for
USEing modules:
USE [,<intrinsic-attr :: ] module_name
Now, why can't we have this syntax extended to include PRIVATE/PUBLIC
use of modules? I have suggested this quite a while ago (97-143, if I
remember
correctly, and discussed on comp-fortran-90 mailing list) but nothing came
of it.
So what we are going to have in F200x is a further spread of inconsistent
syntax. And few seem to care ... Good night, Fortran.
Cheers,
Werner Schulz
Computer Consultant
Tessella Support Services plc (www.tessella.co.uk)
James Giles
Werner Schulz wrote in message <79vrlh$fku$1...@uranium.btinternet.com>...
...
>I don't share your radical position on pointers, sometimes they are very
>very
>useful. Though I agree that F90/95 and esp. F200x make quite a number of
>uses unnecessary and that is good so. Because in those cases pointers are
>only used because allocatable arrays are not available. But try to write a
>balanced
>tree without pointers. It's a much more complicated job without pointers.
>And not
>necessarily more efficient.
See the recent exchange on the comp-fortran-90 mailing list. There also
I had stated that I would not use pointers very much (or at all) if the restrictions
on ALLOCATABLE arrays went away - especially if some form of reallocate
were provided. Someone posted a challenge to write a tree sort routine such
as one on the unicomp web site without pointers. I rewrote the unicomp one
almost mechanically. It took about 15 minutes. And most of *that* time was
deciding not to clean up a bad style choice in the original code (they were passing
an argument to a procedure implicitly by making it a global rather than making it
an explicit argument). It's not all that hard.
In that case the result was not much more complex without pointers at all, and
it was more efficient since it got rid of most of the calls to the system's (or
the support library's) memory manager to allocate nodes on the tree. Pointers
should never be used (and the language should never require their use) unless
aliasing is a deliberate part of what you're trying to do. That should be very
rare (I can't remember the last time I needed to do so).
--
J. Giles
Martin Ambuhl
Actually, I find that C++ programmers range toward rather than away from
verbosity, but I could have a bad sample.
The code above has an important feature unremarked thus far. In
standard C or C++, the 'g(x) = 1-a*x**2' line would need to be defined
outside the function body. That is, there is no such thing as nested
functions in C or C++. This can be a pain at times, and is something
not only Fortran but Pascal did better. In those rare C implementations
that provide such a non-standard non-portable feature, such as GCC, it
is often done with more flexibility than in Fortran, but that isn't
really important.
robert...@my-dejanews.com
ess...@ix.netcom.com wrote:
> It gets worse exponentially -- a few years back I saw a
> rotational dynamics problem OOPed in ADA and in a
> "Fortran style**" ADA -- thirty pages of code vs page
> and a half, that would've shrunk further had it been in
> Fortran...
Be careful with comparative examples of this kind. They
almost always involve apples and oranges comparisons of
differing styles, and very often involve comparisons of
well written programs with badly written ones, which
prove nothing.
Having used both Fortran and Ada extensively, I would say
that the more powerful abstraction features of Ada are
likely to be significantly valuable in improving the
reliability, readability and maintainability of any large
numerical code, assuming competent programming in both
language domains.
I also think that the fact that Ada has a well thought out
model for floating-point semantics (Fortran has none) can
be of vital importance in numerical codes that are at the
level of carefully worrying about error propagation. It is
impossible to write such code in Fortran in a formally
portable manner.
Examples of snippets, "look at these 5 lines in language X,
how would you do this in language Y" are almost always
bogus. One has to look at large examples, well programmed.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Robert I. Eachus
> Fortran can also be fairly terse, if you just use the f77 way:
function f(a, x)
g(x) = 1-a*x**2
f = sin(g(2*x)) - cos(g(x/2))
end
> >That example is a little too simple to be interesting. Anyway,
> >Here is the Ada 95 version: {reformatted for clarity}
with Ada.Numerics.Elementary_Functions;
use Ada.Numerics.Elementary_Functions;
function F (A, X: Float) return Float is
function G (X: Float) return Float is begin return 1.0-A*X**2; end G;
begin return Sin(G(2.0*X))-Cos(G(X/2.0)); end F;
Looked at this way the difference in size is obviously due to
requiring all declarations to be explicit, and some added reserved
words (begin and return). Of course, you might want to use (Fortran)
double or (Ada) Long_Float instead. In the Ada version you just have
to add Long_ in six places (and the compiler will scold you if you
miss one) while in Fortran you have to replace implicit declarations
with explicit declarations and hope you don't miss one.
There should be no difference in generated code between the two
versions, so the tradeoff is the traditional Ada tradeoff of more
required text to reduce errors and make maintenance easier. If you
don't care about maintenance, use APL which is even terser than
Fortran. I do.--I find that I program in four languages consistantly,
of all the languages I know: Ada for anything that needs to be read or
maintained, SQL for database queries, csh for shell scripts and APL
for exploratory data analysis. (Please, no arguments about csh versus
sh, bash, or tsh. I use all of them, but my job requires mostly csh.
Similarly, I prefer ODBC for embedded database access, but most of my
database access coding is in the form of standalone scripts.)
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
Christoph Nahr
>That example is a little too simple to be interesting. Anyway,
>here is the Ada 95 version:
>
>with Ada.Numerics.Elementary_Functions;
>use Ada.Numerics.Elementary_Functions;
Unashamed off-topic question: Why exactly do you have to write *two*
lines to use *one* Ada library?
Clumsy attempt to make this question on-topic: After all, Fortran
90/95 only has the USE statement and seems to do fine. :-)
--
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
Dan Nagle
Roughly,
In Ada, 'use blah' means use the definitions within the package blah
(package = module in Fortran-speak).
'with blah' means link with library blah.
--
Cheers!
Dan Nagle dna...@erols.com
bg...@my-dejanews.com
> > Fortran can also be fairly terse, if you just use the f77 way:
>
> function f(a, x)
> g(x) = 1-a*x**2
> f = sin(g(2*x)) - cos(g(x/2))
> end
>
> > >That example is a little too simple to be interesting. Anyway,
> > >Here is the Ada 95 version: {reformatted for clarity}
>
> with Ada.Numerics.Elementary_Functions;
> use Ada.Numerics.Elementary_Functions;
> function F (A, X: Float) return Float is
> function G (X: Float) return Float is begin return 1.0-A*X**2; end G;
> begin return Sin(G(2.0*X))-Cos(G(X/2.0)); end F;
>
> Looked at this way the difference in size is obviously due to
> requiring all declarations to be explicit, and some added reserved
> words (begin and return).
Yes. Note that the full-fledged Fortran 95 version with explicit
declarations and an internal procedure replacing the statement
function reads:
REAL FUNCTION F (A, X)
IMPLICIT NONE
REAL, INTENT(IN) :: A, X
F = SIN(G(2.0*X))-COS(G(X/2.0))
CONTAINS
REAL FUNCTION G (X)
REAL, INTENT(IN) :: X
G = 1.0-A*X**2
END FUNCTION G
END FUNCTION F
which has the same number of lines as my Ada version did before
Robert Eachus reformatted it. And I'll reiterate that this example
is too simple to be interesting, in that it is not representative
of most numerical analysis code. Statement functions are not *that*
common in practice, and subprograms tend to be longer (which makes
IMPLICIT NONE more valuable than in this example).
One thing this example shows is that Fortran is actually among
the more verbose languages out there. The verbosity was gained in
recent revisions of the language, and comes from features added to
make debugging and automated checking easier. On the other hand
Fortran 90/95 added features that promote higher code density,
in primis array operations. This corresponds to what Robert Dewar
has called a "higher level of abstraction"; I'm not sure whether he
had Fortran 77 or Fortran 95 in mind when making his claim that
Ada had an advantage on that count. (And I won't go into the merits
of that claim here.)
In my book, terseness is OK when a program unit is short enough that
I can contemplate it in its entirety in my mind. As soon as it grows
beyond the point where I need to keep written notes, explicitness
begins to win (i.e. I might as well make sure that my notes are
thorough; and if the compiler can understand them and make good use
of them in its diagnostics, so much the better).
>
> There should be no difference in generated code between the two
> versions, so the tradeoff is the traditional Ada tradeoff of more
> required text to reduce errors and make maintenance easier. If you
> don't care about maintenance, use APL which is even terser than
> Fortran. I do.
And if you do care about maintenance of Fortran code, you may like some
of the new features, even though they come at the expense of terseness.
Nick Roberts
|If you
|don't care about maintenance, use APL which is even terser than
|Fortran.
And I use Prolog:
g(X,A,Y) :- Y is 1-A*X*X.
f(A,X,Y) :- g(2*X,A,B), g(X/2,A,C), Y is sin(B)-cos(C).
Terse enough for you?
-------------------------------------------
Nick Roberts "The Prophylactic Didactic"
-------------------------------------------
&IknowtheXposting'sgonnaREALLYannoysomeppl:-)
bg...@my-dejanews.com
> >with Ada.Numerics.Elementary_Functions;
> >use Ada.Numerics.Elementary_Functions;
> Unashamed off-topic question: Why exactly do you have to write *two*
> lines to use *one* Ada library?
I'm cross-posting this response to comp.lang.ada, where the question
would have been on-topic (albeit a FAQ).
The answer is: you don't need the second statement ("use") if you only
want to use fully qualified names, as in
return Ada.Numerics.Elementary_Functions.Sin(G(2.0*X)) -
Ada.Numerics.Elementary_Functions.Cos(G(X/2.0));
Likewise, when you only want to import a few selected identifiers
from the with'ed package, you can simply give them shorthand names:
function Sin (X: Float) return Float
renames Ada.Numerics.Elementary_Functions.Sin;
-- and likewise for Cos
One can also do the renaming at a higher level:
package EF renames Ada.Numerics.Elementary_Functions;
-- ...
return EF.Sin(G(2.0*X))-EF.Cos(G(X/2.0));
An additional twist is that you can (indeed must) "with" a package
at the compilation unit level, but are allowed to "use" it only
within more limited scopes.
> Clumsy attempt to make this question on-topic: After all, Fortran
> 90/95 only has the USE statement and seems to do fine. :-)
That's one of the things the committee that developed Fortran 90
tried to keep simple. They were well aware of Ada 83 syntax at the
time.
Whether the adopted solution is appropriate is (as always) debatable.
Suffice it to say that Fortran did not go for the hierarchical naming
scheme of Ada, and that once you remove that feature the distinction
between "with" and "use" becomes blurred. On the other hand, Fortran
offers renaming and ONLY: clauses on the USE statement (and nowhere
else). Also, Fortran defaults to reexporting objects that are visible
by use association within a module; you have to explicitly make them
PRIVATE to prevent this. By contrast, Ada packages won't reexport such
entities unless they've been explicitly renamed within the package.
Fortran lets you put a damper on namespace pollution through ONLY:
clauses on USE statements and through the PRIVATE attribute, while Ada
does that by defaulting to a fully qualified hierarchical namespace
and giving you a couple of ways of creating abbreviations, namely "use"
and "renames". Neither solution is perfect, but both are workable in
practice.
Since this is going to two newsgroups whose readers need not all be
familiar with both Ada 95 and Fortran 95, a few examples may be
useful.
! Fortran -- Ada
MODULE inner package Inner is
PUBLIC
REAL :: a, b, c A, B, C: Float;
END MODULE inner end Inner;
with Inner;
MODULE middle package Middle is
USE inner, ONLY: a, d => c A: Float renames Inner.A;
D: Float renames Inner.C;
PUBLIC
INTEGER :: c C: Integer;
END MODULE middle end Middle;
with Middle;
MODULE outer package Outer is
USE middle use Middle; -- optional
PRIVATE
PUBLIC :: c C: Integer renames Middle.C;
LOGICAL :: b B: Boolean;
END MODULE outer end Outer;
There. I hope I got it all right (my Ada is a bit rusty). If not,
someone will undoubtedly correct me. The point is that both languages
offer comparable facilities, but there are differences of detail.
I'm not really interested in passing judgment on which is better.
Give that apple to Paris, not to me.
Note that in the example above, INNER exports A, B, C;
MIDDLE exports INNER's A and C (renamed D)
and MIDDLE's C;
OUTER exports OUTER's B and MIDDLE's C.
William Clodius
>
> Hello,
>
> Roughly,
>
> In Ada, 'use blah' means use the definitions within the package blah
> (package = module in Fortran-speak).
>
> 'with blah' means link with library blah.
I don't believe you are correct on this point, although I wish this were
cross posted to comp.lang.ada to be sure. I believe "with" in Ada
roughly parallels the use of "with" in Pascal.
In Ada, I believe "use" gives you access to the definitions within a
package, but, unless accompanied by with, most useages of the package
definitions (operators and perhaps type definitions are exceptions) must
be prepended with the package name in a manner similar to structures or
Fortran's derived types, i.e. if package y defines public variable x
then in the scope with a simple
use y;
you must type
y.x = ...
to assign a value to x defined in y, but in the case
with y;
use y;
the "y." may (must?) be elided, i.e.
x= ...
can be used to assign a value to x defined in y. This is a tradeoff
between compactness and verifibility. Having the package name
immediately associated with the entity means it is easy to determine
where to find the appropriate package (documentation) for the entity.
This is particularly useful for large codes maintained by large teams.
But having the package name immediately associated with the entity
requires more typing and does make reading in the absence of problems
more complicated, i.e., is preferred for simple code.
Because Ada was designed with an emphasis on large code projects its
default is to emphasize documentation.
Fortran's simple use is roughly equivalent to combining Ada's use and
with. Fortran's use with an only clause also allows determining (less
directly) from the text the appropriate module (i.e., documentation) for
the entity. Fortran's module system has a greater emphasis on
programming in the small.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: wclo...@lanl.gov
Randy MacDonald
>
> > Fortran can also be fairly terse, if you just use the f77 way:
>
> function f(a, x)
> g(x) = 1-a*x**2
> f = sin(g(2*x)) - cos(g(x/2))
> end
>
> > >That example is a little too simple to be interesting. Anyway,
> > >Here is the Ada 95 version: {reformatted for clarity}
>
> with Ada.Numerics.Elementary_Functions;
> use Ada.Numerics.Elementary_Functions;
> function F (A, X: Float) return Float is
> function G (X: Float) return Float is begin return 1.0-A*X**2; end G;
> begin return Sin(G(2.0*X))-Cos(G(X/2.0)); end F;
>
>Fortran.
An APL myth: APL is not maintenance-friendly.
one should note that the "inline" function has precedence in APL, in
what was termed alpha-omega notation, and which currently exists in
the form of "dynamic functions" in at least one APL, and in the J language.
f <- { -/1 2 o. a. {1-a.×w.*2} w. × 2 0.5 }
(a. - left argument; w. - right argument; o. - circular function }
Thing is, this in many ways reads better than the FORTRAN, and much
better than the Ada.
..and APL for exploratory data analysis.
this, of course, should not promote the myth that APL is only useful
for exploratory data analysis. As a maintainer of APL systems for over
15 years, where maintenance tools can be crafted WITHIN the language, I
would say that APL is the solution to any maintenance problem it creates.
--
|\/| Randy A MacDonald |"We ARE the weirdos, mister!"
|\\| ra...@godin.on.ca | Fairuza Balk "The Craft"
BSc(Math) UNBF '83 | APL: If you can say it, it's done.
Natural Born APL'er | *** GLi Info: in...@godin.on.ca ***
I use Real J | Also http://www.godin.com/godin/
------------------------------------------------<-NTP>----{ gnat }-
Randy MacDonald
>Robert I. Eachus wrote in message ...
>|don't care about maintenance, use APL which is even terser than
>|Fortran.
>
>
>g(X,A,Y) :- Y is 1-A*X*X.
>f(A,X,Y) :- g(2*X,A,B), g(X/2,A,C), Y is sin(B)-cos(C).
>
>Terse enough for you?
nope....
f <- {-/1 2 o. a. {1-a.×w.*2} w. × 2 0.5} -- APL with dynamic functions
Dan Nagle
William Clodius wrote:
>
> Dan Nagle wrote:
<snip not quite right Ada info>
This is what happens when I try to understand the ARM instead
of a textbook. :-) I'm still learning Ada.
My compiles fail if I don't have "use", my links fail if I
don't have "with"...
Thanks for straightening this out.
>
> I don't believe you are correct on this point, although I wish this were
> cross posted to comp.lang.ada to be sure. I believe "with" in Ada
> roughly parallels the use of "with" in Pascal.
Actually, there is a thread in comp.lang.ada on this topic right now.
>
<snip rest of info>