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

[Steven D'Aprano]

On Thu, 18 Feb 2010 06:15:20 -0800, Steve Howell wrote:

> On Feb 18, 1:23 am, Duncan Booth <duncan.bo... at invalid.invalid> wrote:
>> Jonathan Gardner <jgard... at jonathangardner.net> wrote:
>> > On Feb 17, 12:02 am, Lawrence D'Oliveiro <l... at geek-
>> > central.gen.new_zealand> wrote:
>> >> In message
>> >> <8ca440b2-6094-4b35-80c5-81d000517... at v20g2000prb.googlegroups.com>,
>>
>> >> Jonathan Gardner wrote:
>> >> > I used to think anonymous functions (AKA blocks, etc...) would be
>> >> > a nice feature for Python.
>>
>> >> > Then I looked at a stack trace from a different programming
>> >> > language with lots of anonymous functions. (I believe it was
>> >> > perl.)
>>
>> >> Didn’t it have source line numbers in it?
>>
>> >> What more do you need?
>>
>> > I don't know, but I tend to find the name of the function I called to
>> > be useful. It's much more memorable than line numbers, particularly
>> > when line numbers keep changing.
>>
>> > I doubt it's just me, though.
>>
>> Some problems with using just line numbers to track errors:
>>
>> In any language it isn't much use if you get a bug report from a
>> shipped program that says there was an error on line 793 but no report
>> of exactly which version of the shipped code was being run.
>>
>> Microsoft love telling you the line number: if IE gets a Javascript
>> error it reports line number but not filename, so you have to guess
>> which of the HTML page or one of many included files actually had the
>> error. Plus the line number that is reported is often slightly off.
>>
>> Javascript in particular is often sent to the browser compressed then
>> uncompressed and eval'd. That makes line numbers completely useless for
>> tracking down bugs as you'll always get the line number of the eval.
>> Also the way functions are defined in Javascript means you'll often
>> have almost every function listed in a backtrace as 'Anonymous'.
> 
> If this is an argument against using anonymous functions, then it is a
> quadruple strawman.

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.



-- 
Steven