Re: [dev] Lexers and parsers

On Wed, Aug 19, 2009 at 6:18 PM, Kurt H Maier<karmaflux_AT_gmail.com> wrote:
> On Wed, Aug 19, 2009 at 11:49 AM, David Tweed<david.tweed_AT_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.tweed_AT_gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot