Perl is worse!

[Steve Lamb]

On 27 Jul 2000 17:56:55 GMT, Martijn Faassen <m.faassen at vet.uu.nl> wrote:
>Hmm. You seem to expect that strings and other things will be automatically
>coerced to integers whenever a function expects an integer. I think that's
>pretty scary; when I pass in the wrong thing to a function I *want* it to
>complain, as it's very likely I did it by accident. 

    The problem there is you're thinking in terms of separate data types.  I
prefer the freedom of thinking in /DATA/.  Not types, just data.  1.  Is that
a string?  Is it an integer?  Is it a floating point number?  Yes, it is all
three.

1.21 / 1
1 + 1
"My keycode is simple, 1."

>I don't want things to work by accident. Perhaps you're missing that this
>'problem' is also a 'feature'; you get less 'weird' bugs due to the fact that
>your program keeps running long after your data got coerce-mangled to death.
>Python would tend to throw exceptions as soon as it went wrong.

    I've never gotten 'weird' bugs from Perl taking the data type from the
context of the operation at hand.  Not even in my early days of Perl.  I won't
say there weren't got'chas that got me, but it was quite liberating not having
to worry about thinking in terms of how the computer sees the data and,
instead, having the computer see the data as /I/ see it.  

    Furthermore, I have already gotten my first 'wierd' Python bug and it is
wierder, by far, than anything I hit in Perl.  Even when I was debugging the
code (love the debugger!) I couldn't understand what was going on.  What's
more, in the context of the script, it shouldn't have happened.

def foo():
  print "foo"
foo

>>> def foo():
...   print "foo"
... 
>>> foo
>>> <function foo at 806ef00>

    Sure, works nice in interactive mode.  You'd think when I left that in my
script that Python would have tossed it's cookies.  No.  All I saw was a
statement the parser took and the debugger was showing no call being made even
when stepping through the code.  Newbie mistake, sure, but certainly one of
those that if we want to be strict about what goes where should have been
caught.

>So perhaps you're missing the important tradeoff here.

    What, strict checking versus TMTOWTDI?  If we're going to have the strict
checking why, then, don't we have typing up front instead of the half-typing
we have now?  Python gets the initial type from context but won't switch types
based on context?  Might as well force people back into declaring variables in
certain types since that is implicitly what we have now.

>All right, for this particular case I suppose one could get used to
>this kind of coercing. But in general? I'd need to *remember* it all,
>right?

    Nope.  You stuff a number into a scaler it is a number but can be used as
a string.  Not that hard to remember.  Much easier, in fact, that having to
remember to declare everything from the onset or declare it each time you need
to use it in a particular context much less having to put in checks in case
you're trying to declare something into something which it cannot be morphed
into.

    Simply stated, main reason I don't do C, don't do Java, and dropped Pascal
so long ago, the frustration of not being able to take data of one "type" and
use it in a different context without jumping through 20 different loops
depending on the particular case.  To me it isn't char, int, longint, unsigned
or signed, strings or whatever, it is data.  Lists and hashes (and in Python,
tuples) are just structures of data.  What "type" that data is is completely
subjective and based on the context of the operation.  To me, a language that
understands that has the feature, not the language that refuses to.

-- 
         Steve C. Lamb         | I'm your priest, I'm your shrink, I'm your
         ICQ: 5107343          | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------