On Thu, Aug 20, 2009 at 3:43 AM, David Tweed<david.tw...@gmail.com> wrote: > I'm comparing the viewpoint that you're going to whip up one-off > parsers by piping in inputs and patterns and piping out output versus > a setup where you assemble the input into a file, quite probably using > piping, and then run on that. IMO, part of why pipes are very usable > is that they don't allow you to do anything complicated in an > individual step, so it is possible to effectively debug stuff.
Not everyone uses pipes they way you do. > It's not about "trust ourselves to use computers", I work on jobs > where it is VERY IMPORTANT software to work correctly and reliably, > not just sound "cool" or "radical". Okay, so you're another one who thinks you're more important than the rest of us. Congratulations on your Serious Business. > So I spend a lot of time sitting > there trying to debug what's going on in bizarre cases (including > parsing strange data files from things like IP connected cameras that > can produce really strange HTML if they're polled at the wrong time) > and correcting corner cases and unexpected interactions. No matter how hard you try, I'm not going to turn this into a pissing match. Just keep in mind you're not the only one in the world -- or even on this list -- who turns out mission-critical code, and the fact that you do so doesn't give your opinions heavier weight than other people. > I specifically said I didn't think it was a bad idea, just that at the > design stage people really ought to be considering how to debug stuff > EFFECTIVELY. Unfortunately, in my experience most programmers don't > want to think about debugging facilities (possibly because it offends > their ego to believe that they could write incorrect code that needs > debugging), so some ramshackle stuff gets added on at the very end of > coding that's not very effective. Spending that amount of debugging effort is not incompatible with using pipes to transfer information. > For me to choose writing a parser via piping in on the command line vs > sticking it in a script, I'd have to believe that it'd take less time > doing it on the command line. Given that I DO make mistakes when > coding, that means the debugging has to be at least on a par with the > debugging I can do on scripts and files. Not a condemnation of the > idea by any means, but something that deserves thinking about at the > design stage. I still don't understand why you're terrified of the concept of debugging something involving stdout redirection. It's basically always *easier* to do so, because you can temporarily redirect stdout instead of having to manually code in a buttload of debug output. It seems pretty clear that your coding style is incompatible with this idea, but I can't figure out why that makes it bad. -- # Kurt H Maier
