Nick Kallen writes.
> I do believe this is the case. Among other things, math is the science of
> precise human logic dealing with quanitative and qualitative aspects of
> entities. Programming languages are languages to precisely describe
> quantitative and qualitative aspects of entities.
The mathematician's concept of what is precise and the programming language
designer's (or "designer") concept of what is precise are different for
most programming languages. They are the SAME for those languages at the
functional end of the spectrum. This, and not language-features, is the
REAL difference between functional languages and the rest - bolting on
features doesn't make a language functional. So Nick Kallen is missing the
mathematical point when he writes:
> A C++++ with parametric polymorphism (w/ type classes),
> algebraic types, and pattern matching could also *always* produce code
> that was shorter than C++.
A designer of a functional programming language, if he wants to add a
feature, has to prove that that feature won't interact disastrously with
other features, most typically by specifying a translation into the Lambda
Calculus. If a programming language has n-features then the number of
possible interactions between features is at least n^2 (leaving aside
ternary interactions). Consequently proving anything useful (for example
that it is type-safe) about the language is likely to require looking at
n^2 cases, unless the language is carefully designed, which C++, say,
isn't.
Even if we take the Lambda Calculus, the basic definition of substitution
has SEVEN cases. So, until you've built up a decent repetoire of lemmas,
every proposition you prove about substitution requires you to treat all
seven cases, often with a couple of sub-cases. And that's about as simple
as you can get (unless you use Shonfinkel's combinators). Even a fine
mathematician like Curry got some of the details of alpha-reduction proofs
wrong, according to Hindley. [Hindley and Seldon, "Introduction to
Combinators and the Lambda Calculus", Cambridge UP 1986].
Likewise, the basic Church-Rosser properties of the Lambda Calculus are
sensitive to the reduction-rules in use, which is why the
functional-language people are sold on laziness, since normal-order
reduction (corresponding to lazy evaluation) is the standard way to be sure
a of computation terminating in a normal form if one exists. [This fact
incidentally must have been known to the Algol 60 designers, since they put
call-by-name into the language...]
Moreover, if you want to use the Lambda Calculus as a logic (as HOL does,
for example) you need a typed version, since logics built on the untyped
version are inconsistent (Curry's paradox).
So, analysing programs with mathematical precision is quite hard work, and
requires considerable application of Occam's Razor...
Robin.
|