Re: (OT) Where is programming headed?

[Dominus]

Says mstone:

Automatic programming boils down to the deep theoretical question of whether all programming can be reduced to a finite set of generative postulates, the way, say, algebra can.

Perhaps I misunderstand your meaning, but it seems to me that Gödel's first incompleteness theorem says exactly that algebra cannot be reduced to a finite set of postulates.

Right now, we don't know if that binary sequence can be found by any means other than brute-force examination of every possible program.

You seem to have a deep misunderstanding of the halting problem. Right now, we believe that no method, including "brute-force examination", can determine if every program halts. If "brute-force examination" were sufficient, one would write a computer program to perform the brute-force examination and come up with the answer. But this is precisely what we know is impossible.

As a very simple example, consider this program:

use Math::BigInt;

my $N = Math::BigInt->new(shift @ARGV); 

while (1) {
  $N += 1;
  next unless prime($N);
  next unless prime($N+2);
  print "$N\n";
  exit;
} 

sub prime {
  my $n = shift;

  for (my $i = Math::BigInt->new(2); $i * $i <= $n; $i += 1) {
    return 0 if $n % $i == 0;
  }
  return 1;
}

You can't tell me whether this program will halt on all inputs. Not by "brute force examination" or by any other method. Why not? Because you don't know how to figure that out. Neither does anyone else.

I won't address your assertion that a solution to the halting problem will provide a solution to "the automatic programming problem", because you still haven't said what "the automatic programming problem" is, and I'm starting to suspect that you don't have a very clear idea of it yourself.

It might even be possible to calculate that value with a Turing machine.. in which case, we could sidestep the current proof for the halting problem's unsolvability without actually contradicting it.

No, you couldn't. The proof completely rules out this exact possibility. I don't think you could understand the proof and still believe this.

Point taken, though one could probably call that a compiler issue.. IIRC, the ANSI-C spec defines all floating-point representations in terms of a minimal error variable elim.

You're the one that brought it up; if you wanted to leave compiler-dependent issues out of the discussion, you should have done that. As for the square root of 2, what of it? Are you now saying that code to compute the square root of 2 will fail "as often as not"? That isn't true either.

The term elim does not appear in the 1999 C language standard, which I consulted before posting my original reply.

--
Mark Dominus
Perl Paraphernalia