Why use Perl when we've got Python?!

[John Stevens]

On 14 Aug 1999 02:55:19 GMT, Eric Bohlman <ebohlman at netcom.com> wrote:
>John W. Stevens (jstevens at basho.fc.hp.com) wrote:
>[quoting someone whose name was lost]
>: > It is wrong from the Larry's principle that things that behave
>: > differently should have different appearances.
>: 
>: Then why doesn't Perl have two different operations for
>: assign/reassign, vs. add to an array?  A tiny little violation of
>: Larry's principles, that.
>
>Nope.  "Behave differently" hear means "accomplish two different tasks."  
>Comparing two strings to see if they're equal lexically is not the same 
>task as comparing two strings to see if they're equal numerically.  

Right.  Do you see what I am saying?  Automatic coercion (from string to int)
created a problem.  The problem was dealt with by making a change that
impacts the language.

As well as providing a huge opportunity for defects, the complexity
of the language was increased.

>Putting a particular value in a particular position in an array that 
>already holds a value *is* the same task as putting a particular value in 
>a particular position of an array that does not yet hold a value; the 
>only difference is in the internal details of how to accomplish it.

Yes, but the context of this was TC's comparison with Python's lists.

For an ARRAY, your argument makes sense.  For a list, it does not,
yet TC was taking Python lists to task for not acting like arrays.

On the other hand, Perl's behavior encourages defects:

$array[$index] = $newWord;

The program ran for a very long time, then the system started thrashing,
then it core dumped.

The value of $index?  Very, very large.  Perl happily tried to allocate
Gigabytes worth of core.

>Of course, the OOically-correct way to handle the string comparisons is 
>to define a base class, ComparableString, and two subclasses, 
>LexicallyComparableSting and NumericallyComparableString, along with 
>polymorphic operators that understand which class they're comparing to 
>and apply the correct comparison method.  But there are cases where you 
>may want to do *both* comparisons on a string,

I would disagree with the last part . . . it makes sense to encode
a number as an ASCII string, then to decode it back to an integer,
but to compare two strings as if they were numbers, again, allows
for far to many defects.

For example (another real bug, here):

$result = $Total / $count;

Generated a division error.  $count contained the string: "Payroll". . .

>and to be OC you then have 
>to cast the string to the appropriate type;

Cast?

>the Perlish way of picking 
>the operator director is IMHO easier and more maintainable; in my 
>experience, heavy casting makes code unreadable.

Casting is a poor idea, I agree.  Explicit conversion, however, is
more maintainable and much easier to use in a way that reduces
defect rates.

John S.