Perl is worse!

Paul Boddie paulb at infercor.no
Fri Jul 28 12:46:44 EDT 2000


Steve Lamb wrote:
> 
> On Fri, 28 Jul 2000 10:42:15 +0200, Paul Boddie <paulb at infercor.no> wrote:
> >Having seen Perl's behaviour in cases like the one Tim quoted, albeit in the
> >following form...
> 
> >  1 + $variable
> 
> >(trying to remember Perl syntax) where $variable is some text which should
> >have been a number but for various reasons happened to be something like
> >"foo", I would rather my chosen implementation language did raise an
> >exception than pretend nothing was wrong.
> 
>     This is a matter of opinion.  I have to ask, where were your data checks
> in the first place?

Well it would be good to check the data first, but then if you're a Perl coder
who's confident enough to let the interpreter work out "the right thing" and not
warn you about what ancient BASIC interpreters would call a "type mismatch",
you're probably going to be fairly easy going about where your data came from.
If you are, on the other hand, careful about the value of $variable, I can't see
why you wouldn't welcome a bit of type checking.

> >What about 1 + "23"? Is "23" a decimal number or a hexadecimal number or
> >what?
> 
>     Decimal.  Is that not decimal form?

It could be octal, for example, or any number of other bases. Wherever the data
came from might assume the base of the number and not mention it explicitly. I
suppose you want to decide the base with prefixes, as in 1 + "023". At that
stage, you might as well be writing 1 + string.atoi("23", 8).

>     Nope.  1 + "foo" = 1.  Perl uses the a different syntax to put strings
> together.  + is only a mathematical operator, not a math and string operator.

Yes, I remember this now. And the comparison operators are different for strings
and numbers, aren't they? That leads to some interesting results too.

> >whereas 1 + "foo" is meaningless to almost everyone except Perl coders.
> 
>     But 1 + "1" is not.

Well, I could certainly guess what you mean, but there are a number of reasons
why we tend not to leave the interpretation of program code to the imagination
of the reader. After all, program code is a form of message, communicated to
both machine and to other humans. Larry Wall may want to encourage poetically
expressive code, but I would rather see unambiguous code which works as the
writer intended and as the entire audience expects. (That's the audience who
have read the rule book, of course.)

Regards,

Paul



More information about the Python-list mailing list