Steven D'Aprano wrote: > On Thu, 18 Feb 2010 06:15:20 -0800, Steve Howell wrote: [...] > There really ought to be a special level of Hell for people who misuse > "strawman" to mean "a weak or invalid argument" instead of what it > actually means, which is a weak or invalid argument NOT HELD by your > opponent, which you (generic you) made up specifically for the sake of > shooting down. > > If you actually read what Duncan says, he prefixes his response with: > > "Some problems with using just line numbers to track errors". > > Duncan's post is an argument against relying on line numbers as your > main, or only, source of information about the location of bugs in > Javascript. > > In fact, this post is remarkable for the sheer number of actual strawman > arguments that you (Steve Howell) use: > > >> Shipping buggy code is a bad idea, even with named functions. > > Strawman #1: nobody said that shipping buggy code was a good idea, with > or without named functions. But shipping buggy code *happens*, no matter > how careful you are, so you need to expect bug reports back from users. > > (And they will be *hard to find* bugs, because if they were easy to find > you would have found them in your own testing before shipping.) > > >> Obscuring line numbers is a bad idea, even with named functions. > > Strawman #2: nobody said that obscuring line numbers was a good idea. But > apparently compressing Javascript is valuable for other reasons, and > obscuring the line numbers is the side-effect of doing so. > > And even knowing the line numbers is not necessarily useful, because many > bugs aren't due to the line that raises the stack trace. Just because you > know the line which failed doesn't mean you know how to fix the bug. > > >> Having your customers stay on older versions of your software is a bad >> idea, even with named functions. > > Strawman #3: nobody said that staying on older versions is a good idea. > But sometimes it happens whether you like it or not. > > (Although I'd like to point out that from the end user's perspective, > sometimes we don't want your stinkin' new version with all the anti- > features and pessimations and will stick to the old version for as long > as possible. If you don't like it, then think a bit harder before adding > anti-features like fragile, easily-corrupted databases which perform > really, really badly when your home directory is mounted over the > network. I'm talking to you, Firefox developers.) > > And it doesn't really matter: you either end-of-life the old version, in > which case you don't need to do anything about the bug report except say > "upgrade", or you decide to continue support, in which case it doesn't > matter whether the bug is reported for an old version or the latest > version, you still need to fix it. > > >> Not being able to know which version of software you're customer is >> running is a bad idea, even with named functions. > > Strawman #4. > > See the pattern? When you attack a position the other guy hasn't taken, > that's a strawman. When you make a weak argument, it's just a weak > argument. > Next week: Lesson 2 - Ad Hominem Attacks
regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
