in reply to Re: Re (tilly) 1: Perl debugging - a look at 'beta' mechanism
in thread Perl debugging - a look at 'beta' mechanism

I think you are referring to the Linus Torvalds quote that merlyn quoted at Re: Re (tilly) 2: Are debuggers good??

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.

  • Comment on Re (tilly) 3 (misread): Perl debugging - a look at 'beta' mechanism

Replies are listed 'Best First'.
Re: Re (tilly) 3 (misread): Perl debugging - a look at 'beta' mechanism
by poqui (Deacon) on Jan 12, 2002 at 01:22 UTC
    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

      I probably shouldn't respond to a thread which already has this much emotion. But I will try to clear up what I think are misreadings on your part.

      Saying that it is no fun to work with careless people is not elitist. It is a simple observation of the fact that it is no fun to put out fires caused by other people, to have to fix bugs introduced by other people, to have to rewrite things because you cannot trust the work of other people, etc. These things are all true, and I can vouch for them from experience. To become elitist you need to cross the boundary to asserting that carefulness is a trait that the vast majority of unwashed humanity is constitutionally incapable of learning. And I don't see Linus Torvalds saying that.

      Granted, Linus is ruthless about it. But he is ruthless for good reason. Linus develops and maintains a prominent software project. He has a lot of demands on his time, and has made the decision that it won't be his job to train potential developers from scratch. This is reasonable. It takes a lot of work to train people, and Linus has his pick of competent people who are willing to work with him. When you are in a position to cherry-pick people, it would be silly not to. Most of us do not have that luxury. But people who do, learn to do it like Linus does. Find ways to reject people, fast, just to get the list of candidates down to something you can manage.

      Another thing you appear to be misreading is merlyn when he says, 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 This does not say that you should never use a debugger. It says that if you are producing software that is such a mess that the only way you can find your own way around it is to use a debugger, then you are doing something seriously wrong. You are creating nightmares for yourself and your maintainance programmers, and you should stop doing so in any way possible. If you can learn, do. If you refuse to even try, then you have no business working as a programmer. That may sound harsh, but based on where costs are in software, employers are being stupid if they let employees repeatedly create up front messes in software development.

      The point is strongly made, yes. But ironically it is one you then came out with in your own words. As you nicely put it, Dependency is the hair I think we are trying to split here. You say it at more length in your elevator analogy. What you didn't say there, but is underscored by Linus, is that your actions affect co-workers and others who need to handle your code. If you aren't avoiding dependency upon the debugger, then you are doing something wrong. It is easy to avoid dependency upon the debugger by not using one. As you point out, it is possible to use one and be careful enough to keep vigilance. But it is very, very bad to turn code into a mess of spaghetti which can only be manipulated by poking and prodding until trial and error tells you that you have pushed the meatballs into the new pattern you wanted.

      As for the central question of the thread, well I am not going to try to convince you one way or the other. The most that I will say is that it works well to read people as talking about themselves. What merlyn and I said is that we find it harder to remain vigilant about overall design while using a debugger. If your mileage varies, the more power to you. Like Linus says in his email, you can use a debugger if you want to, and we won't give you a cold shoulder. Results are what matter, and our limitations are not necessarily yours.

      Now there is something very elitist said in that thread. It isn't in any of the things you are complaining about. It is in the final paragraph of On being a programmer. The rest of that post I agree with whole heartedly. Programming well is a different kind of activity than scripting out a set of actions. But in the final paragraph merlyn says that in order to learn to program you have to be wired the right way. That is elitist. If you had objected to that, I would have never disagreed with the objection. (My inclination is to disagree with merlyn on that point as well, but that is a question for another thread.)

      But you didn't. Instead you objected to distorted versions of much more reasonable things that were said. Which is why I have tried to clarify the gap between what you appear to have interpreted people as saying, and what I read them as saying. And now that I have clarified that as best as I know how, I am going to let this thread drop.