Re: [dev] Lexers and parsers

On Thu, Aug 20, 2009 at 3:43 AM, David Tweed<david.tweed_AT_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