in reply to Programming Mantras
I don't know if it's really a mantra but the voice in
my head when I'm debugging often says "don't stop at one".
This comes from my boss/mentor during a work term at a
really cool shop
in 1984. I was coding on a Cray 1S at the time, and as
compiling was a long term process, he explained that 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.
These days I usually don't have too long to wait for my Perl projects to run
(either they are pretty short, or I construct tiny sample datasets for testing),
so I take this advice to mean "don't stop at the easy or 'obvious' answer, as it
is often neither".
--
I'd like to be able to assign to an luser
Re: Re: Programming Mantras
by hossman (Prior) on Jan 21, 2002 at 13:23 UTC
|
(not really a perl thing, but...)
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:
- fix the code so it compiled and ran
- modifiy it so it did something slightly different.
As provided, the code generated about 42 compiler
errors/warnings ... people (like me) who tried to fix
more then one error at a time, or fix the later errors
first, spent forever on the assignment. Had we started
at the first error, and then recompiled, about 3/4s of
the errors went away. Fixing the next (now first)
errors made the rest go away.
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.
| [reply] |
|
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
| [reply] |
|
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?)
| [reply] |
|
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
| [reply] |
|
|