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--.
 >> Sadly, the more appropriate languages for this sort of work have become
 >> desperately unpopular...
 >
 > I gotta ask: what languages would you consider most appropriate for
 > this sort of work (computational chemistry calculations)?
 In general, I think it is better to work in strongly typed languages
 which do full run time error checking. Unfortunately, as I said, most
 such languages are now highly unpopular.
 Anyway, any of the Algol descendants (Pascal, Modula-2, Modula-3, even
 Ada) would work quite nicely from the point of view of people used to
 ordinary procedural languages. Unfortunately, compilers for such
 languages are not well maintained these days, because no one cares
 about them any longer. Because of that, C is a reasonable compromise
 for numerically intensive code. The compilers are generally excellent
 and the tools are very good -- but you have to be a damn careful
 programmer not to cut yourself on the sharp edges.
 I wouldn't recommend Java, both because of performance with a VM
 based system for numerical analysis intensive code, and because it
 does not automatically detect numerical overflow/underflow, though it
 does get upset about array bounds violations.
 If your code isn't computationally bound and the slight holes in the
 safety aren't an issue, Java certainly is better for you than C. Of
 course, if you aren't concerned about performance, Python seems even
 nicer. Python is a lot of fun, if a bit odd, but the interpreter is
 very slow. I do not recommend Perl for this sort of thing. (I think
 the bioinformatics people who use it are not using the right tool for
 their job.)
 Believe it or not, I'd actually say that Lisp is a pretty good choice,
 especially the implementations with very good compilers for numerical
 work like CMUCL, SBCL, and various commercial compilers like Allegro
 Common Lisp. Lisp is very alien to non-computer science types, and
 even to many computer scientists, but if you learn it well, it allows
 you to do a whole lot in the way of high quality abstraction -- you
 can write a lot of code very fast, and if you're not using an
 interpreter, the code is often as fast as you can get in any other
 compiled language. Were Lisp not so unloved and so ill supported in
 many environments, I'd push it even harder.
 A word for a moment about tools.
 If you are a cabinet maker, the difference between a good tool and a
 bad tool, and the difference between knowing which tool is good and
 which is bad, and the difference between knowing how to use the good
 tool and not knowing how to use it, all have very obvious impact both
 on the quality of the furniture you build and on how fast you can
 build it. This is entirely obvious.
 However, many computational chemists try to "go cheap" on learning
 about their tools and picking good ones. That means the difference
 between building fast, flexible and maintainable systems quickly, and
 building not so fast, not so flexible and not so maintainable systems
 not so quickly. It is no less obvious with computational chemistry
 than with cabinetmaking that you need to know your tools and know them
 well.
 Computational chemistry is a two part discipline. You really can't
 neglect the computer science side of things any more than you can
 neglect the chemistry side of things. It makes all the difference.
 Perry