Subject: RE: [hackers-il] Maintenance of 10,000,000 lines long application s?

From: Chen Shapira <[email-masked]>
Date: Sun, 6 May 2001 20:50:00 +0200

> agreed, to both accounts. on a tangent, the use of the 
> debugger, i would
> be happy to have your opinions on the following post by linus:
> 
> http://lwn.net/2000/0914/a/lt-debugger.php3
> 
> i find that when i try to avoid the debugger, the resulting code is
> higher quality, because i have to reall _think_ about the code i'm
> writing. however, in some cases (a deep call stack, an obscure bug
> which only happens every n'th iteration), a debugger is very, 
> very usefull.

The other day, OmerM and I discussed Linus's attitude toward conventional
development tools (CVS, Debugger, IDE, etc.). We worried that since so many
young people view Linus as a Demi-God, they will be presuaded into thinking
that inorder to be more like Linus (which isn't a bad wish) they should
avoid software tools.

Which reminds me (and forgive me for discussing female problems in a male
forum, but after you started with playboy...) for many years I was a rabid
feminist, naturally I avoided wearing bra's, which are obviously yet another
symbol of male oppression. Last year I started wearing bra's and guess what?
They are damn comfortable.

Same with software tools, they may substract from your "hacker" value, and
you can certainly work without them, but they are damn comfortable.

And after working for 1 year on CGI without a debugger, and then moving to
ASP which has a debugger - I can safely say that debuggers are very cool.

---

From: mulix <[email-masked]>
Date: Sun, 6 May 2001 20:56:36 +0300 (IDT)

> that inorder to be more like Linus (which isn't a bad wish) they should

i dont think that's linus's point, at all. software tools are only bad
when they come INSTEAD OF THINKING. there's nothing wrong with any tool
that makes one's life comfortable, and one's delivery of a product
swiftier, UNLESS, the time saved would've otherwise been spent thinking.

> Which reminds me (and forgive me for discussing female problems in a
> male forum, but after you started with playboy...) for many years I
> was a rabid feminist, naturally I avoided wearing bra's, which are
> obviously yet another symbol of male oppression. Last year I started
> wearing bra's and guess what? They are damn comfortable.

amusing analogy, to say the least :) but flawed. the bra's comfort does
not come instead of something else. a debugger can come instead of
thinking.

> you can certainly work without them, but they are damn comfortable.

you are doing an injustice to linus, here, chen. he doesnt object to
debuggers on "hacker" value, he objects to them because they can lead to
superficial solutions.

> ASP which has a debugger - I can safely say that debuggers are very cool.

aye, a debugger is nice. but thinking hard about the problem and PROVING
your solution is correct, for all cases (which is my preferred coding
technique, for tough problems) makes for much better code. and that's
the whole point, isn't it?

-- 
mulix
http://www.advogato.com/person/mulix

linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead

---

From: "Nadav Har'El" <[email-masked]>
Date: Mon, 7 May 2001 00:47:47 +0300

On Sun, May 06, 2001, Chen Shapira wrote about "RE: [hackers-il] Maintenance of 10,000,000 lines long application s?":
>...

Thanks for sharing ;)

> ASP which has a debugger - I can safely say that debuggers are very cool.

One thing the anti-debuggers on this list missed as the two modes of
programming I mentioned in a previous post.

When I'm in the first mode, i.e., writing a (relatively) big chunk of new
code I almost never use a debugger. Sometimes I use a few "printf"s, but
not a debugger. I think a lot, code, compile and check, but almost never
find a need for a debugger. One thing about this mode of programming is
that I'm adding new code incrementally, so if a bug pops up I usually
instantly know which part of the code the bug is, and just read it, think
about it, and fix it.

But when I get to the second mode, I.e., after the big chunk of new code is
finished and I need to test it and get rid of all the bugs, I sometimes use
a debugger. This is because when you're faced with a completed program (even
a relatively small one, say 5,000 lines) and your program suddenly quits
with s Segmentation Violation without saying anything, let's face it - it's
pretty handy to run gdb and ask for a stack trace and find where that bug
is coming from! What else am I to do - sit around for days reading my entire
code (most of it is probably unrelated to the bug), pondering about it, proving
it works, etc.? No - that won't work if the bug is just a silly buffer
overflow (or pick you favorite language's typical reason for bugs), unless
you have very keen eyes. A former co-worker of mine used to ask me to "plant"
bugs and errors, on purpose, in programs he wrote, so that he could check
the efficiency of his proofreading his code. But not everybody likes to
work that way. I don't like tyo work that way.

Of course this debugging is no substitute for doing a good and smart job on
the _first_ mode (when you're writing the bulk of the code). If you write a
code that is supposed to handle 10 cases, but you forget to handle 5 of them
because you didn't think of all cases, then all the debuggers in the world
aren't going to help you. If you're trying to search a database of 1,000,000
entries and choose a linked-list as your data structure, not even God can
help you ;)

And this is also where proofs come in: sometimes, especially in graph-theory-
related algorithms, you find that unless you formally prove (not with those
silly Russel-Whitehead-like symbolisms, with English text!) that your
algorithm works, you'll never really know if does. If you're smart (and well-
educated in graph theory) the first algorithm you think of might work, and
the proof would look like a waste of time. But some days you're not as lucky,
and the algorithm you devised is wrong, and won't work for 1 in every 10
cases. How will you know that without proving? (if you think by exhaustive
checking, what happens if the algorithm is wrong in 1 in every 1,000,000
cases?)

BTW, "proving" does not always mean writing a formal (but still textual)
proof on paper. It is necessary for more complex algorithms which you make
up on your own, but in some simpler algorithms, or algorithms you build
from known (and proven) "building-block" algorithms, you just need to "prove"
for yourself that you indeed thought of all the possible cases. Some
programmers don't even bother to do that. And they are just as bad as those
Engineers that don't bother to think of all the cases and the implications
of what you do (e.g., look what happened to the Maccabia bridge, the Arad
festival desaster, the collapsed bridge over the highway a few years ago,
etc.)

People don't usually think of bugs as life-threatenings, but some are -
consider for example the code in neuclear-warhead carrying ICBMs, or the
code inside implanted pacemakers or defibrillators, one of which I happen to
have implanted in my chest (here, I shared a personal thing too ;)).
Slashdot had a whole discussion about Internet-connected defibrillators
yesterday, in
	http://slashdot.org/science/01/05/06/0036212.shtml

As one of my random signatures says:

	A good programmer is someone who looks both ways before
	crossing a one-way street.

-- 
Nadav Har'El                        |       Monday, May  7 2001, 14 Iyyar 5761
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |All those who believe in psychokinesis,
http://nadav.harel.org.il           |raise my hand.