Why ALPAL

Really it's "why use symbolic math programs to develop number crunching software," but these are from the doc_282 in the ALPAL docs (my emphasis).

• First, physics code could be generated and modified to incorporate new physics and features at a much greater speed than occurs with present codes. Such a language would directly foster improvements in the physics models employed, as well as teh numerical methods used to approximate these models. Two reasons point out the need to experiment with numerical methods for a given set of integro-differential equations. First, as a direct consequence of the paucity of mathematical theorems that constructively characterize partial differential equations (PDEs) in general, there is no means of determining what approximation technique will most faithfully capture the solution. Second, in almost all cases, analysis of an approximation technique is limited to idealized linear problems, so the stability and convergence properties of applying a given approximation technique to actual set of PDEs is unknown. Thus, the optimal algorithm for solving any given PDE or set of PDEs is not known, and any tool to aid the computational physicist must be capable of dealing with many different numerical algorithms and methods.
• Second, much of the drudgery and concomitant errors in constructing simulation codes would be eliminated by such a language. Large amounts of uninteresting algebra are associated with both the development of appropriate physical models and the discrete versions of the these models on a computer. If the algebraic work involved could be largely automated, computational physicists could spend a great deal more time doing the physics they were trained to do.
• Third, a more natural way of describing the physics model is possible with such a language. Errors in the modeling and numerical approximation process would become more obvious, thereby reducing the number of errors in the simulation code.
• Fourth, it becomes possible to automate the computation of Jacobian matrices both for linear and nonlinear problems. Not only would this automatic calculation greatly reduce the number of algebraic errors commited for those cases that solve linear systems of equations (with or without a nonlinear solver0, but it would make possible a large number of implicit techniques for situations where it has just not been feasible to use them in the past.
• Fifth, such a language could fulfill the need to optimize the very expensive computation that goes on in simulation codes. While a competent scientis can do a good job of optimizing a simple simulation code, the complexity of this task for large simulation codes is beyond the capabilities of even the most skilled scientist. Moreover, optimizing a code is a mundane task that once again does not reward the scientist in his primary pursuit. Optimization becomes an even more critical issue on non-scalar computer architectures such as the CRAY-XMP or an ultracomputer. A high-level view of how to vectorize and/or parallelize a given algorithm (or meta-algorithm) on one of these supercomputers is crucial so the scientist can substantially improve the cost-effectiveness of a simulation on that computer. In principle, a language like ALPAL can provide such a view.
• Sixth, since the cost of developing simulation codes is great, especially for new machine architectures, this language could be used to dramatically cut development costs. This is true whether a simulation code is being created for a new machine or whether it is being ported from a previously used computer. Experience with vector computers over the past decade at LLNL has taught this lesson well. More recently, some simulation codes have been ported to the CRAY-XMP, with use being made of its distributed computing capability. This porting to a distributed computer has required an even larger investment of manpower. These large manpower development costs will be repeated many times because a great variety of parallel computers are now appearing, and because parallel computing is a far greater technical challenge than even vector computing.
• Seventh, more complete and coherent documentation can be developed with such a language. In fact, a journal-style specification of a code can provide many details that are not generally provided in a journal article about the code. The journal-style specification is expressly designed for readability, wheras the text of a traditional simulation code is not. This is so because it is impossible to express high-level mathematical concepts such as derivatives and integrals together with their numerical approximations in Fortran or any other conventional high-level language.