[Beowulf] g77 limits...

[Robert G. Brown]

On Thu, 23 Feb 2006, Greg Lindahl wrote:

> On Thu, Feb 23, 2006 at 01:54:43PM -0500, Robert G. Brown wrote:
>
>> Column
>> indentation and continuation rules suck (if they're still there).
>
> Robert,
>
> If you are 15 years behind in knowing what's in Fortran, maybe you
> shouldn't write so many postings about how it's limited? Free form
> source format was added in Fortran90.

Well, a lot of it IS tongue in cheek, right;-)?  Sprinkled with smileys?

Sigh.  I should have known better than to actually start to dis on
fortran -- again:-)

And besides, as I noted at the VERY beginning when I was ASKING about
fortran -- the fortran compiler that most of the physics code I'm
interested in is written in these days is g77, not f90 or g95.
Physicists at least are really, really slow to port their legacy
sources.  You must have encountered cernlib by this point in time -- one
of my few recent brushes with fortran at all was trying to get cernlib
to actually build into an rpm.  If you've looked through it and haven't
shuddered, well, you're just shudder-proof.

IOW, the sources I've looked over -- sources still in use and used as
the basis for a whole lot of currently functional code -- are still
indented just like F IV.  Heck, a lot of fortran source in my possession
-- not my own, stuff in current use -- still uses 10 CONTINUE to
terminate loops, goto statements all over the damn place, poor
indentation -- it's just plain awful to read.

> One way to spot a good compiler engineer is their attitude about
> Fortran; if they like that it's easier to generate good code for
> Fortran, they're a keeper.
>
> Along that line, this example was a good one:
>
> for(i=1;i<=N,i++)
>  {
>    do_some_work(&i);
>  }
>
> In Fortran, it's illegal to modify the loop index in the body of a
> loop. In C, it's legal, so this loop will be pessimized unless
> do_some_work can be inlined or otherwise proven to not modify i.

Yeah, yeah, I know.  I even said so in a previous post, sort of.
Fortran is a lot easier to optimize BECAUSE it has fairly rigorous,
fairly conservative rules.  On the other hand, think of all the magic
you can do within the C loop and for() rules -- dangerous magic, sure,
but heck, if do_some_work decrements i by one for any value of i you'll
learn about it soon enough and won't make THAT mistake anytime soon
again.  Fortran is just no fun;-)

OK, OK, enough kidding around...:-)

Truthfully (since you're dragging the TRUTH out of me instead of some
more elbow-poking fun:-) I think that while most programming language
decisions are made on a basis that completely ignores them (see below),
there are trade-offs associated with all of the programming languages
and that no language is "perfect".  All languages, on the other hand,
tend to be "good enough" to program most tasks that they are used for.

Some are stricter, do more type checking, protect the programmer against
their own mistakes, force the programmer to use a style that can be
automatically optimized for them at the compiler level more easily,
match up better to "formula translation" or some other desired base
procedural/object oriented/list oriented paradigm.  And I don't mean
just fortran -- C++ has many of these advantages as well.  Pascal was
downright fascist about types and declarations, the two or three times I
coded toy projects in pascal before I ran from the room screaming Sieg
Heil and burned my pascal manual as the object of demonic mind control
that it was.

Then there is object support -- nonexistent in fortran when last I coded
in it, absent altogether in most of the code we're looking at messing
with, and it doesn't SOUND like it is particularly easy to use real
structs/objects even in f90 or g95 or gfortran (a thing that I'll be
figuring out one way or the other soon enough, sigh, and I freely ADMIT
my ignorance here).  Either way, OO support is strong in C++ and python
and some other OO languages and (in my opinion) perfectly adequate and
well-balanced in C.

Then there are languages -- well, there is C -- with LESS of all of the
above -- less strict rules, more freedom, more danger to the programmer,
more accessible power, harder to optimize at the compiler level, perhaps
easier for the USER to optimize as there isn't a lot of room between C
and assembler.  The ability to play fast and loose with types (giving up
strict type checking, mostly), the ability to play pointer magic (and
giving up the ability of compiler or runtime environment to check array
bounds and learning to live with and debug segment violations as a
matter of course), and so on.  Trade offs, not absolutes.

And really, there are still more languages -- list processing languages,
scripting/interpreted languages (object structured e.g. python,
relatively unstructured e.g. perl) that are perfectly reasonable things
to use to program different things.  MOST problems CAN be programmed in
ANY of these languages, with varying amounts of pain and efficiency.
However, it is important to remember that the pain is SUBJECTIVE and
likely to be different per human based on their very personal history,
skillset, experience, and that most programmers -- I mean physics
postdocs and grad students -- are blissfully ignorant when it comes to
program efficiency or even numerical "problems" associated with digital
computing. Fortran means just plain translating formulas into code.
Nothing to it.

That is, the way most people REALLY choose the language used to program
any given problem is to consider:

a) the languages they know -- very few people will willingly learn a new
language to solve a problem if they think there is ANY way they can
solve it in a language they already know, for obvious reasons;

b) the ones they have available -- if APL is your very favorite language
and perfectly suited to a problem, you're SOL these days. [Well,
actually you aren't, according to google -- even APL is still alive and
kicking and available, build ready in (of course) C-source form for
linux.  Whoda thunk it?];

c) how much you "like" the languages you know, which languages suit your
personality, which languages you're "good at"; and sure, last and least:

d) which language actually suits the problem "best" for objective
reasons associated with program design, which is precisely last on most
people's list.  And honestly, in some sense it makes SENSE that it is
last and it BELONGS last.  a-c are really a bit more important in the
cosmic scheme of things unless you have lots of time to learn languages
and lots of money to pay for them and the time you spend learning them,
or unless there is a large payoff for using the right language even if
you have to learn it to do so.

Now, if you did a really careful survey of grad student/postdoc/faculty
programmers the world over in the academic sciences, I think that you'd
find that a disconcertingly large fraction of them have actually used
exactly one programming language to do any real (paid) work -- fortran
-- learned (more or less) on the job while working under the direction
of a dissertation advisor who gave them a bunch of -- fortran -- code to
study and modify.  This even describes me well enough as of twenty or so
years ago.

Sure, some of them took courses in programming (I did) and have written
up a few assignment programs in C++ or java or the language du jour in
computer science departments, back when they were undergrads (PL1 and
hey, Fortran in my case), but these aren't computer scientists and
programming a dozen "hello world" class homemork projects in C++ doesn't
make you a C++ programmer good enough to stand up to your advisor and
point out that C++ is a much better language than fortran for some given
application.

I don't have to do such a survey -- I'm surrounded by dozens of people
just like this, awash in a sea of fortran legacy code, most of whom
never took the step that I took and actually learn a second (and third,
and fourth, and...) language. Lots of them have literally never coded in
anything else, not even as undergrads.

You, on the other hand, probably know a dozen programming languages and
are probably fluent in three to five or even more.  Noting that it's
hard to BE "fluent" in more, as one has to use them a LOT to stay that
way and therefore to have ongoing projects that rely on them -- if you
manage it you have my greatest respect.  Heck, you have that anyway,
even if you don't...;-)

So YOU can actually sanely choose a programming language on the grounds
of d) above -- one that best matches a problem -- as long as the one
that best matches isn't one you really don't know, say lisp or tcl or
apl or pl1 (somewhere down there I'm bound to hit one you don't know:-).
Even then, YOU probably know enough languages that learning a new one is
not terribly intimidating so that if you DID need to learn APL for a
given problem you would.

YOU, sir, are a rarity indeed.

MOST of the world's scientific programmers "speak" one language, often
surprisingly badly (as is directly evidenced from examining the code
they produce).  Fortran.

According to rule a) above, if all you have is a hammer, all the world
is a nail.



BTW, although I myself have programmed in many, many languages --
including applications that are completely unsuited for it in good old
APL -- I will freely admit that I have done my damnedest to reduce the
ones I actually use to three -- C for "real programming" of any sort,
perl for sophisticated scripting or C-lite programming, and bash
(because if you do any sysadmin at all you cannot avoid it).

I can intellectually recognize that fortran has (finally) evolved to
where it isn't as nightmarish as it was when I abandoned it, that maybe
by now it is a pretty good language. That it was nightmarish is pretty
clear -- it has changed far more than e.g. C has changed over the same
time period, and a lot of fortran's changes have been to steal
constructs from C that were obviously missing in the language and
obviously necessary.

I can also intellectually realize that C++ may be "better" than C,
although I remain unconvinced.  Ditto I exchange some good-natured
badinage with my friends around here who have written yum in python,
which I refuse to learn, mostly. Nominally because I claim that it is
silly to indicate program blocking STRICTLY with indentation and so on.

However, the REAL reason I stick with C/perl/bash, and eschew python,
and avoid csh, and no longer code -- much -- in awk, and shudder at
pascal, and won't touch C++ or fortran, and run screaming at the thought
of learning lisp is that I'm >>good<< at coding in C and don't >>have<<
to use anything else to do the work that I need to do.  Ditto perl vs
python -- I can code "anything" in perl.  What more than anything can
python code?

It has nothing to do with the merits of the language, really.  We code
in what we know best, until "forced" to do otherwise by some real
inadequacy in the language (as I encountered in fortran vis a vis C long
ago).

That's what makes language discussions fun but also causes them to
inevitably deteriorate into a flame war.  It isn't, actually, a rational
discussion and there is no "right" answer.  If you dis ANY language you
break SOMEBODY'S dolly -- even APL.  If you dis any language when that
language is the ONLY language somebody programs in and you are therefore
by implication assaulting their personhood or insinuating that they must
waste the next twelve months of their life learning a new language to
the point where they are approximately half as proficient in it as they
are in the one they already know -- well, you're lucky if they don't
break your kneecaps with a steel rod, especially if their boss is
listening and apt to take your advice seriously and make them do
it...;-)

This is true even when you are SERIOUS about it -- when the language IS
horribly wrong for the project and they DO need to learn a new one and
start over.  Wear those hard-shell knee pads at any such presentation,
is all I can say...:-)

    rgb

>
> -- greg
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu