On Thu, Aug 20, 2009 at 1:37 PM, Kurt H Maier<karmaf...@gmail.com> wrote: > On Thu, Aug 20, 2009 at 3:43 AM, David Tweed<david.tw...@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.tw...@gmail.com "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
