comment on

Some good points here:

Multiple implementations are good:: Code should be written to a language spec, not to a particular implementation. Observe how clear ISO C is about "x=x++" (it is undefined behaviour). Perl isn't so clear; what's worse is that, since there's only one implementation, "suck it and see" might be considered a good answer (it isn't, but only because of the possibility of a later implementation changing).
Function parameters: The Perl way makes some nifty things possible, but it doesn't "make the easy things easy".
Docstrings: (Stolen shamelessly from Lisp, of course). Perl doesn't have an interactive mode (but see my RFC 184 for Perl6, which I hope will be approved), but even so docstrings would be nice. Not that PODs are bad...

Some of the points are awful:

Less typing with Python:

No "concrete examples" to show this; a study of a short program implemented in both languages would go a long way to convince Perlers of this. Especially given that the claim is a bit odd -- most Pythoners I spoke to were enamoured of their language's verbosity, and said that made it better than Perl.

But WHY is this a measure of language quality? Surely Perl wouldn't be a better language if we removed length, on the grounds that y///c is one keystroke less?

Here's what put me off Python:

No closures

When people say Perl lacks closures, they mean you have trouble if you define a named sub inside a named sub (and try to return it). Python is much worse, though: it invents a new concept of "scope". You have "outer scope" (globals, really) and "inner scope" (dynamic variables, like local creates in Perl). You cannot write

def adder(x):
  return lambda y: x+y

a = adder(5)
print a(3)
[download]

because `x' is lost. The manual says to fudge it with default argument values, by drilling your variables down into the scope:

def adder(x):
  return lambda y,a=x: a+y
[download]

This is horrible! After a=adder(5), a(3) gives me 8, but so does a(4,4).

Closures aren't some academic abstraction; for instance, they probably form the basis of the most readable, intuitive style for coding Perl/Tk (or any other GUI).

Regexps

What can I say? Perl does it better. I use regexps a lot; this "little language" is immensely powerful and intuitive.

Surprisingly, most of Python's real advantages have been eliminated, too!

Tuples
Internals said to be "nicer": If you've ever tried to write any non-trivial XS (or Swig or Inline), you probably cursed Perl. My Pythoneer friends say Python internals are nicer, and better-documented.
Nice mechanism for "obsoleted" and "proposed" language features.

In reply to Re: Perl vs. Python: Looking at the Code by ariels
in thread Perl vs. Python: Looking at the Code by mothra

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		`&`
	<		`<`
	>		`>`
	[		`[`
	]		`]`

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.


Keep It Simple, Stupid
	PerlMonks