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)
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
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.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
|