In any case the question isn't whether or not debuggers make any specific bug faster to solve. Of course they do. That is their job. Once things go wrong it is usually much faster for a competent person to get an answer with a debugger than it is without. But using the debugger you will never see your program and understand it in the same way that you do without, and that makes the forest easy to miss for the trees when it comes to design mistakes.

If so, then your interpretation is a serious misread of what was meant. If you wish to make accusations of elitism, fine. But please do it over statements where it is justified.

The fact is that problematic code is something that sneaks up on us. Very few people intend to write bad code. Rather they write something, modify it, introduce a few dependencies, and before long you have a Big Ball of Mud. The only way to avoid going down that slippery slope is developer vigilance.

The first claim being made is that debuggers assist you with debugging, and assist you in dealing with the consequences of being partway down that slope. This is pretty non-controversial. After all debuggers are intended to assist in fixing problems in any kind of code.

The second claim is that this makes it easier to deal with warning symptoms and lose vigilance. This is somewhat more controversial. It is easy to misunderstand this and see it as saying that only careless people use the debugger. That isn't what is being said though. What is being said is that when you find it easy to fix symptoms, it is easier to miss the fact that they are symptoms. Within the comfort and myopic view that the debugger gives, it is harder to notice broad design issues which will lead to misunderstandings and fragility. You can still do that, it just takes more awareness and work than it does when you study the code at a source level. Debuggers don't necessarily make you more careless, they just make it harder to stay aware of the need to be careful. (I think this is the point you misinterpreted.)

The third claim is the controversial one. That claim is that the tendancy to lose vigilance with debuggers is a severe enough issue to forgo the debugging convenience they give. You will find good programmers who disagree on this. We have a concrete cost and concrete benefit. All can agree on that, but still disagree on their relative worths.

Now to these claims I will add a last one. The cognitive difference between how people who use and don't use debuggers approach problems can lead to cases where each has problems with the other one's code. I think the case for people who don't use debuggers dealing with slightly messy code is clear. What is tolerable to a person with a debugger may not be to someone without. The converse may be less obvious.

The issue the other way is that if you don't use a debugger, it is easier to add in levels of indirection in your design. Those levels are good for you, they allow you to think about problems at a higher level, in larger chunks. However those abstractions break the connection between what is written in the code and what you might see in a debugger. As an example consider the case of perl. This was (for the most part) designed and written by Larry Wall, who does not use debuggers. To make his life easy, Larry proceeded to make very liberal use of macros with various naming schemes so that he could keep track of the design.

The result is that trying to trace the execution of perl in the debugger can be an..interesting..experience.

Yes, that is exactly the post and its replies to which I refer.
Linus: I'd rather not work with people who aren't careful. It's darwinism in software development.
Merlyn: If you can't program careful enough to not need a debugger, then either slow down your rate of coding, or pick a different profession. Please

Compare to: I'd rather not work with people who can't match my superior level of intelligence. It's darwinism in intellectuality.
or: If you can't program carefully enough to not need a compiler, then either slow down your rate of coding, or pick a different profession. Please.

Any way I read it, it still sounds elitist. Like the old ASM programmer I met when I first started.

I don't disagree with you about problematic code sneaking up on one, or that Vigilance is the price of good code. But blaming the tool is a poor excuse.

Elevators are a wonderful invention, and people can use them to get between floors in tall buildings. The people who use them are (for the most part) not less able to use the stairs just because they are using the elevator. But someone who comes to *depend* solely upon the elevator to move between floors is limiting themselves; just as is the person who limits themself to using stairs.

tilly: What is tolerable to a person with a debugger may not be to someone without. The converse may be less obvious.
And thats ok, but thats a bit different than saying that the person who chooses to use a debugger "should find another profession".

tilly: The third claim is the controversial one... that the tendancy to lose vigilance with debuggers is a severe enough issue to forgo the debugging convenience they give.
And I say that the tendency to lose vigilance with compilers is a severe issue too, but not enough to forgo their use.
Dependency is the hair I think we are trying to split here.

tilly: The issue the other way is that if you don't use a debugger, it is easier to add in levels of indirection in your design.
I agree, debuggers are not perfect, especially when dealing with indirection, but that doesn't, IMO, make them useless, or even dangerous to use.




"That that is, is... for what is that but that? and is but is?" Shakespeare, Twelfth Night, Act IV, Scene 2 "Yet THAT which is not neither is nor is not That which is!" Frater Perdurabo (pseud. Aleister Crowley), Liber CCCXXXIII, The Book of Lies