[Beowulf] g77 limits...

[Robert G. Brown]

On Wed, 1 Mar 2006, Leif Nixon wrote:

> "Robert G. Brown" <rgb at phy.duke.edu> writes:
>
>> As for the python... well, I just plain like delimiters in my code.  I
>> might even use it if the authors of python hadn't imposed two pieces of
>> religion on its users:
>>
>>    No line terminator (e.g. ;)
>>    No {} -- all code grouping MUST be accomplished by indentation.
>
> In braces-riddled languages you have to mark up the block structure
> twice; first with braces for the sake of the compiler, and then with
> indentation for the sake of humans. That's a bit silly and error prone
> in my eyes...

Well, yes, but not exactly.  You have to mark up the braces for the sake
of the compiler, yes, absolutely, but you have some ability to use
JUDGEMENT as to how to indent -- or if. 
i=10;
while (i>0) { a[i] = b[i]; i--; }

(on one line) works just fine and is both readable and reasonably
elegant.  Not that

i=10;
while (i>0) {
   a[i] = b[i];
   i--;
}

is terrible either.

With C code you can also make a judgement on things like nested loops.
I have code where the loops are nested some 8 of 9 levels deep -- sums
over successive angular momentum indices, for example, inside sums over
coordinate indices (sometimes in both position and momentum space).
Nesting levels of 10+ are not unknown.

With C you CAN do

for(){
   for () {
     for () {
... (to many more levels)
                                for(){
                                  and now begin a really long formula HERE where it runs way off the screen
                                }
...
     }
   }
}

Or (as I often do) you can "renormalize indentation":

for(){
   for () {
     for () {
....
/* Note that I indicate a level renorm in a comment leading *
   for(){
     and now begin a really long formula HERE where it doesn' run off the screen
   }
/* and comment the trailing edge as well */                              }
...
     }
   }
}

I actually have quite a bit of code that does this, because the
alternative is to use a 150 character wide tty with tiny characters.
It's still pretty readable and a hell of a lot easier to edit.  And of
course in the OLD days this sort of thing gave fortran hell -- you HAD
to renormalize indentation in really deep loops or you'd run out of
characters in your 66 character working line (card length 80 less the
leading 6 and trailing 8).

So in C (and perl), you can only make an "error" on the braces.  Getting
the indentation "wrong" just makes the program a bit harder to read --
or not.  Might make it a bit easier to read.  Might make it POSSIBLE to
read.  Edge cases, as I said, but not uncommon ones.

For simple 2-3 levels of nesting of loops and conditionals sure, python
or perl or C or Fortran IV or whatever -- all are fine and pretty easy
to read, even with 10 CONTINUE type block terminators (which alas, lots
of people wouldn't use instead choosing to label the next active
statement and ALSO fail to indent... sigh).

Besides, my favorite programming editor (jove) is smart enough to manage
code indentation inside program blocks for C (or perl) automagically and
check for matches of brace pairs, actually making it very easy to ensure
that your code indentation is as it should be.  And then there is
"indent", to come behind with retroactively and make things all pretty
and consistent if you get sloppy while writing, which I don't.

Finally, even with indentation used to denote program blocks there is
some ambiguity, remember -- humans still have to be sure to indent each
successive block CORRECTLY (relative to indentation levels used in prior
blocks) or you can convey the impression of depth B when really the
depth is A.  Indentation blocking is a local process, not global.

But as usual, this is a posteriori justification (on my part) for a
perhaps irrational but quite real preference.  If I'd learned python
first, maybe I would have liked it the other way, but instead following
the PL/1, Fortran, Basic, C route by the time I got to C {}'s were
beautifully sparse and flexible to my eyes and veritably manna from
heaven, especially when teamed up with an emacsoid editor...:-)

Myself, if I were going to write an interpreter/scripting language from
scratch I'd start pretty much from C at this point, add regular
expression parsing in conditionals, create automatic fast data types
capable of managing struct-like structures, and otherwise largely
preserve its syntax, structure, and intrinsic subroutine calls.  And I'd
add a binary exponentiation operator (damn it!  This is the one thing
about C that I miss from Fortran, amazingly enough...:-).

But wait!  That's perl, or damn close.  The biggest gripe I have about
perl is that it's struct support is high mediocre.  Purportedly python
does that much better, while preserving a lot of its other advantages.
Otherwise when I first learned perl I thought I'd died and gone to
heaven.  It is still the language I'd choose to learn and use if I could
only use one language, ever, for everything that had to be done.

One day I'll probably get over it and learn python.  In the meantime I
get way too much pleasure from ribbing my friends (and being ribbed back
in return) over the python vs perl thing.  Remember, this IS duke, and
Seth Vidal (and Icon, and Michael Stenner) ARE all my friends, and yum
IS written -- in python.  Every now and then I threaten to write a
perl-Gtk interface to yum just for the sheer fun of it... and then duck.
Sometimes I even have to run out of the room.

    rgb

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