5 ms·

What about Python do you find better than modern Perl? Besides Pygame and NLTK, there's nothing in Python I can't do faster, easier, or more maintainably in Pe

What about Python do you find better than modern Perl? Besides Pygame and NLTK, there's nothing in Python I can't do faster, easier, or more maintainably in Perl. I much prefer Moose to Python's barely-there OO, and nothing compares to the availability (and testing and other infrastructure) of the CPAN.

toddh 16y ago
It's a joke pointing out how Perl has fallen behind in the marketplace. I've written as much Perl as your average bear, to see it lose out has been sad.
- chromatic 16y ago
  By which objective measurements has Perl "fallen behind in the marketplace"? TIOBE is nonsense and noise, and the State of the Computer Book Marketplace has flaws that would make a first year business student blush. I know there's some nebulous buzz factor, but I'm asking about verifiable measurements.
  - phaylon 16y ago
    It might be worth noting that Perl is simply stronger than it appears. The community has very easy ways to communicate information, since Perl has a very good infrastructure. CPAN is easy and doesn't distinguish between rank or other privileges; there's RSS feeds for about everything and you can get a large crowd simply by releasing; Many forms of bugs that are dependent on architecture/environment can be caught by automated testing, or by community members reporting their installation logs through their CPAN client; We still use mailing lists (some of which are closed) because they're easy to manage and are well suited for long big-traffic discussions; we use IRC because of its advantages, and many early developments happen on irc.perl.org, separated from the rest of the IRC world (this isn't bad, just a simple reason); We didn't do forums and online communities that well in the past, but it's starting. There is PerlMonks, but it was always very Perl-specific. Blogging has been adopted by the community a lot, and you can feel its impact when you see more and more people asking about the projects the community enjoys the most at the time (Moose, Catalyst, Dist-Zilla & Co). I heard "Yea, we still make heavy use of Perl in our company, but we didn't follow the community, because isn't Perl on a decline?" many times at CeBit this year. So it's kind of a chicken-and-egg problem. Overcoming it isn't an easy task, but we're heading in the right direction and there's a couple of very smart people working on it.
T_S_ 16y ago
I will take your question seriously and give a very personal reaction. (You are obviously not a flamer, despite 1 comment here.) I haven't tried modern Perl. Maybe you could lure me back to perl. I programmed in perl for about 4 to 5 years on an intermittent basis. I though it was great. I then switched to python because my lab was doing a big project in python. I ultimately became more comfortable with python over perl for some very simple reasons. (1) Readability. I could understand code from others far more quickly. I could understand my own code better after leaving it for a while. (2) Introspection in the REPL. Things like dir and docstrings were very helpful. Initially I felt the perl debugger was superior, but I came to rely on pydb running inside ipython and got along ok. (3) CPAN. Python was way behind but got close enough for me after easy_install became common. scipy and numpy were important to me and the perl variant of these things (pdl, I recall) seemed to lag. (4) OO was always easier for me to grok in python, probably because it was originally designed with OO in mind. In the end I found I really don't like OO all that much, and now I code in haskell, which is an entirely different story. Looking back I would also say that Perl6 was a huge distraction without a big payoff. It should have killed off Perl 5, yet it lives. Seems like Python 3 has similar issues. I haven't done much with Ruby besides skim a tutorial or two and wonder why it has gained so much mindshare. Again, this is strictly a personal assessment and not meant as advice for anyone.
- chromatic 16y ago
  Readability is subjective. Python code frustrates me because I can't tell when blocks end; for some reason, my mind ignores horizontal whitespace in the same way that other people can't understand sigils. Python has long had a huge advantage with its REPL; the Perl 5 debugger is clunky and difficult to use and, despite some heroic refactorings, still a mess. Perl 5 lifted Python's OO model. That's why both languages have an explicit self and why neither language makes a strong distinction between functions and methods. A method is merely a function installed into a namespace and somehow invoked as a method. As for Perl 6, most of everything good that's happened in Perl 5 over the past several years has roots in Perl 6. I'm not claiming that without Perl 6 these things wouldn't have happened, merely that they did as a direct result of Perl 6. This includes the book Perl Best Practices and the Perl testing renaissance.
sreque 16y ago
Not having to deal with copious amounts of accidental complexity needlessly introduced by the language? Just look at the example on the o'reilly page for the Perl Best Practices book which is linked to by this article. In Perl, there's more than one way of creating file handles, and one of them is the older and less effective way. What a useless fact I have to memorize! Perl was actually the first dynamic language I learned, and when I looked online to see how to open a file, I found the old way first. Later on, I was like, "Hey! How do I pass this $@($*& thing to a function!?" So I looked online and found several competing ways to do it. I first learned of the OO way of doing it, but that required rewriting a lot of code. Then I discovered the syntax required to assign your file to a normal variable, which required me only to add sigils to my code! Unfortunately, I never got so far in my newbiedom as to learn the syntax for passing typeglobs around. This page describes the madness so wonderfully as a "perl recipe": http://docstore.mik.ua/orelly/perl/cookbook/ch07_17.htm http://docstore.mik.ua/orelly/perl/cookbook/ch07_17.htm. Yum! And, of course, Steve Yegge describes what I'm saying much better at http://sites.google.com/site/steveyegge2/ancient-languages-perl http://sites.google.com/site/steveyegge2/ancient-languages-p...: "There are no rules, no heuristics, no patterns. It's pure memorization. Commit the Perl Periodic Table of the Operators to memory, and you're officially 1/1000th of the way down the road to Perl Zombiedom. "
- chromatic 16y ago
  I don't know what to tell you other than if you deliberately write clunky code, you'll have trouble understanding and maintaining it. Passing typeglobs around isn't modern Perl; it hasn't been necessary for over a decade (to be specific, it hasn't been necessary since 22 March 2000). ... and I know Steve and I like Steve, but I wouldn't take medical advice from him either for much the same reason.
  - sreque 16y ago
    Steve may not be a medical doctor, but he is a programming language expert, so I really don't get your ad hominem refutation of what he said about Perl. Perhaps you can comment on what he actually said, not who he is? Also, I think you missed the entire point of my post, including the example. I'm also not sure of how else to word it to help you get it. My point was that Perl requires you to deal with a host of issues that have nothing to do with solving your actual computing problem. One simple example of these many thousand idiosyncracies, which the article itself indirectly brings up, is Perl file handles. Even if you know the "modern" way of using them, you still had to go through the learning process to differentiate between the old and new styles, and you still have to commit a bunch of useless facts to memory. Worse, you may still encounter and have to deal with the old way in the wild! I love the description of the perl5i CPAN module at http://search.cpan.org/~mschwern/perl5i-v2.2.2/lib/perl5i.pm http://search.cpan.org/~mschwern/perl5i-v2.2.2/lib/perl5i.pm: "perl5i - Fix as much of Perl 5 as possible in one pragma" Why not use a language that lets you get stuff done faster, instead of a language that's been feature-patched to death to fix the terrible design flaws it began with?
neild 16y ago
I much prefer Python's argument-passing to Perl's barely-there conventions. Python gives me positional arguments, named arguments, named positional arguments, required arguments, and default values. Perl gives me @_. I can, of course, build almost everything that Python gives me using @_, but I'd rather not have to do it all. For example, I can write: def frobnicate(a, b, snozz=True): pass frobnicate(1, 2) frobnicate(a=1, b=2) frobnicate(1, 2, False) frobnicate(1, 2, snozz=False) frobnicate(1) # Error, need to pass at least two args. frobnicate(1, 2, snooze=False) # Error, no such argument. I'm certain there's a "Modern" Perl module that will help with doing this sort of thing, but it's nice to have it there in the language. Back when I wrote a lot of Perl, I'd always end up with something like this: sub frobnicate { my($a, $b, %args) = @_; $args{snozz} //= 1; } frobnicate(1, 2); frobnicate(1, 2, snozz => 0); Of course, this doesn't include any of the basic error checking I get for free in Python. I like having OO support in the language syntax. Yes, Perl has Moose now, but the blending of packages and classes is still there. In Python, I can declare a new class with just a couple lines of code; even a minimal Moose class declaration takes substantially more. For example: class XPathError(Exception): """Base exception class for all XPath exceptions.""" Two lines of code to get a useful class. That, of course, ties into one of Perl's big weaknesses, which is exception handling. I know that there are modules which try to patch over Perl's very weak exception handling model, but again, Python is just so much better. What's the Perl equivalent of this? try: x = int(s) except ValueError: x = 42 Perl's core still uses strings for exceptions, which is just horribly fragile and painful to deal with. Python has solid, pervasive exception handling with exceptions defined as objects in a sane and simple hierarchy. I like the fact that people understand Python. I was a pretty good Perl coder, back in the day, and I like to think I had a quite deep understanding of the language. The problem was that I kept dealing with code written by people who didn't. To some degree, this is a problem in any language, but Perl contains so many traps and pitfalls for the unwary. Consider context. I understand the difference between scalar context and list context. I understand why the following two lines of code are equivalent: foo(1, 2, 3, 4, 5, 6); foo(1, (2, 3, (4), ((((5))))), 6); I understand when the above lines aren't equivalent. But entirely too many people don't understand this. And, in my opinion, they shouldn't have to. I've never once missed list flattening in Python. Perl is big and complicated and powerful. Some of that complexity is wonderful, but I find that I don't really miss any of it. Python isn't as big, and it isn't as complicated, but it's just as powerful for me. I haven't missed CPAN. It's a wonderful collection of code, but Python's PyPi (formerly the cheeseshop) is also wonderful. We could quibble about what packages are available for each language or the technical details of CPAN vs. PyPi, but let's just say that I'm happy with both. I could go on. Let's just say, however, that I've found there's nothing in Perl that I can't do faster, easier, or more maintainably in Python. Oh, there's the occasional area where I take a couple lines more code to do something in Python. There's also the occasional area where I take a couple lines less. But, overall, things just feel cleaner to me in Python. I used to love Perl unreservedly, but I've been over it for some time now. When I go back, the idiosyncrasies that I once found charming just annoy me. I've moved on. You still like Perl, and that's fine. I hope I've given you some sense, however, of why some of us prefer other languages.

toddh 16y ago

It's a joke pointing out how Perl has fallen behind in the marketplace. I've written as much Perl as your average bear, to see it lose out has been sad.

chromatic 16y ago
By which objective measurements has Perl "fallen behind in the marketplace"? TIOBE is nonsense and noise, and the State of the Computer Book Marketplace has flaws that would make a first year business student blush. I know there's some nebulous buzz factor, but I'm asking about verifiable measurements.
- phaylon 16y ago
  It might be worth noting that Perl is simply stronger than it appears. The community has very easy ways to communicate information, since Perl has a very good infrastructure. CPAN is easy and doesn't distinguish between rank or other privileges; there's RSS feeds for about everything and you can get a large crowd simply by releasing; Many forms of bugs that are dependent on architecture/environment can be caught by automated testing, or by community members reporting their installation logs through their CPAN client; We still use mailing lists (some of which are closed) because they're easy to manage and are well suited for long big-traffic discussions; we use IRC because of its advantages, and many early developments happen on irc.perl.org, separated from the rest of the IRC world (this isn't bad, just a simple reason); We didn't do forums and online communities that well in the past, but it's starting. There is PerlMonks, but it was always very Perl-specific. Blogging has been adopted by the community a lot, and you can feel its impact when you see more and more people asking about the projects the community enjoys the most at the time (Moose, Catalyst, Dist-Zilla & Co). I heard "Yea, we still make heavy use of Perl in our company, but we didn't follow the community, because isn't Perl on a decline?" many times at CeBit this year. So it's kind of a chicken-and-egg problem. Overcoming it isn't an easy task, but we're heading in the right direction and there's a couple of very smart people working on it.

T_S_ 16y ago

I will take your question seriously and give a very personal reaction. (You are obviously not a flamer, despite 1 comment here.) I haven't tried modern Perl. Maybe you could lure me back to perl. I programmed in perl for about 4 to 5 years on an intermittent basis. I though it was great. I then switched to python because my lab was doing a big project in python. I ultimately became more comfortable with python over perl for some very simple reasons. (1) Readability. I could understand code from others far more quickly. I could understand my own code better after leaving it for a while. (2) Introspection in the REPL. Things like dir and docstrings were very helpful. Initially I felt the perl debugger was superior, but I came to rely on pydb running inside ipython and got along ok. (3) CPAN. Python was way behind but got close enough for me after easy_install became common. scipy and numpy were important to me and the perl variant of these things (pdl, I recall) seemed to lag. (4) OO was always easier for me to grok in python, probably because it was originally designed with OO in mind. In the end I found I really don't like OO all that much, and now I code in haskell, which is an entirely different story. Looking back I would also say that Perl6 was a huge distraction without a big payoff. It should have killed off Perl 5, yet it lives. Seems like Python 3 has similar issues. I haven't done much with Ruby besides skim a tutorial or two and wonder why it has gained so much mindshare. Again, this is strictly a personal assessment and not meant as advice for anyone.

chromatic 16y ago
Readability is subjective. Python code frustrates me because I can't tell when blocks end; for some reason, my mind ignores horizontal whitespace in the same way that other people can't understand sigils. Python has long had a huge advantage with its REPL; the Perl 5 debugger is clunky and difficult to use and, despite some heroic refactorings, still a mess. Perl 5 lifted Python's OO model. That's why both languages have an explicit self and why neither language makes a strong distinction between functions and methods. A method is merely a function installed into a namespace and somehow invoked as a method. As for Perl 6, most of everything good that's happened in Perl 5 over the past several years has roots in Perl 6. I'm not claiming that without Perl 6 these things wouldn't have happened, merely that they did as a direct result of Perl 6. This includes the book Perl Best Practices and the Perl testing renaissance.

sreque 16y ago

Not having to deal with copious amounts of accidental complexity needlessly introduced by the language? Just look at the example on the o'reilly page for the Perl Best Practices book which is linked to by this article. In Perl, there's more than one way of creating file handles, and one of them is the older and less effective way. What a useless fact I have to memorize! Perl was actually the first dynamic language I learned, and when I looked online to see how to open a file, I found the old way first. Later on, I was like, "Hey! How do I pass this $@($*& thing to a function!?" So I looked online and found several competing ways to do it. I first learned of the OO way of doing it, but that required rewriting a lot of code. Then I discovered the syntax required to assign your file to a normal variable, which required me only to add sigils to my code! Unfortunately, I never got so far in my newbiedom as to learn the syntax for passing typeglobs around. This page describes the madness so wonderfully as a "perl recipe": http://docstore.mik.ua/orelly/perl/cookbook/ch07_17.htm http://docstore.mik.ua/orelly/perl/cookbook/ch07_17.htm. Yum! And, of course, Steve Yegge describes what I'm saying much better at http://sites.google.com/site/steveyegge2/ancient-languages-perl http://sites.google.com/site/steveyegge2/ancient-languages-p...: "There are no rules, no heuristics, no patterns. It's pure memorization. Commit the Perl Periodic Table of the Operators to memory, and you're officially 1/1000th of the way down the road to Perl Zombiedom. "

chromatic 16y ago
I don't know what to tell you other than if you deliberately write clunky code, you'll have trouble understanding and maintaining it. Passing typeglobs around isn't modern Perl; it hasn't been necessary for over a decade (to be specific, it hasn't been necessary since 22 March 2000). ... and I know Steve and I like Steve, but I wouldn't take medical advice from him either for much the same reason.
- sreque 16y ago
  Steve may not be a medical doctor, but he is a programming language expert, so I really don't get your ad hominem refutation of what he said about Perl. Perhaps you can comment on what he actually said, not who he is? Also, I think you missed the entire point of my post, including the example. I'm also not sure of how else to word it to help you get it. My point was that Perl requires you to deal with a host of issues that have nothing to do with solving your actual computing problem. One simple example of these many thousand idiosyncracies, which the article itself indirectly brings up, is Perl file handles. Even if you know the "modern" way of using them, you still had to go through the learning process to differentiate between the old and new styles, and you still have to commit a bunch of useless facts to memory. Worse, you may still encounter and have to deal with the old way in the wild! I love the description of the perl5i CPAN module at http://search.cpan.org/~mschwern/perl5i-v2.2.2/lib/perl5i.pm http://search.cpan.org/~mschwern/perl5i-v2.2.2/lib/perl5i.pm: "perl5i - Fix as much of Perl 5 as possible in one pragma" Why not use a language that lets you get stuff done faster, instead of a language that's been feature-patched to death to fix the terrible design flaws it began with?

neild 16y ago

I much prefer Python's argument-passing to Perl's barely-there conventions. Python gives me positional arguments, named arguments, named positional arguments, required arguments, and default values. Perl gives me @_. I can, of course, build almost everything that Python gives me using @_, but I'd rather not have to do it all. For example, I can write: def frobnicate(a, b, snozz=True): pass frobnicate(1, 2) frobnicate(a=1, b=2) frobnicate(1, 2, False) frobnicate(1, 2, snozz=False) frobnicate(1) # Error, need to pass at least two args. frobnicate(1, 2, snooze=False) # Error, no such argument. I'm certain there's a "Modern" Perl module that will help with doing this sort of thing, but it's nice to have it there in the language. Back when I wrote a lot of Perl, I'd always end up with something like this: sub frobnicate { my($a, $b, %args) = @_; $args{snozz} //= 1; } frobnicate(1, 2); frobnicate(1, 2, snozz => 0); Of course, this doesn't include any of the basic error checking I get for free in Python. I like having OO support in the language syntax. Yes, Perl has Moose now, but the blending of packages and classes is still there. In Python, I can declare a new class with just a couple lines of code; even a minimal Moose class declaration takes substantially more. For example: class XPathError(Exception): """Base exception class for all XPath exceptions.""" Two lines of code to get a useful class. That, of course, ties into one of Perl's big weaknesses, which is exception handling. I know that there are modules which try to patch over Perl's very weak exception handling model, but again, Python is just so much better. What's the Perl equivalent of this? try: x = int(s) except ValueError: x = 42 Perl's core still uses strings for exceptions, which is just horribly fragile and painful to deal with. Python has solid, pervasive exception handling with exceptions defined as objects in a sane and simple hierarchy. I like the fact that people understand Python. I was a pretty good Perl coder, back in the day, and I like to think I had a quite deep understanding of the language. The problem was that I kept dealing with code written by people who didn't. To some degree, this is a problem in any language, but Perl contains so many traps and pitfalls for the unwary. Consider context. I understand the difference between scalar context and list context. I understand why the following two lines of code are equivalent: foo(1, 2, 3, 4, 5, 6); foo(1, (2, 3, (4), ((((5))))), 6); I understand when the above lines aren't equivalent. But entirely too many people don't understand this. And, in my opinion, they shouldn't have to. I've never once missed list flattening in Python. Perl is big and complicated and powerful. Some of that complexity is wonderful, but I find that I don't really miss any of it. Python isn't as big, and it isn't as complicated, but it's just as powerful for me. I haven't missed CPAN. It's a wonderful collection of code, but Python's PyPi (formerly the cheeseshop) is also wonderful. We could quibble about what packages are available for each language or the technical details of CPAN vs. PyPi, but let's just say that I'm happy with both. I could go on. Let's just say, however, that I've found there's nothing in Perl that I can't do faster, easier, or more maintainably in Python. Oh, there's the occasional area where I take a couple lines more code to do something in Python. There's also the occasional area where I take a couple lines less. But, overall, things just feel cleaner to me in Python. I used to love Perl unreservedly, but I've been over it for some time now. When I go back, the idiosyncrasies that I once found charming just annoy me. I've moved on. You still like Perl, and that's fine. I hope I've given you some sense, however, of why some of us prefer other languages.