From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-08-10T23:26:01+09:00
Subject: Re: Language chatter

On 8/10/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> 1. No programmer I've ever known has stood by idly while someone took
> Turing completeness away from him or her, either deliberately or
> accidentally. :)
> 2. Part of the whole "science" of proving programs correct is designing
> ways for the customer to formally specify what a program must do to be
> correct. A processor not only has to know what the programmer intended
> but what the customer wanted as well. :)


Ed, the biggest problem with abstruse conversations like this is when
you get two or three guys who enable each other and keep it going ;-).

To take a step back from CS, here's the high-level thing that really
troubles me: why is there such an impedance mismatch between the
things we need to achieve in software and the available tools? Why do
I always feel like it takes mountains of "code" to do things that can
be described without too much difficulty? I'm not saying that
genuinely complex problems should be reducible beyond what makes
sense. I'm also not underrating the difficulty of good software design
or the difficulty of communicating well with the clients. But I'd
rather that *most* of the effort go into those areas. As things stand,
I have to solve a lot of computer-language-generated problems that do
not contribute value to the solution. It's like our machines have too
much friction.


I would *gladly* give up Turing-completeness in order to get a
(domain-specific) language that was more expressive (less
"frictional") in terms of the problems I need to solve. I've been
trying to present an intuition (which I don't know how to prove or
disprove) that the practical power required to solve circumscribed
problems does not come from Turing completeness, which of course *is*
required to solve general computing problems. Much depends on how you
define (and constrain) the problem space, and we need to get better
and more disciplined about that.

If this sounds like the old Lisp mantra of "design a language to fit
your problem and then just use that language," well, yes. How does one
do it effectively, though? You mentioned techniques for making
general-purpose programs easier to reason about, and they boiled down
to making them "smaller" in multiple dimensions. But our problem
domains are big and getting bigger. So something is missing. Back to
impedance mismatch again.

I'm going to try to have the discipline to stand back from this thread
now because until I can prove some of this crap I've been spouting, I
don't think I'm adding much value.