just fixing the one error that the compiler spat out was often shortsighted, as there could easily be more examples of the same error in other locations, or that error could have been caused by an earlier error, or perhaps a more fundamental logic problem.

I have to disagree on that one, the first lesson I learned the hard way in my first CS class was not to get bogged down by compiler errors. The prof had given us some C code, and our assignment consisted of two parts:

1. fix the code so it compiled and ran
2. modifiy it so it did something slightly different.

Moral: start at the begining, and proceed in sequence. At each step make sure that what you've done has fixed the first bug, and reduced the total number of bugs.

Superficially it seems that you advocate the whirlpool model instead of the waterfall one. But really you advocate tripping blindly in the dark. As I will show, there is nothing wrong with the method of your teacher but you are getting the wrong lessons out ouf it!

1. fix the code so it compiled and ran

Most compilers run completely out of sync at the first syntactical error and produce a cascad of errors. So incremental fixing is a way to get a program to compile. That was probably the lesson the teacher wanted you to learn. I don't see any other interesting lessons to get from that. Getting a program to compile is no big deal!

2. modify it so it did something slightly different.

That's the way we do everything. Proceed from the known to the new. We never start anything from scratch but learn from previous experience. The good teacher is the one that impose in an new exercice a "slightly difference" so that the pupil can both build his confidence and exercice his own initiative.

But deducing from these exercices that programming is incremental fixing of bugs is dead wrong. Incremental improvment of programs, or Larry's whirlpool (as opposed to the waterfall model) is way more than that. Testing and fixing is just the inner loop or the whirlpoool. But what you propose is not even that, it is the blind fixing of visible bugs probably creating countless of bugs elsewhere. In the linux kernel mailing list,there are recurring threads about self-proclaimed the bastard Linus against getting a debugger in the kernel to fight this natural but wrong tendency: "just fix the next bug" and to encourage programmers to always get the larger view

I guess I could derive my mantra from Arthur Koestler notion of holon.

Every complex system is an holarchy where higher holons depends on lower ones. A program is such an holarchy and the first thing to know is at which stage of the holarchy you need to work. Fixing blindly bugs after bugs is working on lower holons and at best building scar tissues. In more pragmatic term, getting local optima (here fixing given bugs) are no guaranty of a global optimum. And we live in a society where every one is a specialist of some holon and is able and prone to get a local optimal there but is likely create a disaster at higher level. Example: "an optimal so-called liberalist american economy is likely to wreck the global ecosystem because it does not care about global warming". Pick up your favorite example.

So the mantra is Which holon needs working? or in term of Larry's whirlpool Which loop of the whirlpool needs work?

Certainly, these mantra, as any mantra, set the mind but, by themselves, do not define any course of action. The devil is in the details and we must go define in a given fields what an holarchy is and from which holon it is made. Different schools of programming have various ideas about that.

I like the concept of holon and holarchy but beware not to get in new-age drug induced illiterrate holistic dreams!!

-- stefp -- check out TeXmacs wiki

I wasn't making any comments about overall bug fixing methodologies, or trying to advocate a particular development lifecycle approach, my point was specificly addressing this issue of fixing compile time bugs/errors/warnings.

If you try to fix to many at once, you run the risk of not realizing a later bug is caused by a former bug, and spend excessive ammounts of time debugging lines of code that have nothing wrong with them (thanx to your orriginal fix) In my opinion, unless you can tell from the error msg exactly what the problem is, it's not even worth the time/energy of jumping to the line# of the next error to see if it might be a differnet problem. That 0.5 second can be better spent recompiling, and thinking about important things, like what grass smells like

The worst situations I've ever seen are people who forgot that in fixing their first error, they may have added/removed a line from the code, invalidating the line number the compiler gave them for the rest of their errors.
(You could argue that you people can keep in mind when you make a change that affects line numbering -- but why should they have to?)

The point I was trying to make is that the compiler error usually tells you one vague thing: you did something wrong. Unfortunately it does not tell you to any useful extent what you did wrong. It could be anything from a simple typo in one line that lead to 42 messages, or you could have a whole host of fundamental flaws, and there are many options in between.

In fact, I think I'm safe in asserting tha the most serious flaws in programming are too subtle to be reported by any automated means, so when you do get a warning or an error, the wisdom my boss meant me to take was this: view this warning as a moment of reflection to consider all that leads to this point and all that follows, and take a moment before you simply change one character in a knee-jerk reflex and re-compile.

For another example, I am reminded of a silly little activity my geek friends and I enjoyed in high-school, when we had gained access to the the first BASIC interpreter we'd seen. The speed of response was positively intoxicating! When we got some code from elsewhere, and received the "syntax error on line nnnn" message, we'd just delete that line and re-run, repeating this process over and over. We were at least sure to never get that particular error again (now that's "de-bugging" ;-), and while the result was often a program reduced to just a handful of lines that did little or nothing, sometimes we'd get some really interesting behaviour which would amuse our adolescent minds for minutes at a time. I don't believe we ever got a correct program out of this process however ;-)

While I was writing this, I noticed a great line from virtualsue in the CB:

Programming is a craft not a religion. It's not all that different from construction work ;-)

I think this is absolutely true, and following that metaphor, consider whether a contractor should simply patch cracks in a wall, or have a look to see if there is a larger problem elsewhere in the building.

--
I'd like to be able to assign to an luser