Re: [dev] Lexers and parsers

From: David Tweed <david.tweed_AT_gmail.com>
Date: Thu, 20 Aug 2009 18:29:34 +0100

On Thu, Aug 20, 2009 at 1:37 PM, Kurt H Maier<karmaflux_AT_gmail.com> wrote:
> On Thu, Aug 20, 2009 at 3:43 AM, David Tweed<david.tweed_AT_gmail.com> wrote:
[snipped]

> 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.

Bear in mind I think you unleashed the first "insulting turn of
phrase" refering to me as a someone who "doesn't trust..."
Incidentally, the point of my signature isn't anything to do with
Python (it's only in there because it needs to be to understand the
sentence), it's about people who take that view of software
maintainability.

You also keep assigning to me things that I didn't say, and don't seem
to have read the sentences that actually appear in the email that I
wrote. The above is a prime example: where have I said my opinions
should have greater weight than those of others? This makes any kind
of constructive analysis of the issue pretty much impossible.

I admit I could have been slightly more polite by not giving a reason
why most programmers don't want to think about debugging as one of the
most important things to design into a program, and then bolt it on as
a poor afterthought which means that most debugging facilities are
substandard.

> 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.

This is the one technical point in your email. Again I'm not
terrified, I'd just prefer to use my coding time as efficiently as
possible. You certainly could do things this way, but my point was
that it'd be a good idea to think about possible BETTER mechanisms of
understanding the behaviour for debugging before getting in to debates
about whether an ASM coded parser is or isn't a problem. (I was being
serious when I said part of what makes pipes great is that they DON'T
do sophisticated things; however parsers do.) Likewise I'm not
remotely condemning the idea, merely pointing out that there's a big
"issue" there. If a good solution is found for the issue, I'm all for
it. It's also not something I'm trying to force on people by "my
opinion having greater weight", but my opinion about what's most
important. My coding style isn't incompatible so much as without any
greater thought to debugging things effectively it seems like the
doing everything on the fly is likely to cost me more time (given that
I don't write perfect parser definitions, etc, first time) than doing
it the other way.

-- 
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
Received on Thu Aug 20 2009 - 17:29:34 UTC

This archive was generated by hypermail 2.2.0 : Thu Aug 20 2009 - 17:48:01 UTC