robison@uiucdcsm.cs.uiuc.edu (05/09/88)
> ... And, anyhow, > any problem which can be stated in a programming language which is (nearly > reasonably, or even not) "mathematical" (or otherwise) can be solved by > any computer which implements that language. The halting problem is specified with mathematics, but can never be solved by our notion of computer. That's why mathematics makes a nice specification language, we can specify the "what" without the "how", even when the "how" is nonexistent. See the "Laws of Programming" paper in the Aug. 1987 CACM for a readable discussion on programming languages vs. specification languages. - Arch D. Robison
mccaugh@uiucdcsp.cs.uiuc.edu (05/14/88)
It is sad to see "flaming" proceeding on both sides of this issue, and I
certainly don't presume here to resolve it all...
1) Some of the first inspirations for "higher-level" languages came from
mathematicians who wanted to be able to express algebraic expressions
more naturally: the result - according to J. Backus - was FORTRAN;
2) When symbolic manipulation of algebraic expressions at a higher level
than FORTRAN was demanded, MACSYM (among others) evolved.
I could go on; mathematics (among other disciplines) has inspired a host
of innovations that can only be called "programming in mathematics".
The latest of these I have tried is "Eureka: the Problem Solver" from
Borland Int'l: given some equations and initializations (so long as the
functions are differentiable since it uses "steepest descent"), the system
is remarkably quick at posing a solution. Having tried it, I do indeed feel
as though I am "programming in mathematics".
The direction programmatic evolution seems to be taking is to become
more Descriptive and less Prescriptive: when I look at 'ei' (O'Donnell's
equational-logic language) and Lucid - among others - I do indeed feel
the tendency of programming as an activity to approach the style of
mathematics, which is also more declarative than procedural.