Hacker News Reader

Comment by ohyes | Hacker News Reader

"Someone who could write large programs that have a high probability of being correct"

No one can do that.

I can write a number of small programs that are correct, however. This is easy, because I can check all of the inputs and outputs. When I combine them, I get another small program that is also correct.

P: "Doctor, it hurts when I do this"

D: "So don't do that"

This is the reason for FP, DSLs, etc.

View on HN

Most programs I write have an infinite number of inputs.

I'm not sure how this is relevant?

All programs have an infinite number of possible inputs. You check the ones that you expect.

Is that somehow non-obvious?

> You check the ones that you expect.

You expect buffer overflows? Out-of-bounds arguments? These are the things the GP is referring to, I figure.

Mathematics proves things about an infinite class of objects all the time, like, say, the input/output behavior of your program. One technique to do this is induction.

Prove your program works for n=1. Induct on n.

You forgot n=0.

edit: and I forgot n=⊥

I meant to say programs that have a high probability of behaving correctly. That's not to say that the program is correct. There's almost zero chance that any large program is entirely bug-free, but some applications to perform reliably because the most used paths through the software are correct.

Use a language that makes gluing easier, and you can scale this strategy further. Confer Wadler's "Why functional programming matters".

Reply on news.ycombinator.com