On 8/8/06, M. Edward (Ed) Borasky <znmeb / cesmail.net> wrote:
 >
> I learned Lisp (1.5) in the early 1970s, and this style of programming
> seemed to be tied to Lisp at the time, but I actually had used it
> earlier. For some reason FORTRAN programmers, including myself when I
> was one, don't usually use this style, perhaps because the original
> FORTRAN didn't have structured concepts and forced the use of GO TO
> statements.


I've always been fascinated by one specific aspect of functional
languages: in theory, it's possible to use tools to prove programs
correct. What a productivity win that would be. At different times, I
used professional programmers who worked for me as guinea pigs to see
just how they would take to the functional style, and the results were
dismal.

Even though the Church and Turing models of computation are unified
(and were unified long before digital computers existed), there still
seems to be something intuitively attractive to many programmers about
stuffing values into little boxes and being able to go get the values
out of the boxes later. I'm not sure if this is fundamental, or a
side-effect of the fact that our practical computing machines are all
Turing machines and most programmers learn something about "memory"
and "secondary storage" early in their training. This explains why
pure functional programming is stylistically so challenging in
practice, whether or not you believe it's challenging in theory.

But one of the more insightful things I've heard recently is this:
Turing-completeness works against productivity and makes programs less
tool-able. And this is a direct consequence of its power, which
necessarily gives you Godel-undecidability in the general case.

The Lispish style (conceptualizing programs as artifacts in a
domain-specific language), which Ruby does extremely well in an
imperative-language context, can be said to have the following virtue:
it allows you to work with your problem domain using a language that
is not Turing-complete. (Let that sink in for a moment.) That means
that your programs are easier to reason about, easier to debug, and
eventually, easier to tool. What you lose in expressive power is
trivial because your standard for language power is related to your
problem domain, not to Turing-completeness in general. What you gain
in productivity is potentially immense.