CCL: Cleaning up dusty deck fortran and converting to C/C++

 Sent to CCL by: "Perry E. Metzger" [perry]*[piermont.com]
 --Replace strange characters with the "at" sign to recover email
 address--.
 >> I've seen many efforts in my Computer Science professional career in
 >> which people attempted to keep old code alive at all costs -- and in
 >> each case, it ended up costing far more human labor and far more money
 >> than a straight rewrite would cost. Rewriting, using the original code
 >> as a model and as a mechanism for validating regression tests, is
 >> often a superior solution.
 >
 > Alas, I have also seen some very high profile cases where old Fortran
 > codes were discarded in favor of new "object orientated C++"
 codes
 > that still have yet to match the old "legacy" codes they were
 supposed
 > to replace.
 One tip -- we computer science types like the words "programs" or
 "software" or "code" singular. "Codes" generally
 says to us "this
 person isn't a member of the guild" -- if you're a consultant, when
 the client says "codes" is the point at which you start adding zeros
 to your estimate.  "Softwares", by the way, is even worse.
 Sure, you can write really crappy code in any language. However, some
 languages really make it much harder to write good code. Fortran and
 Cobol are at the top of my list for that.
 > Good or bad code can be written in many languages.
 Sure. To quote an old saw in CS, "You can write Fortran in any
 language", and many people have. You can write stuff in C that could
 be written right in Fortran -- no recursion, no data structures but
 arrays, no function pointers, etc. -- and many people who don't know
 better do. You can also use all those things but use them incorrectly
 and end up with a mess. There is never any substitute for knowing what
 you are doing.
 However, people who know what they're doing stay far from Fortran.
 We made used to make fun of people who still wrote in Fortran when I
 was an undergraduate decades ago, and we also said "and they'll still
 be writing in Fortran in 1990 I bet" as though that were an impossibly
 funny joke. Little did we know they'd still be using Fortran in 2005.
 Writing software in Fortran vs. writing software in a language that
 has things like structs, pointers and recursion is like cooking using
 only a small bunsen burner, a dull knife and a cheap aluminum pan,
 versus having a professional kitchen complete with a Viking range,
 knives from Global, good cookware and a 650hp food processor. Yes,
 both will get the job done, but what a difference in the difficulty of
 getting the job finished and the pleasure taken in the task.
 Incidently, proper editors, debuggers etc. are also important, as is
 knowing your way around the OS you use. Know your tools.
 > Besides, rewriting 200,000 lines of Fortran into a new language while
 > simultaneously changing all of the data structures is a pretty darn
 > big task that doesn't result in any publications.
 Yup, but if you know what you're doing it pays a dividend in the
 end. There are algorithms you just can't express in Fortran cleanly. I
 used to do high performance computer graphics work -- you couldn't
 even express your models reasonably in Fortran (though of course
 people often made do anyway). A lot of problems in computational
 chemistry look pretty similar, by the way.
 When I see the circumlocutions people use in Fortran to do what would
 be trivial in a better language -- shudder. It is much like watching
 someone trying to make furniture with an axe. Yes, if you work really
 hard at it, you can produce something -- but it won't work as well as
 using tools meant for the job.
 Sure, rewriting your code won't get you publications, but when you're
 done you can do new things faster. The name of the game, after all, is
 economizing on manpower and getting the computer to subsume more and
 more of your task and to do its work as fast as possible. Failing to
 invest in your tools is pennywise but pound foolish.
 > If I were ever to replace my Fortran code with C I would initially
 > translate and then begin changing some of the data structures as
 > desired within the new framework.  Arrays are still the most efficient
 > data structure for many tasks, but it would be nice to have a few
 > linked lists and some memory allocation once in a while.
 Arrays are rarely the first tool I think of -- or even ever a tool I
 think of. They're fine tools for building other data structures --
 they're often hidden deep underneath the covers of things like hash
 tables and such -- but what you want to be thinking of is
 *abstractions*, not *implementations*. The non-professional thinks
 first of what to implement, the professional thinks first about what
 abstractions to build.
 In any case, I can't imagine writing most software without real data
 structures. If you don't know why you want to be able to build clean
 hash tables, priority queues, search trees, etc., then you don't know
 why your programs are running orders of magnitude slower than they
 need to. The difference between the right and wrong data structure is
 the difference between trying to cut down a tree with a hand saw and
 trying to cut it down with a chain saw.
 --
 Perry E. Metzger		perry]*[piermont.com