Also, at work, my boss HATES people to be on IRC, but for AIM/ICQ they don't really care, in fact we use ICQ
for inter-office stuff all the time.
Isn't this just a little strange? There doesn't seem to be any objective (business) reason to prefer one over the other, so this leaves me wondering if it isn't some sort of cultural bigotry. Kind of like "alcohol is a good drug used by us normal Joe's, but pot is a bad drug used by slackers, long-haired hippy freaks, and people that put their babies in microwaves.
Is IRC the messaging software of choice for liberals and child molesters?
Around 1990, as I recall, a Los Angeles TV station called the embassy of a Latin American country (I forget) to ask for an interview with the ambassador. Unluckily for them, they actually reached the phone number of a local actor, who enterprisingly showed up for the interview in a suit, mustache, and thick glasses. He did it straight, with a nice accent, and then revealed the stunt a few days later.
Congrats to the WTO on having a sense of humor. Is there anyone that doesn't love this stuff?
There is nothing that printf can do for me that a debugger can't.
I think you would benefit by considering how a master programmer (which I don't claim to be) might beneficially use printf's in preference to interactive debugging.
Here's an example that comes to mind. Suppose you have a large software system that depends on some sort of numerical computation library. It may be useful to trace all calls across the library interface, printing the trace in an easy-to-parse manner (perhaps to be checked by another program). It's relatively easy to do this with printf's; it's possible to do with a debugger (by maintaining a debugger script with the required breakpoints, along with breakpoint scripts), but fraught with problems. Maintaining complex debugger scripts is a nightmare.
Also, printf's, or some similar logging mechanism, work just about everywhere. There are plenty of situations where invoking a debugger isn't practical or even possible.
Using a debugger to track down a problem should only take a few minutes. Anybody spending hours just isn't using the tool properly.
Maybe you've never run across a really subtle bug in a large software system before. By subtle, I'm talking about a bug which might occur hours (in execution time) before any externally visible aberrant behavior, during which time it has caused a cascading series of minor errors which finally lead to (say) a crash. You could spend your entire life trying to diagnose a problem like this with a debugger.
I believe that interactive debuggers are very useful in their place, and that a good programmer must master them, but also that they should be used sparingly, and not as a substitute for really thinking about the problem at hand. Personally, I find myself spending less and less time inside a debugger as the years pass, and more and more time making sure my code is constructed so that those kinds of problems don't occur in the first place.
Yes, it's true that newbies should learn how to use interactive debuggers well, but that doesn't mean that knowledgeable programmers make heavy use of them. The best programmer I've ever met made (or repeated) the observation that once you've dropped into the debugger, you've lost. I didn't fully understand the wisdom of this at the time, but now years later I can see that he's about 99% right on this.
The wise programmer uses the right tool for the right job, and an interactive debugger is usually the wrong tool. If you have a core dump, it's worthwhile to take a quick look at the stack dump, etc., but beyond that, you should carefully question time spent on further interactive debugging. It's a mental monkey trap--it feels like work and it's the easy thing to do. And five hours later it'll still seem that way.
The disadvantages listed for printf debugging are either incorrect, or also true for interactive debugging.
Likewise, the advantages listed for interactive debugging are incorrect, or do not consider the tremendous timesuck that interactive debugging can be. Consider, for example, the first point: Yes, you may immediately discover that a null pointer was dereferenced, but this may well tell you nothing about what really happened. The true bug could have occurred hours ago in a completely different part of the program.
Stepping through your program is no replacement for really thinking about what's going on.
This of it this way: You go to a doctor saying you don't feel well. The printf doctor eyeballs you, carefully forms theories about what might be wrong with you and takes various measurements to validate/invalidate those theories. The (interactive) debugging doctor says, "Nurse--scalpel!"
how would the auto industry appear if
autoworkers felt it was their perogative to "be creative" while doing assembly line
work? This is exactly what programmers act like. The smart auto companies give
their line workers time to be creative, during process review, so that they can
concentrate on quality the rest of the time.
I respectfully disagree. First, auto assembly is dramatically different from software engineering (aka programming); the latter consists almost entirely of design activity. Being a programmer is more like being, say, an architect. And a good architect is being creative all of the time.
Second, the best auto companies apparently support their line employees being creative all of the time, too. Those bottom-up process improvements would be the result of time spent thinking creatively while doing assembly work.
Lack of mastery of the basics and inattention to detail are problems, as you say, but they are not caused by excessive creativity. Rather, the problem is lack of experience and judgement, and (as usual) above all, bad management.
I believe that creative thinking is required to develop a fine engineering judgement about questions like just when certain kinds of sorts are and aren't appropriate and why.
For starters, I need to send email to/from clients and be able to say I'm taking reasonable steps to keep their matters secure.
Mostly, though, it's reliability. If someone gets my POP password, I no longer have reliability.
As for kiddie porn, etc., fortunately I find it immoral. In any case, anyone who reads/writes anything on the net they don't want repeated later in the New York Times is a fool.
I'm the original poster. I understand that real (i.e., complete) security is impossible.
All I'm looking for is nominal security. That is, access to my email without passing my password or the email across the network in the clear. This is very basic, but many providers seem not to offer it.
Slashdot Mirror
Isn't this just a little strange? There doesn't seem to be any objective (business) reason to prefer one over the other, so this leaves me wondering if it isn't some sort of cultural bigotry. Kind of like "alcohol is a good drug used by us normal Joe's, but pot is a bad drug used by slackers, long-haired hippy freaks, and people that put their babies in microwaves.
Is IRC the messaging software of choice for liberals and child molesters?
--Mike
I read this as
Congrats to the WTO on having a sense of humor. Is there anyone that doesn't love this stuff?
P.S. "bunny burgers"
I think you would benefit by considering how a master programmer (which I don't claim to be) might beneficially use printf's in preference to interactive debugging.
Here's an example that comes to mind. Suppose you have a large software system that depends on some sort of numerical computation library. It may be useful to trace all calls across the library interface, printing the trace in an easy-to-parse manner (perhaps to be checked by another program). It's relatively easy to do this with printf's; it's possible to do with a debugger (by maintaining a debugger script with the required breakpoints, along with breakpoint scripts), but fraught with problems. Maintaining complex debugger scripts is a nightmare.
Also, printf's, or some similar logging mechanism, work just about everywhere. There are plenty of situations where invoking a debugger isn't practical or even possible.
Using a debugger to track down a problem should only take a few minutes. Anybody spending hours just isn't using the tool properly.
Maybe you've never run across a really subtle bug in a large software system before. By subtle, I'm talking about a bug which might occur hours (in execution time) before any externally visible aberrant behavior, during which time it has caused a cascading series of minor errors which finally lead to (say) a crash. You could spend your entire life trying to diagnose a problem like this with a debugger.
I believe that interactive debuggers are very useful in their place, and that a good programmer must master them, but also that they should be used sparingly, and not as a substitute for really thinking about the problem at hand. Personally, I find myself spending less and less time inside a debugger as the years pass, and more and more time making sure my code is constructed so that those kinds of problems don't occur in the first place.
The wise programmer uses the right tool for the right job, and an interactive debugger is usually the wrong tool. If you have a core dump, it's worthwhile to take a quick look at the stack dump, etc., but beyond that, you should carefully question time spent on further interactive debugging. It's a mental monkey trap--it feels like work and it's the easy thing to do. And five hours later it'll still seem that way.
The disadvantages listed for printf debugging are either incorrect, or also true for interactive debugging.
Likewise, the advantages listed for interactive debugging are incorrect, or do not consider the tremendous timesuck that interactive debugging can be. Consider, for example, the first point: Yes, you may immediately discover that a null pointer was dereferenced, but this may well tell you nothing about what really happened. The true bug could have occurred hours ago in a completely different part of the program.
Stepping through your program is no replacement for really thinking about what's going on.
This of it this way: You go to a doctor saying you don't feel well. The printf doctor eyeballs you, carefully forms theories about what might be wrong with you and takes various measurements to validate/invalidate those theories. The (interactive) debugging doctor says, "Nurse--scalpel!"
Thanks!
I respectfully disagree. First, auto assembly is dramatically different from software engineering (aka programming); the latter consists almost entirely of design activity. Being a programmer is more like being, say, an architect. And a good architect is being creative all of the time.
Second, the best auto companies apparently support their line employees being creative all of the time, too. Those bottom-up process improvements would be the result of time spent thinking creatively while doing assembly work.
Lack of mastery of the basics and inattention to detail are problems, as you say, but they are not caused by excessive creativity. Rather, the problem is lack of experience and judgement, and (as usual) above all, bad management.
I believe that creative thinking is required to develop a fine engineering judgement about questions like just when certain kinds of sorts are and aren't appropriate and why.
As a prior victim of Exchange, I feel your pain.
There can be, however, a bright side. Please name your company so that we can short it. :-)
- corporation wants to read your email
- corporation files frivolous lawsuit
- corporation subpoenas your email and reads it
- corporation drops frivolous lawsuit
- corporation continues on its merry way
--MikeMostly, though, it's reliability. If someone gets my POP password, I no longer have reliability.
As for kiddie porn, etc., fortunately I find it immoral. In any case, anyone who reads/writes anything on the net they don't want repeated later in the New York Times is a fool.
All I'm really hoping for is a provider that
The second point may be too much to ask, but the first certainly isn't.
The email and shell could be separated, a la sourceforge.
All I'm looking for is nominal security. That is, access to my email without passing my password or the email across the network in the clear. This is very basic, but many providers seem not to offer it.
When and where is Emmett's talk? If you don't bill it, they won't come...