Perl is worse!

[Alex Martelli]

"Steve Lamb" <grey at despair.rpglink.com> wrote in message
news:slrn8o3jap.49c.grey at teleute.rpglink.com...
    [snip]
> >But, back to %members...:
> >Why organize it like that, rather than just index it directly with a
> >(name,number) pair?  Presumably, because Perl cannot use a pair as an
index,
> >but wants a scalar?  But that's no problem in Python, so (guessing at
your
> >snipped parts):
>
>     Exactly.  Actually I normally use something like $name."|".$index for
a
> later split().

I hope you remember that in Python there's no need for the joining
and later re-splitting: just putting the pair (tuple) in there is
so much easier and more natural.

> >a single string, but the % operator has the advantage of being
> >easily tailorable
>
>    I never did like the whole placeholder for actual values in print
> statements or other similar constructs.  I fail to see why one must do
that
> instead of putting what you want there.

Among other things, it makes it easy to save/load/change a format-string;
you are encoding that much information as easily-handled data, rather
than as harder-to-handle executable code.  It's also easier to ensure that
the same, identical format-string is used in various places: just use a
variable to identify it.  If/when it changes, it's changed in ONE place;
this is the kind of thing that's harder to do with code.  (You could do
it by moving the formatting into a function, but then what's the
advantage of myformat(name,index) over myformat%(name,index)...?-).

It's a long-running querelle in C++, which suggests a style like
    std::cout << a << b << c;
in place of C's classical printf (format-string-based) approach.

A format-string does have the disadvantage of encoding the type
information _away_ from the object (which you may not think of as
a disadvantage, but most people do:-).  However, in Python this
may not be a problem, since the % operator is defined to call the
string-conversion for the items in the right-hand operand that
correspond to a %s on the left; so, the object can get control
if it wants to, by overriding the convert-to-string special method.

There's nothing stopping a C++ programmer from defining a similar
formatting operator, of course, but it doesn't seem to be happening
much that I can see.


But this is all about occasions in which the formatting really
matters -- when it must match an externally imposed standard,
or it must be displayed to the end-user.  Such formats tend to
be subject to frequent, finicky changes, so having them as
easily changed strings is particularly nice.  When no such
constraint obtains, Python generally permits you to just use
the tuple -- guaranteeing no data loss, maximum simplicity,
directness.  You just don't have to put strings together, to
split them up again later, as much as is usual in Perl (it
was _mandatory_ in Perl 4, which had no rich data structures;
it's still _popular_ in Perl 5, for various reasons).


[about warts]
>     I'm not saying it is the same.  I am just refuting claims that Python
> doesn't have then and that they are, senseless, wretched, horrible or any
> other negative description people care to place on it.  It is different
and as
> someone (you, mayhap?) said that even typing isn't good in all cases.

I'm not quite sure what you're saying, but there's a well-known
URL out there (which I forget, but hope someone else will remind
us of:-), of a well-known Pythonista, collecting Python's warts.
It's good to keep aware of them, particularly in a language that
makes so many of us so enthusiastic, or how will they ever be fixed?
The types-vs-classes dychotomy is mentioned there, maybe that is
what you are thinking of, but it's really a piece of exoterica
which practically strikes very few people.

I doubt you'll find much concurrence that automatic conversion
of strings to numbers in the context of arithmetic is anything
but a <very-negative-description-snipped>.  I've already listed
several reasons (such as the multiplication of operators and
other linenoise this approach implies -- by forcing operators to
determine context, you need separate operators for concatenation
and replication, versus those for addition and multiplication;
by letting type determine context, Python needs far fewer).  Many
more have been listed by others.

You're unconvinced, but I guess that's okay.  But I can't think
of even one area where Perl, as a language, has any advantage at
all over Python (there may be areas not connected to language
design, such as the quality of available books, which are harder
to call).  Why else would I have been so happy, so utterly happy,
to leave 8 years of Perl experience behind and start over from
scratch with Python?

It may have to do with the way my mind (and that of other ardent
Pythonistas) clicks, versus the mental processes of equally
ardent Perlites.  Python never surprises me; when I don't know
for a fact how something works, and I guess rather than looking
it up, I get it right 90%.  Perl, even after many years, kept
coming up with surprises for me.  I think Python is objectively
simpler: fewer keywords, fewer builtins, no weirdly named
variables with similarly weird effects, etc, etc.  And if you've
ever looked at the C sources of Python versus those of Perl, I
think you'll find just as much difference in complexity.  Very
similar absolute-power, very different complexity-levels to
achieve that power.

But that simplicity be a _virtue_, post-modern redundance a
_vice_, is an aesthetic judgment whose practical value will
no doubt depend on the way each individual's mental processes
work -- and there's a lot of variation in that (thanks be!).

Just as I consider C++'s complexity a vice (but still use it
a lot, because I've found no other technology _dominating_
it, i.e., better for _all_ purposes; and also, _that_ is a
complexity which I managed to absorb at well over 90%, not
fully satisfactorily to me, but easily in the top centile,
and enough for much effectiveness -- _Perl's_ complexity
seems of a different kind...), so I do Perl's.  But I
acknowlegde that they're two languages with an extremely
wide user-base, so, assuming other people have made totally
rational and informed judgments and evaluations (perhaps a
rash assumption; one year ago, for example, I had never
evaluated Python...), there must be many minds for which
such complexity works a charm...


Alex