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> To send e-mail to subscribers of CCL put the string CCL: on
your Subject:
line>
Send your subscription/unsubscription requests to:
CHEMISTRY-REQUEST#ccl.net>