Joel Berger

That said I will absolutely not concede that Python is easier to read than Python

I don’t see how it can be.

Working in a mixed Perl/Python shop, I find a number of things that don’t work well in both languages.

One of the odder Python issues comes from our style guideline of lines less than 80 columns long. Nested indents, even with line continuations, often get really hairy. This is a shame, as 160 is easily handled, and is only a small problem when doing side-by-side diffs. (Over/under is available too.)

We do grouse a bit about some Perl issues, most of which come from pre-Perl 5.0 behaviors, and will be very hard to scrub from the language. For instance, the differing behavior of eof, with and without parens. Or the lack of a name slot for “anonymous” code blocks, when they don’t need to be anonymous, but only created at runtime. Or the difficulty of finding a serializer that can report the code from a coderef (even if just for identification purposes in debug). (There’s probably some way to feed coderefs to a deparser and get something useful back, but I haven’t found it, nor looked in anger.)

My colleagues often get snagged by the sigil/bracket trap, such as accidentally making an arrayref and assigning it to the first element of an array when the intent was just to fill a 1D array; or accidentally making a hashref instead of a codeblock.

My own opinion is that good Perl is somewhat easier to read than good Python, but I would color that with my shallower experience with Python, getting distracted by syntax, list comprehensions (who came up with that crap name? — “list generator” seems clearer), rampant whitespace, and as you say, trailing commas. Perl seems a bit more natural, though because of it’s flexibility it can be abused to a greater extent as well.

The love of Python

print '3' > 2    # True
print 3 > '2'    # False

(I know it is fixed in Python3, which is only used by approx. 2% of the users)

local and global variables

a = 42
def f():
    print('and the answer is:')
    print(a)

f()

Works and prints

print('and the answer is:
42

But

a = 42
def f():
    print('and the answer is:')
    print(a)
    a = 42

f()

Blows up during run-time:

and the answer is:
Traceback (most recent call last):
  File "a.py", line 7, in 
    f()
  File "a.py", line 4, in f
    print(a)
UnboundLocalError: local variable 'a' referenced before assignment

In a nutshell: Python has a fair amount of strange behavior.

@QM: For debugging, I think you want Data::Dump::Streamer if you want to be able to dump the absolute maximum of Perl data structures including coderefs. It optionally comes with a shortcut name “DDS”:

perl -MDDS -e 'sub foo { my $x = shift; return 2*$x; }Dump(\&foo)'

$CODE1 = sub {
           my $x = shift();
           return 2 * $x;
         };

Indentation-based scope plus implicit variable declarations plus no checks until runtime bit me several times the last time had significant contact with Python, on a mid-sized Django project. (It didn’t help that the previous developers had slightly different indentation styles.) It’s especially painful for refactorings like extracting or inlining methods. Cut a chunk of code in one place, paste it in another, and things can go wrong in so many ways as you re-indent the thing to conform to its new environment. “C-y C-M-"? Ha ha, you wish! You get to reindent every line by hand, and if you mis-nest things somewhere, you won’t find out until the function actually runs, if you’re lucky.

I agree to most of what you’re saying, however to me this Python construct is much easier to understand than your Perl equivalent using grep and map:

values = [ item.value for item in list if item.value > 4 and item.name != 'bob']

FYI: You actually have an error in your Perl construct, “item” is not defined in “item->name”: my @values = map { $->value } grep { $->value > 4 && item->name != 'bob'} @items;

I worked in 3 companies that have large Perl code bases (and I’m happy to be using Perl), but map and grep were never used because they’re not easy to understand. We never had any formal rule against them, but people would just write the same code using foreach statements. And this is where a simple Python list comprehension would come in very handy.

thetrb: Having gone through the “ugh, map and grep are so ugly” phase myself, I guarantee you it’s a training issue. I fixed that defect in my perl training on my own by reading the first few chapters of SICP. That book made map, grep and so many other things click very nicely.

List comprehensions are amazing constructs in both python and Erlang. I really miss them in Perl.

I’m so exhausted from the lack of readability of modern Functional programming (recent projects in D3.js and Scala), I cant consciously complain about these two old friends.

Perl gives me more ways to write the same thing, so I get to choose which is the most readable.

Thanks Ovid and Steffen Mueller for the anonymous sub tips. Some of these came up on http://www.perlmonks.org/?nodeid=1048128, with the goal of generating stack traces to report exceptions, where many callbacks are created on the fly. The local *ANON trick doesn’t affect svref2object returns.

There is resistance to adding XS modules to all of our systems (there’s even resistance to adding pure Perl, though not as much).

Next time it comes around, I would revisit the ideas brian puts forth in http://www.effectiveperlprogramming.com/2011/09/enchant-closures-for-better-debugging-output/, as that will have less internal resistance and many benefits. One plus is that the enchanted closures can be tweaked for debugging purposes with little effort.

In several places above there is still a small typo: != ‘bob’ should be ne ‘bob’.

You can always do if test: i += 1 , no newline required. This is about the same as the Perl example.

For list comprehensions, nothing is preventing you from using line breaks to make things more readable:

values = [x.value 
          for x in list
          if x.value > 4 and x.name != 'bob']

I’m a Python developer but I started coding Perl full time since a little bit more than a year. It’s true that Python has many quirks. That happens with any language that is more than 20 years old. But I think Perl probably has more quirks than Python.

I think one reason why people think that Python is more readable is because it’s simpler. Both syntax and semantics are simpler. Less operators, less constructs, less ways of doing things. In practice this means that you can understand any Python code after an afternoon. While the same thing for Perl takes years.

Perl is a very flexible language and a good developer can write beautiful readable code with it. In my experience , however, most of the times that flexibility is used to write ugly code instead.

All languages suck. I have only come across one syntax that I mostly like (unfortunately you cant do much with that particular one).

So Perl v Python arguments centered around syntax are somewhat irrelevant. You will find godawful things in both of them.

For me, the only things that matter are:

(i) lots of powerful libraries

(ii) good documentation

(iii) helpful communities

(iv) speed [for some things]

My main toolkit is made up of Perl, Python, Go, and C.

Perl nails (i), (ii), and (iii). It is the super-glue that allows me to write small programs that do a lot simply because just about everythig has already been written on CPAN

Python is the ants-pants for (i) which has anything to do with math/science/ml

Go is the only choice for (iv) for anything to do with concurrency

C is the closest human-readable thing to the metal, and I use it for (iv) where speed and size is paramount.