On Wed, Aug 19, 2009 at 6:18 PM, Kurt H Maier<karmaf...@gmail.com> wrote: > On Wed, Aug 19, 2009 at 11:49 AM, David Tweed<david.tw...@gmail.com> wrote: >> what would be most effective in tracking >> down the inevitable problems when there's a bug in the user input >> and/or mismatched input, particularly if it happens in the middle of a >> pipe process: how are you going to report which part of the input >> stream was wrong, particularly if it doesn't exist on its own, in a >> way which is effective for a human to track down the problem? > > Your position is that this is a bad idea because a hypothetical user > might screw up? And then it would be hard to figure out how? You > must be a python programmer. The rest of us trust ourselves enough to > use computers. 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.
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". 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. 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. 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. -- cheers, dave tweed__________________________ computer vision reasearcher: david.tw...@gmail.com "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
