Interesting! How do you know your algorithm handles the tricky corner cases? I'd imagine you need to write down all the corner cases, write a formal proof for each, and hope that (1) your proof is correct, and (2) your code actually matches your proof. Could you elaborate on how you do this?

Here are a few corner cases I can think of for word-wrapping:

1) The line is empty.

2) The line is 1 character shorter/1 character longer/exactly the same length as the wrap limit.

3) The first break point for the line falls before/after/on the wrap limit.

4) The first character(s) of the newly-wrapped line are spaces.

I don't think that I could just eyeball a word-wrap algorithm and know that it handles all these cases correctly. I would, at a minimum, need to check each case. But at that point, I'm just as well off writing test cases, and allowing the computer to verify that my algorithm does the right thing for each. Of course, that's not as good as a proof by induction for each desired property, but it's a _lot_ less work, and it's almost always adequate. And I don't need to worry about mistakes in my proof.

Am I misunderstanding something about your approach? How would you handle this?

I do not say I do not test my code. I just see no purpose in implementing code that I hope will work. I need to believe it will work, and if it does not, I am sure that it is an implementation, not an algorithm issue. The first attempt in the article was just silly, and the second was just wrong. I would not waste time writing these, instead I would use this time to figure out the real solution and then I would implement it.

Hrmm? How else are you going to solve a problem that you've never faced before?

And yes, wasted time is basically a necessary feature of working on problems that don't have a textbook solution.

I am going to think about a problem, and if I come up with a solution I am sure is correct, I shall implement it. If I do not, I will search the web for a solution. If I find one, I will make sure it is correct, and then implement it. If I do not, I am going to ask some friends of mine about it. If they do not know the solution, I will temporaily loose the constraints and implement a solution that is "good enough", then I will make the problem my next research problem.

Implementing an algorithm we are not sure that works correctly is not only a waste of time -- it is actually harmful, for it is possible to ship an algorithm that only seem to work correctly. Test cases will not prove that a solution is correct.

What did I get downvoted for? I am relatively new here and I do not know all the things that are frowned upon?

I suspect that in many people's experience, "a solution that I am sure is correct" is anything but, until you've actually tested it. And testing it often takes far less time than puzzling over it and pondering. And so claiming that you never implement anything until you're absolutely certain it's correct smacks of youthful naivete, of the type common to college students who've never implemented anything.

In many of the more interesting fields, it's often not well-defined what it means for an algorithm to be "correct" anyway. What would a "correct" web search algorithm look like? How about a "correct" recommendation algorithm? A "correct" flight fare prediction algorithm? A "correct" stock trading algorithm? A "correct" Starcraft AI? There're "better" and "worse" algorithms for these, but there's no such thing as a "correct" one.

For many problems that do have an obvious "correct" solution (eg. OCR, face recognition, fare optimization), getting there is a nearly intractable problem, and the interesting part is in figuring out how you can approximate it as well as possible with the resources you have available is the best you can do.

You are right in what you say, however I think I have been misunderstood. It is well defined what it means for an algorithm to be correct -- it means that it returns expected output for a given input. Ambiguous situations you are talking about are when the problem is not well defined. That is why I used the word "algorithm" in my first comment. Trial and error is perfectly fine when we are not exactly sure what result we expect, but we will "feel" when it's good enough. It is unacceptable if we know exactly what the result should be, though.

When the problem is well-defined, like word-wrapping, or sorting, or whatever, if you blindly stagger and write code hoping it will work, instead of stopping to think why it should work, you are doing it wrong.