Interesting talk on Python vs. Ruby and how he would like Python to have just a bit more syntactic flexibility.

[Steve Holden]

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/