There is only one problem with interpreted languages, that keep us
from using them in scientific computing; *performance*. That,
however, should be a non-issue in most cases, if the language we
interpret is designed carefully enough.

The absolute majority of scientific computing code deals with repetitive tasks. It can be anything from traversing a set of molecules in a molecular dynamics (MD) program, to approximating the solution to a system of non-linear equations. We usually work with sets of numbers, not single numbers. And we usually work with sets that are either large (matrix multiplication or LU factorization comes to mind), or has a simple relationship (eg. adjacent molecules in an MD simulation).

If the interpreted language provides ways to deal with these set operations effectively, the number of interpreted instructions will be very small, compared to the number of compiled and highly optimized instructions the TONS system will be executing to actually solve the problem.

For example, if the interpreted language provides a `mult`
instruction, that performs a matrix multiplication, the difference
between the performance of the interpreted language, and any compiled
language (*C*, *Fortran*, etc.) will *only* be the overhead
in the virtual machine for recognizing the `mult`
instruction. The real code that executes the
operations is highly optimized machine code in either case.

Thus, a carefully designed interpreted computing language should be able to execute at a speed close to that of a compiled language, for a very large class of problems.

<