Hacker News new | comments | ask | show | jobs | submit login
What is "Modern Perl"? (perlgeek.de)
45 points by fogus on Aug 16, 2010 | hide | past | web | favorite | 45 comments



I have a friend who has done some really neat stuff with Modern Perl. I think that is the perfect name since it seems to be just using modern methods of development with Perl.

So, here is a serious question for the Perl geeks though:

Is Modern Perl basically TMTOWTDI falling out of favor? It seems like the article is saying "This is probably a better way" (TIPABW?)


I'd say there is and always will be more than one way to do it. Even if a language manages to constrict usage of the syntax to the guidelines, one layer of abstraction higher up it's all choices once again.

There have always been good and bad practices in Perl. Without change and reevaluation, how should there be progress? I regard Modern Perl as the aggregation of the community's knowledge, experience and best practices with regard to designing software. I'd like to emphasize the last part of the former sentence, since I believe Perl's continuing influence and ability to find new talents is at least in part depending on the nature of the community. And especially the fact that it doesn't matter where a good idea come from. If the Python guys come up with something smart, more power to them, because we might be able to use their experience. And at the same time, I think Perl wouldn't have been such a success for a long time if it hadn't been as flexible as it is, catering to people coming from other styles and other environments. Yes, the Perl community might have a common way to do it, and in this day and age even a library that does it all for you, and stuff you wouldn't even have thought of yet, but that doesn't mean you can't come up with something better.

With the ability to extend the grammar in Perl 6, I believe this will go full circle. Since then everybody in the Perl community will be able to experiment with language design, find bugs, write proof-of-concepts, and so on.


Is Modern Perl basically TMTOWTDI falling out of favor?

Instead its morphed into TIMTOWTDIBSCINABTE, which fortunately is lovingly referred to as "Tim Toady Bicarbonate" :)

In full... There's more than one way to do it, but sometimes consistency is not a bad thing either

ref: http://en.wikipedia.org/wiki/Theres_more_than_one_way_to_do_...


corrected link: http://en.wikipedia.org/wiki/There_is_more_than_one_way_to_d...

That is awesome. While I don't write Perl these days, seeing things like this is like meeting up with old college buddies.


Also, I rarely see listed Devel::REPL. Excellent, excellent tool. Run re.pl with perl -d, and you have half the useful REPLness of CL.


I usually leave a terminal window with Devel::REPL up, often with DBIx::Class running (an ORM and yet another Modern Perl module). Excellent for prototyping with a database and great alternative to normal SQL command line interface.


It's ok... It's better than nothing, but sometimes it can be pretty confusing (one can argue that's correct, but it's definitely not what I'd expect).

    $ my @a=(1,2,3)
    $ARRAY1 = [
            1,
            2,
            3
          ];
    $ my $r=[1,2,3]
    $ARRAY1 = [
            1,
            2,
            3
          ];


Thats just standard Data::Dumper output so nothing to worry about:

    $ say $_ for @a;
    1
    2
    3
    
    $ say $_ for @$r;
    1
    2
    3
You can switch on the Data Dumper Concise plugin (Devel::REPL::Plugin::DDC). It will still display @a has a array reference but its nicer to look at:

    $ my @a=(1,2,3)
    [
      1,
      2,
      3
    ]
    
    $ my $r=[1,2,3]
    [
      1,
      2,
      3
    ]

It's ok... It's better than nothing

Come on its a lot better than nothing! Checkout the plugins on CPAN because this really makes it a very powerful tool: http://search.cpan.org/search?query=devel%3A%3Arepl%3A%3Aplu...


I meant the array reference that looks weird even if you're listing an array.

Well... it is a usable REPL, but I'm used to running IPython+pdb as my login shell. `re.pl` cannot be really compared there.


I find re.pl more than just an usable REPL and considering its a lot younger project than IPython then I'd have to say its progressed/progressing extremely well.


No sympathy there, unfortunately. IPython started in 2005 and was very usable shortly after. Actually, it was more usable then, than Devel::REPL is now. Devel::REPL is now 3 years old (released first cpan version, 1.0 in 2007) and I really can't defend it. It's just not on the same level yet. Even Zoidberg is better in some ways, but it didn't provide nice enough access to Perl syntax the last time I tried it.


No need to defend or provide any sympathy because I find Devel::REPL to be a great REPL and it fulfils all my needs. I've used REPL's in Ruby (irb), Io, Rakudo and Clojure and IMHO Devel::REPL is no where near the bottom of this list!

BTW, a couple of points:

* Zoidberg is a shell clone (ala Bash, Korn, csh, zsh) and is more akin to projects/products like psh (http://sourceforge.net/projects/psh). While there are overlaps Zoidberg isn't really a full REPL (like Devel::REPL, PerlConsole or even Perl::Shell).

* Devel::REPL started as a blog post in April 2007 (http://chainsawblues.vox.com/library/post/a-perl-read-excute...). It may have been called version 1.0 but it was just an proof of concept at this time.


This is a good list to progress towards: http://vmathew.in/lisp-repl.html


While I quite like the article, I'm amused to note that 5 out of the 10 "aspects of Modern Perl" are things I screwed up, struggled with, and standardised on - in a project back in the late '90s.

Tests, 3 arg open, strict and warnings were all things that came to prominence (at least in my head) shortly after the Perl4 - Perl5 update. To a lesser extent "best practices" (the same concept but before the book was published) and "care and marketing" were all things being discussed and in clpm back around the same time everybody was worried about y2k issues. Even the OO stuff was well underway, with things like Abigail's "inside-out objects" being experimented with and discussed well before the start of the Moose project...


And this is all good news because it shows that Perl is progressing and continually improving. For eg. from Perl 5.012 you can now do this:

    #!/usr/bin/env perl
    
    use 5.012;
    use warnings;
That use 5.012 now automatically switches on use strict along with all the extra Perl 5.12 features (http://search.cpan.org/~jesse/perl-5.12.1/pod/perl5120delta....).

Perl + CPAN + time = programming darwinism :)


Also see perl5i for a hypermodern version/vision/patch of Perl 5: http://search.cpan.org/dist/perl5i/lib/perl5i.pm


Just one request from this old Perl hack: please make it easier to learn than Ancient Perl. If you need to be an expert on Vanilla Perl to be able to "get" Modern Perl, then it's going to have a hard time getting traction. Like those Java web frameworks that you needed to be a JSP guru to be able to grok.

Oh well, back to my usual Ancient Perl hacking...


Python?


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.


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. Yum!

And, of course, Steve Yegge describes what I'm saying much better at 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. "


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.


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:

"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?


Perhaps you can comment on what he actually said, not who he is?

Certainly: that particular comment is irrelevant nonsense.

There should also be a CPAN module called Python. Fix as much of perl 5 as possible in one new language!

I expect better discussion from Hacker News.


You're right about the Python comment, and I edited it out. However, I would also say that you've provided no discussion of value in your comments. I at least back up my statements with correct supporting arguments, even if I sometimes use overly strong language in making them.


My point is simple: the past ten years of Perl development have changed the language and its ecosystem dramatically. You can still write Perl as you did in 2000 or 1994 or 1987, but the Perl community tends to use terms like "Modern Perl" and "Enlightened Perl" and "Perl Renaissance" to distinguish between code we know to be buggy and clunky and difficult to maintain and the code we write now that we know so much better.

If you want to compare Python to Perl, compare Python 1.x to the ancient Perl that always comes up in these comparisons. (You may or may not deduct points from Python for breaking backward compatibility in the past near-decade.)


Then we don't have anything to argue about. I agree that modern Perl is a lot better than older perl, and that modules that fix perl, like perl5i, Coro, and Moose, enable you to write decent code using the language. I never tried to say otherwise. My point was, why bother, when you can use a language that doesn't need to be fixed in the first place? Life is so much simpler without all the extra accidental complexity.


My point was, why bother, when you can use a language that doesn't need to be fixed in the first place?

Because I'd rather have to add on Moose (something I can fix while remaining compatible with other libraries) than use a language in which variables automagically spring into existence (which I can't fix).

Worse than that, while I'm sure that new Python 2 classes and metaclasses allow someone to write a better object system for Python, no one would ever use it.

Thus my main non-syntactic gripe with Python is that the things I most want fixed either I can't fix and still have Python or no one in the Python community would ever support, because of the peer pressure to hew to one obvious way to do things.


(This probably both offends both Perl people and C++ people. Here goes.)

I think writing clean, readable, modern Perl is like writing clean, readable, modern C++: it's _all_ about what language features you avoid using.

Writing good code is totally possible in both languages, and people have done it successfully. It's unfortunate that both languages are filled with features better left unused, but they're both very useful tools. Perhaps Perl has a little more competition in its area of focus than C++ does.

Many would argue that we should be using neither Perl nor C++, but I haven't seen any serious contenders to replace either.

(For the record, I use both Perl and C++, but only infrequently.)


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.


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.


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.


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

Frankly, we have all seen the arguments -- when Perl is mentioned on e.g. HN there are always lots of Python lovers which love to tell us them...

It is BTW nice to have OO built in -- and it is nice to have a better OO system in Perl's Moose. And so one. And so on. And so on. :-(

IMHO, the main problem with Perl is the complexity/learning time; the good part is that it is fun. I promised myself a few years ago that if I should work more with computers, it would be things that made me happy.

You were at least polite and informed, but after all those language war lovers, if I change it will be to Ruby. :-)

But sure, come back when it is neat in Python to copy/paste code with variant indentations [Edit: -- and write decent one liners, I never use the REPL]... :-)

Edit: And sure, chromatic wrote that -- as answer to yet another Python trolling...

Edit 2: We have seen the arguments. Before Moose, the Perl OO was derided as a killing problem -- now Moose which is arguably better OO than Python -- is dismissed. And so on.


I was responding to a comment in which chromatic specifically asked for reasons to prefer Python over Perl. As such, "we have all seen the arguments" is needlessly dismissive at best.


[Edit: This was days later, the one I comment on might never see it. It is just for my personal peace of mind to answer seriously, despite that the subject is a bit more flaming material than editors.]

In hindsight, it doesn't feel good just to answer by a couple of edits on my GF comment.

First, as I wrote, the way how the arguments change over time is irritating -- now you dismissed not only CPAN but also that the OO afaik is superior to Python.

Perl is messy and complex from its natural language inspiration. The main problem with that is the learning time. (Given that you work with non-newbies that can document and follow coding standards.)

The advantage with being messy is that growth happens in more areas. Moose is arguably a better OO then Python at this time. There are now standard ways of extending the language. Etc. (You could call it "better evolvability".)

Personally, I like the insanity -- that Perl breaks most every design rule for programming languages that ever existed, but still works. Well, that and the smart and laid back people of the community.

That is what keeps me using Perl; it puts a smile on my face and keep me happy. When the day ends, motivation is everything. I can't get out of bed in the mornings just for money...

But... I am not religious. A job offer with a nice Lisp variant would tempt me. I should get a book about Haskell and read. Or maybe Perl 6.

To change between Ruby, Perl and Python do seem totally meaningless, they mostly fill the same niche. Which is why the trolling of competitors seems so intense from the True Believers' preferred environments (and yes, that view of Python has been growing on me over the last few years.)


Perl is messy and complex because problems are messy and complex.


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.


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.


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.


I kinda thought the trolls were mostly on reddit, sad to see their rise on hackernews too.


If you interpret it as a joke, it is amusing.

It's not that I don't like Perl. In fact, I use Perl and have NEVER used Python.


It's missing the amusing part. Here's better trolling:

     The notion that everything is a stream of bytes is utterly braindead.
     The notion that regexps are the solution to all problems is equally
     braindead.

     Just like Perl.

     Some people, when confronted with a problem, think “I know,
     I'll use regular expressions.”  Now they have two problems.

     (by Jamie Zawinski <jwz@netscape.com>)


You see a troll, I see a lack of introspection on your part.


How much reflection do you spend on a single-word comment?

Python is not Perl, how can it be Modern Perl?

I know that some people think that Ruby and Python continued the tradition of scripting languages that Perl brought to mainstream, and that they are both modern in some sense, but that doesn't make them Modern Perl in any way.

Would you care to expend the thoughts that you think my introspection should have produced, that let the reply not be troll?


What length of comment is required for you to begin introspection? This does a good enough job: http://martin.drashkov.com/2009/11/why-perl-lost-it.html. I personally look to lack of advancement of the language and lack of adoption for new ventures. Google adopted Python for GAE, for example. Heroku used Ruby for their PaaS product. When you look at new devops tools they aren't written in Perl. So, it's not a matter of what is better, it's more a matter of other scripting languages are now in the slot/brand/niche/mindshare where Perl once would have been. So in that sense they are the modern perl.


When you look at new devops tools they aren't written in Perl.

That statement seems to assume a zero-sum game and begs for non-anecdotal evidence. (Paul Graham wrote Hacker News in Arc instead of Ruby on Rails or Django; clearly they're losing ground too!)




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: