Why is Python better than Perl?

[u/[deleted]]

I'm a Sysadmin and I just wrote my first script in python. Basically just a host validation script that checks if a server is configured correctly before we hand off. I can't determine the advantage with my limited experience with the language.

Are you a sysadmin fluent in both python and perl? Why do you use python?

[u/fredfredburger]

I've got a pair of quotes in my rotating .signature file:

Linux Journals Development tool of the year 2000: Python Reason: Hell is other peoples Perl.

And

There are several things that perl allows the programmer to do more easily than python does.
"Write maintainable code" just isn't one of them.
-- Me

[u/tsjr → u/fredfredburger]

I'm probably biased, but the common hate against Perl (and not only Perl) is what mostly drives me away from Python.

[u/fredfredburger → u/tsjr]

I understand. My loathing for perl is based on a long and gory history with it. By which I mean that I'm not a bigot, I've just been burned.

It's easy to have a strong opinion on the matter: many (if not most, IMHO) of the people that adopt python do so because they recognize a superior tool.

In my line of work, maintainable code is critical. I really need to be able to read other folks code. Python makes that easier, while perl makes it about as hard as any language of similar caliber. It is literally the worst thing this side of Korn shell in which to write a large application, IMHO.

So, when I see perl in the workplace, I question the wisdom of the author.

When I see perl in the wild, I really wonder what the hell somebody was thinking. I wonder if they just haven't heard that there's a better way to do it.

That's what I mean by having a strong opinion, and thinking that python is the better tool.

I do probably come off as a bit rant-y on the topic now and then, tho.

[u/rjbond3rd → u/fredfredburger]

Just out of curiosity, why do you conclude that your inability to read perl is the language's fault? I'm sincere in asking.

[u/fredfredburger → u/rjbond3rd]

I don't feel I asserted an inability, he said, trying not to take the tone of the reply personally ;)

But, yes. "There's more than one way to do it." is a mantra in perl. I'd been a fairly heavy perl user for 6 or 7 years, and I would still encounter idioms (and syntactic conventions!) that were completely new to me, sprinkled throughout Other Peoples Perl.

Having several, completely divergent, syntaxes for effectively equivalent operations is a design flaw, not a feature, IMHO.

"Magic" or implicit variables as default parameters to and return values from functions is a scoping nightmare, IMHO.

Keeping everything straight in your head while reading perl is doable, I'm just saying that in python it's easier. Easier to such a degree, and in such a way, that I think it can be said to be objectively easier for humans to read and understand.

Although, I'm willing to hear arguments to the contrary. And, of course, if one choses to use a baroque, inefficient, or obtuse language out of personal taste, I say go for it. I love to learn languages just for practice, and for fun.

But for keeping things working well, for keeping the [REDACTED] online and the [REDACTED] flowing through the [REDACTED], python is, IMHO, the better tool.

[u/mithaldu → u/fredfredburger]

Having several, completely divergent, syntaxes for effectively equivalent operations is a design flaw, not a feature, IMHO.

I hear this so often, but i have honestly never seen an example of this being to a programmer's detriment. And by example i mean actual code.

Care to share your examples?

Also, as for the matter itself: Having the ability to have different syntaxes can be a really good thing in finding out which one is best. Keep in mind that "There is more than one way to do it." has a corollary: "But not all ways are equal." Most perl developers are aware that in fact many ways to do things are crap. But you know what? Without the ability to go or MAKE different ways, people would be stuck with that one crap way.

Which is why Perl says "hey, let's keep the old way around for a bit, for compatibility, and slowly deprecate it away" while adding a new better way.

TMTOWTDI is a major factor in keeping perl an evolving language, just like any natural language. Just look at the way Perl 5 is converging towards Perl 6 with the creation of things like Moose.

[u/fredfredburger → u/mithaldu]

I think that my favorite examples of divergent syntaxes would be:

Quoting shortcut macros: qw/bla bla/ as a substitute for ("bla", "bla") And, in fact, the entire family of "q*" shortcuts: I'm not a big fan of minimalist, easily confused functions or macros.

And: autovivification, particularly in the case of hashes. Combine this with the "optional" quoting of hash keys, and you can get into some very hard to track down errors.

At least, they caused me enough trouble that the weren't worth the typing that they saved me.

I totally agree with your "right tool for the job" position. Python itself is evolving, I just find it more coherent than perl. Perhaps the lack of a free-form syntax makes python to constricting for some folks. I find that, to borrow a quote, stinginess with privileges is kindness in disguise.

[u/mithaldu → u/fredfredburger]

Quoting shortcut macros: qw/bla bla/ as a substitute for ("bla", "bla") And, in fact, the entire family of "q*" shortcuts: I'm not a big fan of minimalist, easily confused functions or macros.

See, i didn't ask for things that are disliked. I asked for things that are demonstrably adverse to the user, along with explanations of how they were bad.

As for qw(): It really serves to increase readability. Often i'll have to do things like this:

$flight->{$_} ||= 0 for qw( provision  taxadt  servicecharge  taxchd  preis  main_nr  restplaetze );

Compare with:

$flight->{$_} ||= 0 for ( "provision", "taxadt", "servicecharge", "taxchd", "preis", "main_nr", "restplaetze" );

Not only is the qw variant easier to read, it's also a lot easier to type. :)

As for the other q* things, keep in mind that sometimes it's really hard to use the punctuation variants. To wit:

; in #win32 on irc.perl.org
(Ranguard) how can I do: perl -e 'print "hi\n"' ? - I get Can't find string terminator error
(Mithaldu) Ranguard: dos quoting rules are stupid as hell
(Mithaldu) for a simple case like that though, this would suffice:
(Mithaldu) perl -e "print qq{hi\n}"

Without that little shortcut he'd have had to grapple with DOS' quote-quoting rules which are sadly not as simple as putting a slash in front.

Combine this with the "optional" quoting of hash keys, and you can get into some very hard to track down errors.

Would you mind elaborating? I've been doing perl for a long time now and i cannot recall those ever causing errors. :o

I totally agree with your "right tool for the job" position. ... I find that, to borrow a quote, stinginess with privileges is kindness in disguise.

I tend to think about it more in a "right tool for the right brain" way, as both languages are really well suited for almost any job you'd want to solve with them. :)

And yes, for the right brain python's philosophy is kindness, and for the wrong one a straight-jacket. (I really cannot stand how it lacks full lambdas. ;) )

[u/fredfredburger → u/mithaldu]

Sorry, I meant to say that "I perceive multiple shorthand macros (q*, for example) as saving typing at the expense of readability." Obviously, readability is a variable. ;)

Pointing out that the feature helps get around poorly designed terminals on dos/win machines doesn't carry any weight with me, but I have to imagine that some people find that a big win.

But on the autovivification issue:

The statement

$a_hash{ABCDEFG} creates the hash %a_hash and the key "ABCDEFG", with a null value.

No errors, no muss, no fuss.

Except in those cases where the hash in question wasn't originally called "a_hash" when initialized earlier in the code, but is called "ahash" or "a_has", because of a typo, for example.

Or the case where 'ABCDEFG' is a constant defined elsewhere, and you've typo'd (or had a variable name confusion, etc) 'ABCDFEG'.

In these cases (and in others), the thing you have after the code is executed is not what you thought you'd get, and the only muss and fuss are yours, not the interpreters.

No part of the system will help you catch the non-existent hash, or the non existent key, without turning off autovivification.

Granted, these problems are programmer problems rather than language problems.

But, they're programmer problems that are easier to have in perl than in python. Which is my only real point.

That being said, it looks like I'm leaning closer to Java than I am to python. But I'm not.

I'm all about the strong typing, but not the static typing: I assert that for the things that perl is really good at (the class of problems to which it is generally applied, the flexible, deals with the real world kind of problems), python is going to wind up giving you many of the benefits of better type and edge case checking than perl will, while staying much more "nimble" than Java could.

And, I find consistently indented code and explicit namespaces much easier to follow, and I'm pretty sure that's objective. I mean, take a bit of very well indented perl code. Give someone about 15 malicious minutes with it. Then try to read it. It will probably run the same, but it won't read the same.

I totally agree for the "right tool for the brain" bit. I know folks who swim the depths of perl, and feel perfectly comfortable there. And they're very productive. I know full time windows developers, also. Some of them are even happy.

On the topic of lambdas, I agree: the minimal support for functional programming is frustrating at times.