kasia in a nutshell

You outta run that Sierra Club BS through a debugger.

Like yourself I am a Software Engineer, and I think your right about what you say about debuggers... they make our lives easier :)

Uh, don't you mean "you're"? But I guess blindly relying on other crutches like spell checkers will fail you too.

"Reading the code to find the bug makes you learn the code by heart"

Huh? Does this person works on a project with just 10 lines of code?

Dave, obviously you can't read well, must be why you are a manager? The "sierra club bullshit" is clearly identified as coming from the nrdc, so it would be more accurate to call it "nrdc bullshit".

Why do you spend your time reading leftist, commie blogs? Don't you have programmers to manage?

the thought that "debuggers are for lazy and sloppy programmers" is the most retarded idea since eating your own excrement.

my favourite is "Linus Torvalds doesn't want you to use a debugger on the linux kernel code", there is a reason for this, it is not always safe to step through a kernel, however there are safe places you can "drop in". This is also funny because it is blind acceptance of anything Linus Torvalds says.

this ones also good "Use print statements!", aka. poor man's debugger, however once again it is not always safe and indeed even possible to print out anything.

The use of "program defensively" is funny too, how long has this person been programming ? it's just regurgitating the same old hackneyed phrases and means nothing

grrr ....

I find that way too many software people never get proficient at using a debugger and instead put in more printf's (making the code bigger, adding
errors in the debug statements, changing the behavior, ...). A debugger let's you see what "it" is doing with less of an impact on the code itself.
Effective debug techniques are an art and a learned skill and much less invasive than coding the alternative.

> how long has this person been programming ?

Almost 30 years, with programs somewhat longer than 10 lines. It's certainly easier to garner support for one's position when one mischaracterizes an opponent's position, isn't it? The "Use print statements" was a very nice touch in that respect.

I have long believed that debuggers were generally a crutch and contributed to sloppy programming, and I still do. I held this position before Linus stirred the pot with his own position on it, and I have largely borrowed his reasoning. I'm certainly not a Linus toady.

He doesn't like kernel debuggers not "because it's hard to debug a kernel" - that's silly - but because it mainly aims at the symptom of a problem (why is the value X instead of Y?) rather than the source of the problem. We all know that a program bug can manifest itself far away from the bug itself, and I don't think that making it easy to change code you don't understand is really a good thing.

"Program defensively" means to rely on consistency checks provided by the language, and this goes a very long way to tracking down the inevitable bugs because they are working for you whether you're in the debugger or not. For instance, I use more assert()s in my code in a day than most programmers use in a year ("An assertion failed is an hour saved"), and about the only thing I use a debugger for is a stack backtrack when the assertion fails. "Building code to be unit testable" is defensive too.

Yes, once in a while (perhaps every other year) I'll single-step through the code, and more often than not it ends up being a waste of time. And I always feel dirty doing it.

> "Reading the code to find the bug makes you learn the code by heart"

I never said that either, but changing code you don't understand doesn't seem like something one would want to advocate.

I suppose debuggers have their value, but I believe they largely substitute for dealing with real problems, and in that respect they engender sloppy habits.

No doubt some have become very proficient, and it seems self-evident by the fact that Kasia (an astonishingly strong developer) uses it that smart people can use them too in a less-sloppy way, but I don't believe this applies in the general case.

Steve

Steve, do you feel the same way about doctors? After all, it's your own body. You should know what is going on and it is pretty sloppy if you can't solve the problem yourself. :)

Steve, I agree with most of the points you make, but you really don't give a reason on why not to use a debugger or why they lead to sloppy habits. The closest you come is:

'aims at the symptom of a problem (why is the value X instead of Y?) rather than the source of the problem'

Huh?!? I’m getting the impression that your problem is with the coder not with the debugger. If the coder is changing things on the fly without reviewing what is going on, then someone (Project Manager\Lead Programmer) needs to smack him on the back of the head until he stops.

The debugger doesn't change one line of code. Also, isn't finding the symptoms of the problem the first step in finding the source?

A debugger is a tool, nothing more. It doesn't make people smarter or dumber. It can make you more productive. You need to get with the 90s.

Steve,
I agree with you totally when you say "I don't think that making it easy to change code you don't understand is really a good thing."
But I still don't agree debuggers are like crutches and they lead to sloppy programming. They might lead to sloppy solutions, but it depends on the user. Why blame the tool when its user is not experienced enough?
I personally believe that debuggers lead to faster and better understanding of a program than by any other means.

The original poster made a good point in that you may want to use a debugger if you are debugging someone else's code if the code doesn't have asserts, logging statements, and/or unit tests.

However, if you are in control of the code and have such testing in place, then a debugger is not the way to go. My point is this: if you put logging statements into your code for debugging purposes, and LEAVE THEM THERE after you are done, you can reuse them in the future if you have to debug that portion of code again.

When you use a debugger, everything you do is lost. If you use logging statments, all of your debugging work is there forever. If you have all of the testing and logging code in place, a debugger isn't any faster than just rerunning you unit tests and examining the logged output. (A unit test should run in an order of seconds)

pbw makes a good observation: "I’m getting the impression that your problem is with the coder not with the debugger."

I can see this same arguement with web design; people prefering a text editor over a WYSIWYG editor. Steve's position seems more aimed at beginner programmers and not profecient, experienced programmers.

In the end, if a debugger (or any other type of assistance application) is used as an aid, and not the "rule", then there isn't any problem with using it. Unfortunatly, there are plenty of people that don't understand the difference between the two.

Couldn't agree more, Kasia. I posted a few extra thoughts here:

http://beust.com/weblog/archives/000198.html

--
Cedric

Well, Danne, there is a problem using it. As I stated above that debugging work is lost. Log statements in the source would be available to future programmers working on the same snippet of code.

I don't much care about if a debugger makes it "easy to change code you don't understand" or if "Reading the code ... makes you learn the code by heart" (even tho these are arguments against a debugger). I only care about the lost work.

As a neebie to programming (just about 4 years in earnest) I got to love a debugger when I had to work (in an XP group) on a large basis of code that was definitely not self-explanationary.

Of course, it being an XP group, the first thing we did was: fix the tests and work test-first from then on.

But still there are a lot of problems (like: What method (in inheritance) is called now??) that I like to see solved with my humble debugger.

All of this was done with Eclipse & Java.

Eclipse & C was a totally different experience, like things definitely not behaving the same way when debugging or running, which I found very very frustrating.

In short: I don´t think "test-first" solves it all; I don´t think that good code is self-explanationary to everyone. I think there is a good reason for debuggers to be around.

On the other hand, just today I heard a lecture on AspectJ that might solve quite some problems around debugging code - they have used similar things (JMangler) to validate large software.

Oh, goodie, a debugger argument!

Can anyone who uses a debugger point out to me how a debugger would point out unsynchronized calls to java.util.Hashmap (which, under heavy load, turns into a real nightmare)?

Here's a hint: you can't, because a debugger cannot accurately model the state of a production environment. You will struggle all day long trying to figure out why the debugger's calls to Hashmap.get() return different results than your production environment.

Astute readers would point out that really nothing can model the production environment. As such, the only way to truly find runtime bugs is to build in good, solid logging into your classes and run them with logging turned on when you start seeing bugs.

You wouldn't.. you'd use the built-in debug output you can turn on via reflection (something I do regularly). Doesn't make the debugger any less useful in other situations.

'When you use a debugger, everything you do is lost.'

I already see debuggers that remember my breakpoints and what variables I'm watching after I close the project for each project that I'm working on. I don't think it is too long before we see a debugger that can totally seperate the logging statements for testing from the source code.

For the debuggers I'm working with the variables watched are at the project level. Move that one (big) step down to the line level. Save that test plan info off into a file with the project that you can share with you friends and you are there.

'If you have all of the testing and logging code in place, a debugger isn't any faster than just rerunning you unit tests and examining the logged output'

I disagree. Usually the logged output needs to be accessed from a different interface. With a debugger the output and your code is in the same interface. No flipping screens or looking at the paper next to you.

I really hate it when people make arguments that boil down to: "I found a case where a tool is suboptimal/useless, therefore you should never use it."

One of the things that programmers seem most likely to forget is that just because we're all writing code does not mean we have similar needs in a production environment.

pbw,

"I already see debuggers that remember my breakpoints and what variables I'm watching"

That is a good point and is a very good counter. It would need to store this debugging info in source control and be easily used by others. It also should be in text file format. For those that don't have access to such a feature, my argument stands (against debuggers).

"No flipping screens or looking at the paper next to you"

There is some of that, but I don't see it as much of a problem. Most good editors (or IDEs) will allow you to assign a hot key to run your tests and display the output. If an assertion failed and the output is formated correctly (which is usu the case or easy to accomplish) you can jump straight from the output to the offending line. Pretty quick and easy.

So you admit you're a commie kasia? Maybe if you weren't so anti-capitalistic you could rise out of the trenches of the computer jockeys (who wouldn't require far so much management if they weren't spending so much time constantly posting far-left stuff on their blogs).

Wow, Steve, do you write everything in assembly too? Or outright binary? After all, compilers are just a crutch too, especially if you don't disable their warnings, messages, etc.

That one idiot uses a debugger as a substitute for "thinking" does not, a priori, mean that debuggers are always a bad idea, but I see them as substitutes for "thinking" *so often* that it seems clear to me that they engender bad habits in the general case.

I think too many people - probably not Kasia - shift their skillsets from "avoiding bugs" to "finding bugs". I just don't see this as all that helpful.

I'm sure that somebody diving into a situation where code was badly written by others mean that one doesn't have the option of creating the code in the first place, and even for a non-debugger-type like me could perhaps find it useful at times, but "being skilled with a debugger" means to me that one is creating too many bugs.

> A debugger is a tool, nothing more. It doesn't make people smarter or dumber.

Well, "Visual Basic" is a tool... :-)

Steve, you've never heard the maxim "There's always one more bug" ? It's true!

.. and dave, I even say that on my 'about me' page.. except you appear to not have the sense of humour required to appreciate anyone laughing at themselves.

> After all, compilers are just a crutch too, especially if you don't disable their warnings, messages, etc.

No, compilers aren't a crutch at all, because they allow one to think at a higher level than one can do at assembler. "Thinking about a problem" is the best thing that a developer can do.

Granted that once the bugs are actually *in* the code, a debugger may well be the best short-term way to get them out, but there is a substantial cohort of developers that prefers to nip them in the bud.

I see C/C++ developers *all the time* who are good with debuggers, but don't enable compiler warnings ( http://www.linux-mag.com/2003-08/compile_01.html ) or use assertions ( http://www.linux-mag.com/2003-06/compile_01.html ). They have avoided best practices that will head bugs off at the pass, but honed their skills at finding them later. This is a completely reversed set of priorities.

A debugger may very well be a valid *last* resort, but it's so often used as a *first* resort that that I cannot help but believe that they are partially causes rather than symptoms.

kasia a good developer?? LOL, if her code is anything like her politics, it's gotta be full of bugs, holes, and bad logic. Or does she work on "fuzzy" logic?

Dave> kasia a good developer?

Yes, I've seen her code, she's an astonishingly good developer. She's probably got more raw talent than I do, just not anywhere near the years of experience.

And why on Earth would you post something like this on a subject you know nothing about? How does this distinguish you from "an asshole"?

Ha, you don't sound like much of a developer to me Stevie. 30 years and you still can't figure out how to use the proper tools. I'm sure I know much more about developing than you do. And it's you who seems to be the asshole, being an arrogant ass at the office pretending you're some prima donna developer.

Uh, aren't you two supposed to be WORKING right now? See why management cracks down on your asses? LOL, 30 years and you're still a lowly developer Steven? That's truly an indicator of how poor your skillset is.

Well, I may very well be an asshole, but I'll let others weigh in on that.

And I like being a "lowly developer" - I have been in management before, am not terribly good at it, so have settled into a comfortable life of the self-employed consultant who works at home. I get to write C/C++ code pretty much every day, and that I still have my first customer from 1985 suggests I'm doing things pretty well.

And IBM, Bellsouth, and Bell Labs seem to think I was a good enough developer to teach them advanced C/Unix topics.

"Doesn't make the debugger any less useful in other situations."

I have yet to find a case where a debugger would help, when there is clean, well-commented code. Nine times out of ten, a debugger cannot help in runtime-specific conditions (which is where clean well-commented code breaks down). If you're consistently having to go back to the debugger, perhaps you should petition your teammates to add more comments to their code.

Hello Dave, I don't use a spellchecking tool at all... I made a typo.

Reading the comments on this blog make you appear a bit rude, why do you do that?

I didn't realise the discussion on debuggers was java-centric

I'm bored already

Anyway, Dave, take a deep breath

There is nothing wrong with socialism, communism, or libralism

give it a rest, your a prime example of conditioning

>> A debugger is a tool, nothing more. It doesn't make people smarter or dumber.

> Well, "Visual Basic" is a tool... :-)

Yes it is and when I'm asked use it, VB.NET and the applications I write with it work just fine. :)

Not all of us are all J2EE\C\C++ all the time. I'm not going to get into a whole VB vs Java thing (and since I can make $$$ writing both, I really don't care). However, VB has made some big steps and can produce some nice code. Which is something I wouldn't have said pre-.NET.

And Visual Studio is one of the debuggers that remembers my breakpoints and what variables I'm watching.

Wow, kaisa, I'd love to be an astonishingly good developer. Good stuff, keep it up.

I don't use a debugger much either, but I'm a unit test freak. I did use the debugger the other day from a unit test and I was amazed at how tight I could focus on potential problem areas.

personally, i've only ever used a debugger post-mortem to examine crashes. Then again, I don't do all that much programming since the world has gone to GUI's. *shrug*

> There is nothing wrong with socialism, communism, or libralism

Wow, what a completely stupid and naive thing to say.

As I indicated earlier, Eclipse & AspectJ & AJDT can enable debugging / logging that can be version controlled, enabled on demand etc.
Besides, they can easily be used for validating "code coverage" of test cases etc.
That´s for Java of course.

>> Can anyone who uses a debugger point
>> out to me how a debugger would point
>> out unsynchronized calls to java.util.Hashmap
>> (which, under heavy load, turns into a
>> real nightmare)?
>>
>> Here's a hint: you can't, because a debugger
>> cannot accurately model the state of a
>> production environment.

Hm. I have to be careful to not sound rude and I am sorry in advance if I fail.

Debuggers do indeed suck at the issue mentioned above. That is not what Debuggers are for. If you have only one or two tools in your toolbox your work will be crass and horribly marred as you try to do detailed work with a monkey wrench or a sledge hammer.

No, what you use for that sort of problem is something like jlint, PMD or Findbugs; Static code analysis tools. There are quite a few of them in the open source arena and some of them are quite good. Each have different areas where they excel. If you are not using this class of tool on a regular basis on your projects, you code deserves to suck.

And Steve, at first you sounded like a right git. After seeing a few of your posts I realize that you are that one guy. Every large shop has one guy who has been around the block a number of times, knows a lot about everything, is often misunderstood and gave up on the idiocy of the management track ages ago. Just wanted to say that there are some people who aspire to work on the technical side their whole careers and kudos to you for doing it and not caving. Cheers.

> there are some people who aspire to work on the technical side their whole careers

More than 10 years ago I was talking with my best friend, who was fully as strong a developer as I was (though a bit older and more experienced). He told me that he wanted to move into management, and at the time I really didn't see that I'd ever want that. But I was open to what might come in the future.

Ten years later I am very thankful I am not in management. Not because it's "caving" or "it's dirty" - I've known some top-notch technical managers in my career - but because I'm simply not very good at it. I have references that will attest to my being a lousy manager (sorry, Mike), and the fact that I like the technical side *and* have a personal disposition compatible with consulting suggests I'm in the right place.

I wish I had the personal skills to be in "technical management", but that might very well preclude being a work-at-home, self-employed consultant.

Life is good :-)

Ok, I've read and participated in this blog. I think I have it figured out.

Most of the "pro-logging" group probably do most or all of the following points:
- Comment thoroughly
- Unit test ALL code (or at least what needs debugged)
- Keep their routines small in line count or cyclomatic complexity
- Use descriptive naming for identifiers
- Sprinkle asserts everywhere (Don't assume anything!)
- Leave logging statements in the source

Most of the "pro-debugger" group probably don't do at least ONE of the above.

If you are a "pro-debugger" advocate, you should think about doing ALL of the points ... if you care about the quality of your product.

Even if one did follow all of the points, I believe there might be times when a debugger might be slighly more efficient. However, it would be very rare and might weaken the last 2 points.

Also, I believe asserts are more important than logging statements. Have the code "tell you" when something is wrong rather than you figuring it out. For times when an assert isn't enough, then use logging statements.

Steve Friedl pointed me here; I suppose I'll weigh in with my thoughts as well.

I too don't use debuggers (as distinct from dump analyzers - more on that, later) to debug programs. It just seems to be too low, too slow. They're just not the most useful of tools.

So what do I do instead? I think about what the program did and why it might have done that. I replay the source code in my head. I look at debug logs.

Naturally, this only really works for code I know well, which is to say, code I wrote myself. I try and avoid debugging anyone else's code :-)

Secondly, maybe firstly, I do everything possible to avoid having the bugs in the first place. I avoid unsafe operations ("every cast is an error of design" - ok, not entirely true, but a good rule of thumb). I write lots of assertions to check pre- and post-conditions, and I leave them in the production code. I don't leak memory, because I always know when I write an allocation where the corresponding deallocation occurs. I'm not claiming natural brilliance here, just that it's my craft and I've learned how to work tolerably well at it.

Is this right for everyone? I don't know. I don't much care. But I'm pretty productive and have a relatively low bug rate in my released code.

My attitude may have been formed from too many years spent writing kernel code; stepping through programs and stopping to examine data is so unlike 'real life' operation that it has little to recommend it.

I'm not entirely dogmatic about the matter. I'll use one from time to time if it seems like it might be useful. Why, I used a debugger some time in the last 3 months (and then I sent email to a buddy of mine in the pro-debugger camp to tell him I'd actually solved a problem with a debugger; I forget what it was now).

Where I will use always a debugger, or something like one (depends on the OS whether the crash analyzer is the same program as the debugger) is to look at crash dumps. When and if those assertions fail, I need to examine the entrails to decide what happened. Mostly, I'm interested in seeing data structures at that point. By definition, something impossible has just happened, so I've got to see the actual state of objects.

BTW, the previous comment is from "the really smart dave", not "the asshole dave" :-)

RSD is not the light to the dark that is AD? They are not the ying and yang of Dave-ness? I have to admit that after reading just the one post that I do quite prefer RSD. By rather a lot.

Knowing the RSD personally, I can vouch that he is a much preferred form of a Dave. Here or anywhere. Even if I don't always agree with him.

"... preferred form of Dave."

Hmmmm ... I'll try not to read too much into that, although I can't help but think "Open the pod bay doors, Hal."

Did someone kill the troll? Papa Billy-Goat, perhaps? Maybe he O.D.-ed on viagra...

He has met his match -- the awesome power of the delete function.

Three cheers for kasia and her powers of deletion.