Re: another take on hackers and painters

[Paul Prescod <address@hidden>]

Jacob Matthews wrote:

>
>
> This is kinda the crux of the argument, though I don't see any explicit
> statement of it: the danger of the 3 + "12" feature isn't in the
> expression 3 + "12", it's in the expression 3 + "oops!". If 3 + "oops!"
> raises an exception, or dies, or takes some other action that will force
> the program to either deal with it or stop right there, there's no
> problem. You've just written convenient syntax for a perfectly reasonable
> function when dealing with small-scale parsers.

I want to emphasize this point of Jacob's. In my mind, the problem is 
not the auto-conversion. That's just a rule you learn. A little bit of a 
weird one, in my mind, but a rule nevertheless.

I think that the real problem reported by (ex-) Perl users is that Perl 
sometimes sees string values that do not have reasonable integer 
representations and rather than telling you that it just guesses that 
you meant for the value to be 0. Often that will mask error conditions 
(not just potential logic bugs, but errors that have been triggered). I 
have a hard time believing that this is the behaviour you want often 
enough for it to be the default. For the rare cases where you want 
"convert the number if it is a number otherwise give me 0" I'd rather 
say so explicitly. 0 is not necessarily the best fallback value anyhow.

As an analogy, you could have a "feature" that if you try to read a file 
that doesn't exist you get back an empty file rather than an error. 
Might be useful once in a blue moon but it would more often cause your 
program to keep running after a critical failure.

  Paul Prescod