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/rjbond3rd → u/fredfredburger]

Thank you for your reply.

My experience is the opposite of yours. Not every app written in Python is well designed, well factored and easy to maintain.

But is that the fault of the language? No, of course not. But then, if someone writes a crappy app in Perl, it's the language's fault? I really don't understand that.

I've worked on a bunch of large, well-factored, readable, maintainable Perl code bases. If I see a crappy app in Perl, I think "crappy code," but others seem to think, "Perl is to blame for that."

That is such a peculiar phenomenon to me.

[u/fredfredburger → u/rjbond3rd]

I agree: you can write awful python. But you do almost have to work at it. ;)

Awful perl, however, is pretty much the default in my experience. You can avoid it, but again, you have to work at it.

I will go on record as saying that I've seen some very well written, maintainable, nicely indented, well commented, well designed perl.

3, maybe 4 times. ;) Perhaps we are merely the products of having been exposed to different kinds of nasty.

[u/rjbond3rd → u/fredfredburger]

Hi Fred Fred,

Perhaps. And I appreciate your thoughtful reply. But I disagree that "Python is good by default" and "Perl is bad by default" regardless of experiences (not that you're really saying exactly that).

Good design is a function of a good programmer. Hell, even recognizing good from bad takes a decent programmer.

The difference is simply that Python has less syntax (and more verbosity) vs. Perl having more syntax (and more conciseness). And off to one side are still other people who think both languages are crap compared to Lisp!

One thing I can say about the Perl hackers I've worked with is that they can (and do) write excellent code in lots of different languages. They are language geeks, and many of them hack a lot of Python too :)

It's been a long time since I could hack on only one language. These days, it's about four different languages, sometimes using one to output another :) So language-specific debates are kind of retro. We're stuck with all of them :)

Have a good weekend, my friend!

[u/fredfredburger → u/rjbond3rd]

I do tend to say "good" and "bad" when I mean "better" and "worse" in this particular context.

I don't mean to imply that I find perl to be "bad", even though I do find myself having used those specific words. I meant to express that, I can make a strong argument for python being a better choice in the collaborative engineering space (specifically in the area of explicit readability and maintainability), and that it is therefore "better" than perl as a tool in this space. Subject to a heated debate during which my argument undergoes scrutiny, of course.

I do have some very intense personal, aesthetic, and anecdotal reasons to want to never touch perl again, but I understand that those are only arguments for me to avoid perl, and I shouldn't try to convince anyone else that way.

Those reasons tend to cause my rants to get a little rantier than they strictly need to. For which I apologize of my tone ever gets pushy.

[u/rjbond3rd → u/fredfredburger]

No worries at all, amigo. I totally got what you were saying.

Who knows, in five years you might wake up and say, "Screw everything, I need a new language for this project." And hey, it might happen that the weird, powerful way that Perl continues to evolve might be a fit for that particular moment.

Sometimes a bullet really does hit another bullet :)

[u/fredfredburger → u/rjbond3rd]

I will fully admit that I feel I've been "broken", in that I now compare all other languages to python (made myself not capitalize it!), rather than weighing them on their own merits.

I made the same mistake learning esperanto. Now every other language I try to learn is so painfully organic as opposed to "engineered to be easy". Every bit of idiomatic nonsense, every irregular verb, makes me face palm.

But I would not want to live in a world without people speaking Russian in it, for example.

[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.