From owner-chemistry@ccl.net Sun Sep 25 00:48:24 2005 From: "CCL" To: CCL Subject: CCL: Cleaning up dusty deck fortran and converting to C/C++ Message-Id: <-29292-050925001339-10992-dttFXCZCQ7JFRv3q5So+OA]_[server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Sun, 25 Sep 2005 00:13:33 -0400 MIME-Version: 1.0 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