“Ignorance more frequently begets confidence than does knowledge: it is those who know little, and not those who know much, who so positively assert that this or that problem will never be solved by science.” – Charles Darwin

“Dare to be naive.” – R. Buckminster Fuller

“It is our duty as human beings to proceed as though the limits of our capabilities do not exist.” – Teilhard de Chardin

“Things are only impossible until they’re not.” – Jean-Luc Picard

Wow — I love this comment! I especially enjoy your description of plowing through complexity, riding the curve up and then down. And I relate deeply. My aim rarely is to get some software merely working (so that it “meets the functional requirements”), but to continue until implementation is compelling, revealing, and ideally inevitable. A tremendously satisfying experience. And a journey of faith, in the sense of hopefulness and willingness to try, but with no guarantee or certainty of outcome. And when it works out, I’m grateful for being invited along for the ride.

And yes (!) to your perspective that in spite of focusing on programs (answers), we will have still “trained the right muscles” for mastering the complexity of specifications (questions).

We have been forced to make our programs precise, but we haven’t been forced nearly as much to make our specifications precise. So there’s been more progress on simple precise programs than on simple precise specifications. Without noting this historical difference, one might mistakenly assume that precise specifications are inherently resistant to simplicity.

There are good abstractions out there waiting to be found. Just because the specification we have now is bad/good/whatever, that dosn’t mean there aren’t better abstractions just waiting to be found.

p>[…] das eine Frage sein, die sich heutzutage er

Nice blog. From my perspective as a teacher, I find that one of the most difficult lessons to teach is that complexity is the enemy. Many young people enjoy complexity—perhaps it gives them a feeling of mastery or something. And as you’ve pointed out, simple and precise is much harder.

In more than just programming, this is not an age given to the appreciation of simplicity.

Norman

What you can formalize is the stuff that the programmer knows the code should be doing, but can’t currently express at compile time. This function should return a list sorted by account ID. That function requires a list sorted by account ID to work correctly. No two of these game objects should ever be assigned the same grid position. This function is guaranteed to return one of these known document types no matter what input stream it is given. That function will always return in some bounded time, using a known set of resources.

In other words, you can’t prove everything, but there are still huge gains to be made proving more than we do today.

My hope is that such proofs will look exactly like quickcheck tests, and quickcheck will someday turn into a tool that proves what it can, and for the rest says, “I couldn’t prove it, but at least it passed these test cases.”