# Programming languages for geophysicists
I was recently asked which programming
language a university should require their
geophysics graduate students to learn. Here
was my reply.
If I had to pick one language, I'd recommend
Java. For an excellent appreciation of Java
as a teaching language, see Doug Lea's web
page at
http://g.oswego.edu/dl/html/javaInCS.html
A second-place choice would be C with some
exposure to C++. But if students know Java,
they can pick up C/C++ on their own.
If I were teaching programming to students
that had never programmed before, I'd use
Python as a learning language. You won't
waste time explaining tricky syntax. Python
supports both procedural and object-oriented
approaches. If I can get Java to compile, it
usually does what I wants. The same is true
of Python, but it usually compiles the first
time.
Do not require Fortran. I have not written
Fortran on the job for ten years now.
If a teacher is using Mathematica in class
exercises, then teach what is needed to do
the exercises, as you go. Mathematica is a
software application, not a language. The
same is true of Visual Basic and Perl.
(Test: if only one "compiler" exists, then
the language probably does not have a
specification, or even a grammar.)
If faculty do not consider programming
languages worth learning, then students will
probably follow their example.
I now consider formal computer science to be
essential training for any scientist who
expects to program as a part of their career.
Make them take courses on programming and
read programming books. They will not have
time to learn by trial and error, as most of
my generation did. Students need courses in
style, data structures, algorithms,
encapsulation, object-oriented programming,
functional/generic programming, and software
patterns. Students need concepts more than
the mechanics of any single language.
Do not choose a language because it is
"realistic" for "real projects" in the "real
world." Those criteria change. Teach them
principles of programming that are likely to
be around for a while. The language is often
unimportant.
I personally wish I had been taught
programming in Scheme (a Lisp dialect), using
the freshman MIT book "Structure and
Interpretation of Computer Programs," by
Abelson and Sussman. No language has given
me more insight into what a compiler really
does.
Teaching C++ is tricky because you must
identify
a safe minimal subset.
The best way to improve one's style in
C++ is to write more Java.
Java is so easy to debug that I almost never
use a debugger. Memory management is the
source of most bugs in C/C++. Java prevents
you from writing outside the bounds of an
array, prevents you from casting a reference
to the wrong type, prevents mischief with
pointer arithmetic, prevents you from reading
uninitialized variables, prevents you from
allocating too little space for an object,
prevents you from leaking unfreed memory,
prevents bad assumptions about the size and
byte order of primitive types, and so on.
Those are the kind of problems that require a
debugger and cost you days. The hardest
problems to debug in Java are concurrency and
race conditions with threads. Of course,
most users of C/C++ never attempt threads.
Performance should be for advanced
students, not novices. Two thirds of our new
processing system is in Java. We use C++ if
we need "machine code," mostly legacy code.
There is not a single line of Fortran. We
have seen Java code run 20% FASTER than
equivalent C code. The latest Java virtual
machines from Sun and IBM profile, optimize,
and recompile during runtime.
Bill Harlan
June, 2001