Chas. Owens wrote: > On Fri, Aug 14, 2009 at 00:21, Uri Guttman<u...@stemsystems.com> wrote: > snip >> i started with punch cards. print was all you had besides thorough and >> deep analysis of your code. that is a talent lost on too many coders >> today. and even today proper use of print is better than any debug >> tool. but it is still a skill to learn, where and what to print and how >> to analyze the results. i have seen many good coders not get that and >> they stick with debuggers. i find the simplicity of print and my total >> control of what gets printed, etc better than learning more commands, >> having to repeat a set of debug commands (yes, you can macro and preset >> them but that is still more work), etc. print is always there in any >> programs (and debuggers have issues with complex sets of processes, and >> daemons and such). > snip > > I have seen the opposite: too many coders sticking with print instead > of picking up a debugger when the situation called for one. I tend to > debug with a combination of looking at the code, logs, and print > statements, but a good visual debugger can be a godsend. The biggest > problem with print statements is that you are modifying the code and > you might inadvertently change something or leave a debug statement in > the code.
...even though I've (mostly) written 'scripts' (albeit hundreds of them), I've always edited code to throw in a print statement for debugging. Over the years, I've tried to devise cleaner ways to toss them in and disable them on command (global $debug and more recently via dispatch or configuration tables). I do very much like debug tools, especially for getting a better understanding of code that I wrote but in my mind may either be ambiguous or confusing. Hence why I'm trying to learn BCP. Hell, I still don't know how to get around writing an external 'trial test' for each individual piece of code before I write it into a program. Most test files I reuse continuously, and just keep overwriting and renaming (which goes against the number one virtue so I'm told). Many times I get pissed off, and the names show. Each to their own I guess, until they figure it out for themselves. After all, if you are a programmer, you must be a logical thinker. Most likely, you need to learn by your own mistakes, but with influence of others. Hence, I'm sure that many people when they first started out have a list like the following of crappy tests laying around, each starting with the same old: #!/usr/bin/perl use warnings; use strict: I've got literally thousands of test and program files laying around on dozens of servers. For this project, it's been easier, given the fact I've integrated version control, a bit of patience, and a lot of reading. Steve ps. I still have the following style of test programs inside of my project directory (yes, I do plan on evaluating the methods I use to name EVERYTHING, even temporary variables and files ;) http://ipv6canada.com/test.txt
smime.p7s
Description: S/MIME Cryptographic Signature
