A Glimpse of the Future of Scientific Programming

Every scientist who has done some programming is familiar with using a compiler: First you write a program in the form of text files containing the source code, and then you run a compiler that reads the source code and…

Every scientist who has done some programming is familiar with using a compiler: First you write a program in the form of text files containing the source code, and then you run a compiler that reads the source code and produces an executable program for the kind of machine you’re using. If you want to change your program, you modify the source code and recompile. This is known as the edit-compile-run cycle, and it hasn’t really changed since the early days of scientific computing in the 1960s, when the transition from assembly language to compiled Fortran began to make computing accessible to a much wider group of users.

A second program development style that many of us are familiar with is the use of interpreters: Instead of compiling the source code to produce an executable program, you directly run an interpreter on it. By eliminating the compilation step, you can develop and test faster. Moreover, interpreters also permit interactive development. The price to pay is performance, because interpreters are usually much slower than optimized executables produced by a compiler. Interpreters have been around for almost as long as compilers, starting with the first Lisp interpreter in the early 1960s.