<div dir="ltr"><br>Hi everyone,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I don't know what the language of the 21st century will be like,<br>

but it will be called FORTRAN.<br>
                        -C.A.R Hoare</blockquote><div><br><br>  I know this was made in a somewhat off-topic thread touching on politics, but I couldn't resist adding my two cents and seeing what other people see from codes these days.  This post stems from a few conversations I've had with people at Yale on development practices and languages, and also from the realization that a university operates quite differently (I think) than research labs or corporations.  Thus, this list is a great way to ping the 'real world' and learn from some different points of view...  <br>
<br>  See, I love Fortran.. or, more specifically, sensible Fortran.  The problem is that there's a <i>lot</i> of nightmare-inducing Fortran code (mostly F77/F66) that is chock-full of things like computed GOTOs, 'equivalence' statements, Hollerith constants, variable names that need their own Rosetta stone to comprehend, etc.  To borrow an image from Douglas Adams, that stuff can be like Vogon Poetry - it's torture to me, plain and simple, but somehow other people love it.  ;-)<br>
<br>  Now, I grew up on C/C++, and I definitely agree that Fortran is going to be the language of choice for codes (in the physical sciences) in the near to mid-distant future, but <i>as</i> a C/C++ guy who has seen more than his fair share of 'object oriented' inspired abstraction where it was most definitely not warranted, I worry a little bit about people leapfrogging from the ancient F66/F77 ways to, "Ooh, someone said Fortran 2003 has lots of OO features!  Let's redesign everything with 34,782 levels of abstraction!".  I cringe at the thought.  On the plus side, as evidenced by the fact that much of the code I see <i>is</i> so old, it seems many developers aren't keen on adopting 'new' things in their language, but on the other, with the size of the projects faced in scientific computing and the increasing importance of multi-threading or even well-designed MPI-based parallelism, <i>lots</i> of people in the physical sciences could benefit from people with a software engineering background... one that <i>often</i> comes with C/C++ familiarty and its assorted demons.  D'oh.<br>
<br>  In terms of the in-house applications I work on, I readily use F90's allocatable arrays and parse tons of command-line arguments, since I figure having flexible codes that are easy for a user to alter without recompiling are worth their weight in gold, and I also tend to use array syntax (sometimes with explicit indices for clarity) to eliminate some loops and make the code more natural in the mathematical sense.  And, of course, I use more descriptive variable names and modules for organizing things.  In terms of the complexity of the data structures and flow, though, I try not to mess with simplicity much - this seems to not only be a half-decent application of the 'KISS' principle, but it also lets people who are not too familiar with F90 still understand what is going on since most things are left relatively unchanged.  The above 'changes' to the F66/F77 base often seem a bit radical to some, so I'd love to know what people see, in general, at other places.  I know some places such as NASA run training classes on the advanced features of F2003 (and even F2008, I think!), and surely the National Labs do, too, but are modern codes taking advantage of such features in any real capacity yet?  (Ex: IBM's XLF already has procedure pointers implemented, so <i>surely </i>someone asked for that?  Is it being used in any open production codes?)<br>
<br>  In other words, what 'era' of Fortran do most people find themselves in, and are things changing?  <br><br>
(PS.  I hope nobody minds the title change -- I figured it was 'different enough' from "Green Computing" to warrant it!)<br><br>Cheers,<br>  - Brian<br><br><br>Brian Dobbins<br>Yale Engineering HPC<br><br>
</div></div></div>