Perl and self flagellation...

What's wrong with Perl 5. Nothing. What's wrong with non-"Modern Perl"? Nothing.

I get the impression from the Perl community sometimes that if you aren't using Moose you're not a real Perl programmer. The notion of Modern Perl to me is a bit amusing.

While I am in agreement with all of the attempts to create best practices and standardization around Perl programming and protect programmers from themselves SOMETIMES, it's a bit of an oxymoron to use standardization (of programming techniques anyway) with Perl. After all, the language that embraces the TIMTOWTDI mantra can hardly throw devotees out of the tent that don't want anything to do with heavyweight additions to their favorite language.

More power to all the Moose developers and it's great that you can create a framework (in Perl) that morphs Perl into...something unrecognizable at times that folks find useful, but here's my point.

Are C programmers lamenting the fact that their language has been left behind on the dust bin of history? Nope. Last I heard, C still has an important role and plenty of highly competent people using it to solve problems. Not EVERY problem, but lot's of problems.

Seems to me that Perl 5 should be embraced in a similar way. It solves a lot of problems. Maybe not every problem. Perhaps a huge project that requires that all developers be put in straight jackets and live within a constrained, highly protective environment is just not a good fit for Perl and one should look at languages that are designed for that use case rather than morphing Perl into Java or the next OO...fill in the blank with a pithy name...language.

My first car was a 1969 Red VW Beetle. The heater was busted and perpetually on. The heat came out of a vent in the floor and burned my feet. I had to stuff a big tube sock in the vent. I put in a quart of oil at every fill up too. One day I saw a VW on the road and saw that someone had smacked a Rolls Royce grill on the front. Wow! Cool! Then it hit me. Why not just buy a Rolls Royce?

As a manager of Perl developers in a relatively small Perl shop (~12 developers) I loathe the guy that sneaks Object::InsideOut into a project to write a 400 line Perl script that essentially updates a database. I have no patience for programmers that want to show the world how smart they are while creating code that only they can maintain. It would be great if God created all programmers with the aptitude of the folks on these blogs, but as a hiring manager, I can tell you there are more folks that struggle with POP5 (plain old Perl 5) than there are Moose/Mouse/Moo-men (sorry persons).

Before I'm burned at the stake by Moose-folk defending their territory, let me reiterate I applaud the effort to see how far you can stretch Perl. While I don't find that morphing Perl into Modern Perl makes sense (to me) and would never pay the penalty associated that always follows when you try to bang a square peg into a round hole, I don't have to. I can still use POP5 and feel good about it.

So, rather than continuing to walk in circles in a self-flagellating ritual reminiscent of Monty Python and the Holy Grail, why not just take Stuart Smalley's approach and let's all just do a daily affirmation.

"I'm a Perl 5 programmer and I'm good enough, I'm smart enough, and gosh darn it people like me!"

stuartSmalley.jpg

Perl 5 has a place solving problems, just as C does. If I want a Rolls Royce, I'll buy a Rolls Royce.

38 Comments

I have no patience for programmers that want to show the world how smart they are while creating code that only they can maintain.

I agree with that sentiment wholeheartedly. I would hope that we all do.

But I don't see what that has to do with your main argument. As I see it, the large "Modern Perl" tools that you are complaining about pretty much all exist to make code easier to understand and maintain than older Perl code.

OO code written in Moose is easier to understand than the equivalent code in standard Perl OO.

Database code written with DBIx::Class is easier to understand that the equivalent code written using DBI and raw SQL.

Web applications written in Catalyst, Dancer or Mojolicious are easier to maintain that the equivalent code written as a series of CGI programs (and, because they are written on top of PSGI, they will be easier to deploy than those CGI programs).

By all means don't use those tools if you don't feel that they are right for you. But please don't think that they are written to confuse you or to make your life harder. They are there to make your life easier. There may be a bit of a learning curve to get over at first. But pretty much everyone I know who has made the effort to conquer that learning curve has benefited massively almost immediately.

POP5 and 'modern Perl' are both ok.

Just keep in mind the principles of good development:

- do not (use) more than you need
- KISS (keep it simple and stupid)

Personally I am a friend of DBIx::Class and Mojo.

But why should I use File::Find et al. if a simple grep { ... } readdir() does the job?

Or why should I setup a DBIx::Class::Resultset if I only need a simple SELECT?

All this modern tools are nice if they keep the complexity away from the own code.

But if your problems are simple, don't use such tools, if they bloat your code.

And don't forget negative surprises with CPAN-dependecy-bloat.

> Moo
> Object::InsideOut

You seem to be massively conflating concepts here. You seem to think that Object::InsideOut is the same thing as Moo, and because you've had a bad experience with one, you project that on the other.

Instead of dumping your lack of experience on other people in this way, i strongly suggest you come on IRC and actually ask questions. :)

"But why should I use File::Find et al. if a simple grep { ... } readdir() does the job?"

Because if your code is full of this stuff, it really isn't funny for others (or your older self, as Damian Conway uses to say) to understand this thing. (You should then actually place a comment above each such command, saying what you are doing.)

Sorry, maybe I should better explain what simple means.

Of course I use File::Find et al. in most cases.

But if the problem is simple and needs not more than e.g.


opendir(my $dh, $images_dir) || die "can't opendir $images_dir: $!";
@manu_dirs = grep { /^[^.]/ && -d "$images_dir/$_" } readdir($dh);
closedir $dh;

the solution with File::Find will need more lines, add complexity and will need wiil need a reader of the code to read into the 20 times larger documentation of File::Find.

Or show me a shorter and simpler solution using File::Find.

You should have used File::Spec->no_upwards and File::Spec->catfile(...) here instead of the /^[^.]/ regular expression which will miss other directories that start with a period as well as the "/" which is not portable. Also look at File-Slurp and IO-All.

I would like to start by saying, I'm not being critical of the opinions in this post or the comment. I would like to try to add some perspective though, targeted, if nowhere else, at future readers.

My biggest complaint with POPO (plain-old Perl objects, i.e. sub { bless {}, shift }) is the repetition. Even in the most simple of classes, I need to write the same accessors, constructors, etc that I have always written. This is fine, and even preferable for some cases.

The reason the object systems came about is that many people got tired of writing the same code over and over. Your problem (only as I see it of course) is that it has taken a long time to get a nice balance between performance and usablility. InsideOut and Moose both help you write classes, but they have overhead in performance, dependencies and even readability if you don't understand them. However the wheel is always turning. Those projects have lead inexorably to the next one, improving along the way.

Moo is my current system of choice (except where Mojo::Base will work). Both are tiny, small enough to easily bundle (or even fat-pack) where needed (saving dependencies) and performance is improving too. Readability only comes with practice of course, but once it does, since you are not repeating yourself, IM(very)HO, you can be more productive.

Of course there is a balance, and no I hope POPO never really goes away. However I hope you give Moo (and yes the thing that eventually tops it) a chance too.

Happy Perling!

Database code written with DBIx::Class is easier to understand that the equivalent code written using DBI and raw SQL.
When I have had to deal with complex queries DBIX::Class is harder for me, I prefer using raw SQL and DBIX::Simple

In a small project, plain Perl classes are probably quite readable, but if you've got dozens of classes, Moose-like "has" statements are much more skimmable. (Of course, there's a slight learning curve while you get used to reading them.)

And because Moo/Moose abstracts away the exact workings of the class constructors and accessors, it's free to do some insane stuff internally to make them really, really fast. Stuff that you'd avoid like the plague if you had to maintain it yourself.

opendir(my $dh, $images_dir) || die "can't opendir $images_dir: $!";
@manu_dirs = grep { /^[^.]/ && -d "$images_dir/$_" } readdir($dh);
closedir $dh;

First of all, you shouldn’t use File::Find for that – you are not recursing, so File::Find is the wrong tool for the job (even though it can be coerced into doing it badly). Secondly,

use Path::Tiny;
@manu_dirs =
    map { $_->basename }
    grep { $_->is_dir }
    path($images_dir)->children;

I know which code I’d rather be looking at…

(Note I assumed that you meant to filter out only . and .. (which Path::Tiny does automatically) – if you did mean to filter all dot dirs, that would take one more line.)

Thirdly, for tasks for which File::Find would be a right tool, Path::Iterator::Rule is a better one.

Need to dig a small hole? Use a shovel (perl objects).

Need to dig a ditch? Use a backhoe (Moose).

> I don't necessarily see how the framework makes reading the code any easier

I sincerely hope you're the kind of person who, when they say this, actually have an interest in learning so they can see it; as opposed to the person who just says it so they can feel self-justified.

If you're the former, please read this: http://rjbs.manxome.org/talks/moose/

Especially page 32 is interesting. Also keep in mind that with Moo you get pretty much everything in that document without the startup penalty, all in pure perl.

And let's see how that would look with the latest perl5i (on GitHub):


use perl5i::2;
my @manu_dirs = ["some/dir/path"->path->children]->grep( sub { -d $_ } );

I will submit this hypothesis: The average Perl programmer that has learned Perl from Learning Perl or the camel book will not find reading Moose code "easier".

Well, someone who has learned Perl from Learning Perl won't have come across OO Perl yet, so both styles are likely to be a little confusing :-)

Here's a concrete example of why I think you're wrong here.

In "classic" Perl OO, a class has an attribute simply because the programmer has written methods that handle that attribute. A class has an attribute "foo" only because there's a "get_foo" and a "set_foo" method (or something similar. This means that most class definitions start with pages and pages of simple "get_foo" and "set_foo" methods. All of which are almost identical. And all of which are probably cut and pasted from other, similar. methods. When you have dozens of methods all of which look the same, if becomes easy to miss the little differences that should exist between them (the name of the hash key that stores the attribute, for example) and introduce hard to find bugs into your code.

With Moose you don't need to write all of that code. Your attribute exist because you have defined a list of attributes in your class. That list is easier to read, understand and maintain than the same functionality would be if it was spread out over dozens of similar-looking methods.

To me, that's the biggest win in using Moose. All of the other great power and flexibility is useful, of course, but that's why I use it.

There are several things here that I don't get.

I get the impression from the Perl community sometimes that if you aren't using Moose you're not a real Perl programmer. The notion of Modern Perl to me is a bit amusing.

I read a lot of Perl blogs, I spent way too much time on Stackoverflow, and I keep an eye on several Perl-related IRC channels, but I have no idea where you get that impression from.

Perhaps I'm wrong, but again my experience is that programming talent follows the same bell curve that most other skill positions do.

That is absolutely correct. Being under the wrong side of that curve myself, I know exactly what you are talking about. But in my experience Moose/Moo help guys like me a lot. They let you write simple and complex classes with a lot less code than in takes to write them in the "traditional" way. Less code means less bugs, means less attention needed to read the code, means quicker coding. If you are not intelligent enough to come up with a class in Moo, you shouldn't even try to write your own constructor that takes a list of parameters to come up with an object. Never mind that subtle traps lurking in writing your own accessor methods.

When people say "Moose" they mean the syntax. Personally i never actually use Moose.pm and port from Moose.pm to Moo whenever i can.

Now, to take your little car analogy there:

Moose is a combat jet
Moo is a VW Beetle
Class::MethodMaker is a kick scooter

Nobody is saying you need to drop everything for Moose, but if you want to get stuff done there's no point in restricting yourself and not opting for something that provides Moose syntax. Moo will give you that and is by no possible measure "heavy weight".

Also, lastly, there is one thing that absolutely disgusts me about the way you approach things: Your reaction to being confused about something is to make wildly inaccurate and wide-reaching statements borne out of the same ignorance that led to your confusion; as opposed to the rational and productive reaction of going and ASKING people.

PS: Did you read the pdf i linked earlier? (Y/n)

This is an old discussion around Perl. Look for posts about using MAP. The arguments then are the same as now with "Modern Perl." I can see the OP's point. Most of my applications read from a database, write to a database, push data out to a web page or an Excel file. For these tasks, basic Perl 5 is great. All of my projects use Apache as their web server and MySQL as the database. When I need to find "Help" in any of the cities where my client's trade show happen, I can find people with these basic skills. I care more about the following when hiring a Perl (or any) programmer:

  • Does the program do what I asked the programmer to do?
  • Can the programmer figure out the requirements and if not, will they ask me for more information? Not all do...
  • Does the program preform its task without a lot of overhead. Does it run efficiently? I started programming when you were billed for machine cycles and Fortran was Fortran 66.
  • Was the program completed on time and in budget. I also find newer programmers have a hard time understanding these concepts.
  • Is the programmers coding style one I, or others can follow?

I use to manage a production department for a NYC printer. We had 60 people who worked around the clock. For one position I interviewed several hundred people. They were given a test of four ads we had produced. I did not care how long it took the person to take the test. I cared about how easy it was to work on their files once they had completed them. When managing a group of people in complex tasks it becomes about working to a common level. If the level of Perl programmers in general is at a 3 to 4 on a scale of 10, then the code needs to be written at that level. The simple reason is that any one of the programmers may be called on to fix a bug at any time. Having code that only the top level people can understand does the company and the client a disservice.

That said, it is the job of the manager to provide a skills path to their employees, so that the bottom level people can grow into top level people. This is not a popular opinion in modern business. Most companies do not want to train their people, they want them coming in as an expert. Not all employees will grow or want to, but those that are smart enough to take advantage of the opportunity given them will make for a better team in the long run.

You have hit on the exact same point I tried to make just a short week ago, and it appears you have been deluged with the same Moose loving bandwagon I was also introduced (again) to. Despite the bandwagon I plan to continue posting about solving ready world problems using non-modern Perl.

Is it your standard policy to be rude when commenting? Suggesting that the way someone else approaches something disgusts you is rude in case you were not aware. Could you not simply say you disagree and state your reason why?

TMTOWTDI! Nuff said :)

The cool thing about TMTOWTDI is that not only is there more than one way to do something, but none of ways are right or wrong. Instead, they are just different ways.

Same thing here. Plain Perl 5 OO vs. Moose vs. Moo. There is no vs. They're just different solutions to the same problem with different pros and cons that different people will pick for different reasons with some people even picking the same or different things for the exact same reasons.

Different people, different experience, different ideas choose different solutions. I don't know why people always get bent out of shape over pointless programming arguments that are just giant cans of worms similar to Vim vs. Emacs (Notice I put Vim first :) ).

That's it !

My standard policy is to treat people with a base level of respect and adjust it by how they behave themselves. You can see an example of how i deal with people who actually make an effort to learn here:

https://gist.github.com/wchristian/acb06503e968e78d3e35

If people exhibit obvious signs of actively wanting to avoid learning anything, then my level of respect drops and i speak more plainly and directly to them.

I have no problem at all with people using "non-Modern" Perl. If that's how you want to write your code, then that's fine, of course.

What I object to is people saying that using Modern Perl tools somehow makes their code harder to understand, when the whole thrust of the Modern Perl movement[1] is the complete opposite.

[1] Insofar as an unconnected group of projects can be called a "movement".

I agree 100% with rlauer and Dave Shultz. The problems "modern" perl solves are interesting problems, but they are academic problems. They are not the problems I have seen actually be relevant in any of my own business scopes which I have been involved in during my short 16 years of Perl experience.

As I see it, the large "Modern Perl" tools that you are complaining about pretty much all exist to make code easier to understand and maintain than older Perl code.
I think you are correct in assessing why they exist. However just because they set out with the goal of making things easier doesn't mean the goal was achieved or that the results are applicable for anybody beyond the community that created the tools. Please create new tools. But don't berate others for not using your tools.
OO code written in Moose is easier to understand than the equivalent code in standard Perl OO.
No it isn't. Code requiring features that Moose has is more concise written in Moose. That is true of any framework.
Database code written with DBIx::Class is easier to understand that the equivalent code written using DBI and raw SQL.
No it isn't. Simple relational table models covered by DBIX::Class are potentially easier. Poorly written db code is terrible in either DBIX::Class or straight DBI.
Web applications written in Catalyst, Dancer or Mojolicious are easier to maintain that the equivalent code written as a series of CGI programs
No they aren't. Well written applications are easy to maintain. Poorly written applications aren't. Using Catalyst, Dancer or Mojo doesn't make your app well written. Using plain old CGI doesn't make your program poorly written.
(and, because they are written on top of PSGI, they will be easier to deploy than those CGI programs).
No they aren't. Deploying to the platforms required by the frameworks *might* be easier. Deploying those frameworks in all of the places supported by CGI likely is harder.
By all means don't use those tools if you don't feel that they are right for you.
I don't. Again, most modern perl is academic. It appears to attempt to solve problems that are perceived warts in perl. The modules do a fine job of fixing those perceived warts. I, and many other people do our day-in-and-out jobs and don't encounter the warts or have long since found ways around those warts, or have agreed that some warts are acceptable. The speed of Perl5's interpreter is one very real wart that I have come to accept as workable (though I long for something better).

I am glad that people write blogs about perl. People blog about modules they write or use. It has every appearance that people writing "modern" perl are prolific blog writers so modern perl gets all of the press. But for every blog about a new cool module there are 100's to 1000's of people doing their job efficiently right now, and possibly in a more efficient way than offered by modern perl.

That is very sad indeed, you seem to have had a different view back in 2011 when responding to a post by chromatic about civility (or a lack there of) in the Perl community. I encourage you to come back to the fold of treating people with respect regardless of their level of "desire to learn", it seems to me deciding how to treat someone else based on the desire to learn might say more about you then then other person.

Very well spoken, thank you for your input.

Modern Perl may be academic, but that's exactly what makes it interesting: "academic" solutions bring an altogether other perspective on solving problems. It is an expression of TMTOWDI, something that ought to be welcomed rather than scorned. I'd rather see the language and its thinking process grow fruitful in novel academic solutions than stagnate in congruent practicality.

> Database code written with DBIx::Class is easier to understand that the equivalent code written using DBI and raw SQL.
It's true only for some cases. ORM has advantages and disadvantages, for complex applications plain SQL is
easier (and just cannot be combined with ORM)


> Web applications written in Catalyst, Dancer or Mojolicious are easier to maintain that the equivalent code written as a series of CGI programs

It's not true when you're writing something complex, non standard. Actually when you writing something else than "classic" website.

I have a feeling that this thread is completely missing the point. This is not about Moo/Moose/Mouse code being easy to maintain, not about Plack apps being easier to deploy. This is about the stuff I'd be discussing with my grandfather would he still be alive: "But I don't need this internet thing.", "Writing letters is so much easier".

People too lazy to learn new things, people afraid of change, will come up with all sorts of excuses and explanations. I think this thread gives perfect examples. Saying "I don't need Moose in my day-to-day work" is one thing, but a claim like "Modern Perl is mostly academic" is so in-your-face ridiculous that everyone should know that we have reach a point where a further discussion of the topic is hopeless.

If somebody wants to sound like grampa Simpson, it's his choice. But he shouldn't be surprised to be treated like grampa then.

> As for "being too lazy learn new things", I would say drawing that conclusion based on the discussion is a non-sequitir.

Considering that you entirely refused to even acknowledge the PDF linked earlier, that is a very valid conclusion to draw.

> While I don't necessarily think Moose is "academic" I do think it is an attempt to create somewhat of a new language out of Perl.

Like some kind of Perl6...

Leave a comment

About rlauer

user-pic I blog about Perl.