[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: another take on hackers and painters
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.