The two Perl articles were interesting because for three years I have worked with the language and up until earlier this year, I loathed it. This was mostly because of its awful support for Object Oriented Programming, but the fact that anyone I've worked with that called themselves a Perl programmer turned out to be a total amateur hack played a part too. After seeing no less than four guys come and go from our team this year after being 'found out' on their first big project, this quote from use.perl.org particularly resonated with me:

We had no trouble finding Perl programmers. They were a dime a dozen. People write a couple of admin scripts in Perl and they put Perl on their CV. Now don't get me wrong, I have Java on my CV, but I would never dream of sitting down for a Java interview without their knowing up front that my knowledge is pre 1.5 and I don't know any of the modern tools. It's only there because I want employers to know that I have some exposure to it, not that I think I know it.

Now, maybe I'm just being naive, but somehow people with Perl on their CV think they can do this job, but they can't. Not even close.

My disdain for Perl and the quality of code that was being written was so great that I wrote a proposal for us to move our entire code base over to PHP. The scary thing is that the technical management accepted it, and I even got as far as completing an alpha PHP port of our (basic) in house framework before the whole project was abruptly cancelled by upper management for reasons unknown. When the suits put the kybosh on my PHP framework, I decided to go covert and just start doing things right without them knowing. What I've never really discussed is what, exactly, this involved.

Object Oriented Perl

The initial reaction was obviously to start looking for alternative work, but quitting a difficult situation isn't really in my make up. Plus, it's amazing what coming out of University and spending the next two years writing procedural Perl can do for your job prospects! So, with renewed determination, I sat down and asked myself - what is it that I can do with PHP that I can't do with Perl? The whole thing boiled down to the syntax of Classes - PHP and Java both had natural constructs for building your classes whereas in Perl it seemed like a nasty hack. Still, it was clear that moving from Perl wasn't an option and I wasn't going to let minute details stop me from writing good code any longer.

The first thing I did was take Damien Conway's book on Object Oriented Perl and read it from cover to cover. What occurred to me whilst I was reading the introductory chapter on the basic concepts of Perl, was that this was the first time I had read anything at all about the language - every piece of code I had written in Perl previously was done using our in house framework which I had "learnt by doing." My experiences had always been at a very high level using a haphazard collection of Perl modules to do the very common tasks of web development - DB access, request details and parsing templates. Rather than truly understanding the underlying concepts of hashes, arrays, references, map, grep and regular expressions I just kinda lumped stuff together and hoped it work. Then I had the nerve to say the language was useless based on nothing more than the quality of the code I was writing.

A few chapters into the book, which was actually a little out of date, I began to realise that Perl doesn't just offer everything that PHP does but, in the right hands, it's actually a really nice language. I wrote a few classes in Perl and decided that writing a new subroutine just to create a class wasn't worse or better than writing a Class and constructor in Java or PHP - it was just different. Within a few weeks of utilising my new found knowledge of Perl, I wasn't just writing code as clean as what I could write in PHP, but it was actually much more elegant. This was thanks to the way Perl handles named arguments to method calls and constructors - optional parameters were easy and my interfaces became self-documenting as a result.

When I finished my first major OOP Perl project, it was something of a humbling experience - after two and a bit years of arrogantly proclaiming Perl to be a nothing language compared to PHP, the first real satisfaction I had felt after a job done came courtesy of language I spent so long trashing. This realisation that I really didn't know as much as I thought about programming led me to searching for "PHP sucks" and seeing that people had clued into that sentiment a lot sooner than I had; and with much better arguments than "the syntax for anonymous arrays sucks." After all my claims that PHP was the way forward, yeah, it was a pretty humbling experience.

Enter the Moose

Whenever I see a 'Perl guy' defend his language, the first thing they'll say is the CPAN. I had always known of it but had shied away from it for so long because, again, it didn't follow the same rules as my comfortable PHP shared hosting comfort zone. With me getting all philosophical over how wrong I was about Perl, I gave CPAN another shot and soon had modules like Template (aka Template Toolkit) and Test::Class up and running on our servers. I also started to look through the standard modules and was introduced to Devel::DProf too - all of a sudden I had this language with an easy to use profiling and unit test ecosystem and an extremely powerful templating system. For the first time I felt like I was working in an environment that was the equal of the ones I read all those enthusiastic PHP, Python and Ruby developers blog about. And it had been there the whole time that I was complaining that Perl was out dated.

The only remaining gripe I had with Perl was the Class definition syntax. I had gotten past the point where I blindly held the Java and PHP model for Classes as the Right Way, but every time I had to write my own "new" I couldn't help but feel like there was a better way. But never in a million years did I imagine something like Moose existed.

Moose isn't just an equaliser to the native OOP systems of the other big dynamic languages - it's the killer feature. People say that Catalyst is the Ruby on Rails or Django of Perl, but I disagree - Moose is the module bundle that makes Perl relevant again. There are plenty of modules on CPAN that try to make writing classes comparable to the way it's done in other languages, but the guys behind Moose had bigger ambitions and created something that provides features that no other language matches out of the box. If you had to install something like Moose just to get what other languages offer natively, then why not just use those other languages? That's why it's so important that Moose offers so much more.

Getting into specifics is for future articles, so for now I'll leave you with a link to the Cookbook and a sample of my Django-inspired CRUD model system for my new framework (courtesy of Moose sugar):

This code provides all the basic CRUD functionality with validation for each model defined. Of course this could have been done with the native has/isa functionality provided by Moose, but I liked this interface better and so did the guys who are going to be using this - the point is that Moose gave me the power to do this and so much more.

Life after PHP

I've read a few times that you learn more from a defeat than you do from a victory, and that certainly has been true in my case. I often think back and wonder what would have happened if the original attempts to "go PHP" had worked out. That project being cancelled has had such a dramatic effect on my approach, understanding and dedication to my profession. This blog, my recent promotion, learning Python and django, getting a VPS and learning more about the server stack - all stuff I wouldn't have dreamt of doing when knocking something up in PHP in a couple of days would have got the job done. I feel like I've learnt more in the last year than I have in the six that came before it.

Could my post-PHP epiphany have come in Ruby or Python? Having played with Ruby and used Python (django) to rebuild my band website I can safely say that it could, but the point of this post is that it didn't come in those languages - it came in Perl. And after all the negativity lately I felt like it would be a good idea to share the positive experience I've had using Perl 5 and the great progress we're making at work to modernise our development practices without changing languages.

Perl going forward

What I've taken from all of this is that a language is only ever going to be what you make of it. Moving past my own anecdote: with projects like Moose, Catalyst and Mojolicious out there, there is no doubt that Perl is a powerful language that lets good developers write good code. So why is Perl dying? I agree with the general sentiment of both articles - Perl is losing ground to Python, PHP and Ruby and it IS getting harder and harder to find good Perl guys. What concerns me is the recommended actions for fighting the rut.

The consensus in the Perl community seems to be that the areas of marketing, web design and their community organisation are where they are struggling, but these are all superficial next to the damage done by all the absolutely atrocious Perl code out there. I mean, surely the fact that PHP developers can sneer at the ugliness of most Perl code is a major warning sign?

Rather than tart up use.perl.org with some gradients, what really needs to be done is for more examples of elegant, maintainable and tested code like the kind found on the Mojo project to be put out there for people to read and aspire to. Rails is a popular framework but that has very little to do with Ruby or the nice user interfaces on 37signals websites. Design is extremely important, but it starts at the code level. Get that right, then worry about the CSS.

Posted by David McLaughlin on Sunday, December 7th

29 Responses

1

mark

Sunday, December 7th

I am not sure about the general conclusion. I can agree that perl still has a huge user-base. However do people really opt to pick it up?

That PHP has become a success is a big shame for ruby python and perl alike. But it draws people to use it as a language, and these are less likely to pick i.e. perl once they have used a lot of PHP (PHP really is the worst IMHO of all these four languages)

One big advantage Ruby has is that you can find your own coding style. You can omit features, you can choose to use .method() or .method just as equally. Python on the other hand advocates the "there is one way for things, and there ought to be a BEST way for things". I think both philosophies have a big advantage over perl's philosophy, and the biggest difference really - as superficial as it may seem - is that they syntax of perl is less appealing than the one of ruby and python. Syntax is not everything - php was a success ... - but I really wonder if perl 5 will be enough to draw a huge _NEW_ follower base.

I have my doubts, but the future will show.

(Programming languages never really "die", but at one point of history they start to become less working, i.e. if no new users arrive and you know that a language is old if all its users are 50+).

2

It's interesting that you mention Ruby allows you to find your own coding style, that's one of the biggest problems with Perl! It is such a flexible language that building maintainable systems is difficult as everyone solves a problem in a different way.

For example, Perl also lets you choose between method and method() and even goes further and lets you choose between:

my $template = Template->new();$html = $template->output;

and

my $template = new Template;$html = output $template;

There is so much more flexibility that it starts to get ridiculous when you can't even get programmers deciding on the best way to define classes. "There is More Than One Way To Do It" has been the bane of my existance when trying to introduce a standard framework over the last year.

It's only because we stopped hiring Perl guys and started hiring guys based on their attitude that we've started moving forward. Right now I work with guys who previously worked in .NET, Rails, PHP and Java shops. They have all had to learn Perl on the job, and thanks to the lessons I've learnt, I've really pushed the idea that it's possible to write good code and we're all pretty enthusiastic about this new framework.

I share your doubts that Perl will struggle to attract new followers - especially Perl 5. That's why I think it's important that the Perl community starts to show off just what exactly can be done with the language.

3

Ross

Sunday, December 7th

David, you are a wonderfully articulate and cogent writer with an evocative sense of style. I very much enjoyed this article despite having no formal experience programming in PERL.

Typically I leave comments once in a blue moon but couldn't remain taciturn in this instance. I shall be adding your blog to my regular read list :)

5

Carlin.

6

It's fun to read your post (found it in Hacker News) because i was looking for a language to learn and did not want to look back to ruby or python. All my experience so far is in PHP so your article really got me impressed and curious about Perl.

Thanks!

7

Andrew

Sunday, December 7th

I think the writing is on the wall for perl, and in my opinion rightly so - we just have better founded languages and tools.

9

Thanks for the fantastic article. This is perhaps one of the better write-ups I've seen about what the Perl echo chamber has known for quite some time.

As you mentioned, marketing and community organization are very difficult challenges facing us, but there are efforts underway.

One large effort is the recently founded "Enlightened Perl Organization", which aims to promote precisely the tools available that allow people to be impressed with the power of Perl.

The first endorsed package list is available on CPAN under Task::Kensho, which provides a recommended set of utilities to Get Stuff Done. Trying to break away from the spirit of "There is more than one way" we're being more opinionated.

Perl is a fantastic language, and with Moose (and beneath the covers Class::MOP) you're able to accomplish things that were previously only available in CLOS-based languages (which have their own drawbacks).

In related news, Catalyst 5.8 will be fully Moose-based and we will be promoting recipes for using Moose to get the best results.

DBIx::Class is also moving towards Moose (and already plays very nicely with Moose).

Catalyst is also branching out to have optimized support for Apache, lighttpd and nginx - using the same FastCGI support that you would expect to use, or the latest work with the HTTP::Prefork server which operates very similarly to Mongrel from the Rails world.

Perl 5 is far from dead, the only writing on the wall that I see is "use Moose" and that is sound advise.

I applaud your efforts in taking the time to really learn about how Perl operates, because while something may look lacking (like the Perl OO capabilities) there is usually a good reason for it; in this case it is allowing things like Class::MOP and Moose to be built.

Again, thank you very much.

-Jay

10

anon monkey

Sunday, December 7th

Take a look at NYTProf for profiling. Much better than Devel::DProf!

11

Try writing an RPC framework for your favorite scripting language. You'll start to realize how beautifully simple the Perl OO mechanism is: calling a method is just like calling a free-standing function in some package, except that the $foo->bar dispatch operator uses ref($foo) to determine the target package, and then $foo becomes the first argument to the function call. That's all there is to it.

Contrast this with Python, where function and method call dispatch are distinctly different beasts. In a Python RPC module, all of a sudden you're traversing a hierarchy of semantic objects to distinguish methods bound to an object instance from unbound methods, from free-standing functions at module scope, from class constructors which look like Foo(), etc. It's a real mess. And for some reason, people think of languages with all these superfluous language constructs as "simpler."

What's amazing is that Perl *evolved sanely* from its humble origins as a sed / C / awk / sh mixture into something which accommodates OO programming via a simple dispatch operator. Or exceptions via the die builtin. The list goes on and on.

Sure, Perl's legacy has held it back in all kinds of ways, but what mature language wouldn't be in the same boat? Contrast this with the sheer carnage that is PHP's "evolution" over the years.

12

Chris Prather

Sunday, December 7th

You said:

"The consensus in the Perl community seems to be that the areas of marketing, web design and their community organisation are where they are struggling, but these are all superficial next to the damage done by all the absolutely atrocious Perl code out there."

and then:

"what really needs to be done is for more examples of elegant, maintainable and tested code like the kind found on the Mojo project to be put out there for people to read and aspire to."

You do realize that the second item is exactly what marketing is right? Showing people that *good* Perl can and does exist, and that Perl doesn't have to be the language of the past. While I may have my doubts and disagreements with Mojo in particular (I think it needs to prove itself ready-for-enterprise since it chose to re-write wheels rather than use CPAN), I agree with the tenor of your argument.

This is why I think things like the Enlightened Perl Organisation are important. They're trying to help present Perl as a modern forward facing language with an Enterprise set of tools (Moose, Catalyst, DBIx::Class) that have been vetted in real-world companies (Y!, Amazon, the BBC).

13

Now that I read it back, that comment is ambiguous. What I meant is that we need to write more code in Perl in a clean and elegant style and put it out there. You can't market what you don't have!

I pointed out Mojo because it was my favourite example of good code design. Does that mean I would code something in Mojo or Mojolicious right now? No, it's still got a long way to go in terms of documentation and features to warrant that but to me, paying this much attention to interface design is setting a new standard:

14

Peter J. Schoenster

Sunday, December 7th

I am surprised you did not mention mod_perl. I, fortunately and not, got a job years ago doing PHP but around that time I had begun writing apps using mod_perl which provides benefits over plain cgi. http://perl.apache.org/ I still use Perl for eliminating general tedium and sysadmin tasks as I'm a default sysadmin in addtion to web guy. I must say I also like python and am using the django framework on some personal sites.

15

To enter the next level though, I recommend "Higher Order Perl" by MJ Dominus. It's the book I've read in the last 10 years that changed my coding practices most. Every single page a must-read, I think.

16

Hiya. Great article. As the guy who wrote a strong typing implementation for Perl, I can tell you not only are Perl programmers generally rotten at and opposed to sort of any real object oriented design analysis, but there isn't really much market for Perl programmers with strong OO background either. A lot of companies claim to want this, but they waffle at the brink. (If you're not familiar with strong typing, it's a compile-time check that verifies that you (probably) declare your types, and use them consistently, never calling methods that don't exist in objects or passing parameters of incorrect object types.)

This accomplishment, and my experience with Java (from back when Java was for applets, before it got all serious and stuff) is generally a mark against me -- an indication that I'm a threat, or an outsider. I'm not complaining about this, at least not so far as it affects me. I'm quite happy to be the black sheep. But I want more for Perl and Perl programmers.

If groups of Perl programmers were really to embrace OO, they'd drop their hostility towards programmers with both Java and Perl experience, and towards older guys who have OODA (object oriented design/analysis) experience. Like Ruby and PHP, departments using Perl tend to be very self-isolating -- young guys who love Perl who don't want old guys or other camps around. (I'm not an old guy -- yet -- but my unique situation has given me an appreciation for them and the knowledge they offer.)

The main reason companies use Perl is because Perl programmers are cheap. And that's the real reason PHP is taking over -- PHP programmers usurped the reputation for kicking out projects with minimal fuss and formality. Perl guys are getting to be the older guys now, who either learned the lessons the hard way, or else are themselves really are obsolete, little more than older, uneducated kids. Unless Perl can embrace to beat PHP for kicking out code cheaply and pretending that programmer is simpler than it is, they need to aspire to be better programmers. And that means learning from the functional guys, the old guys, the Java guys, and so on. Even taking them onto the team. The time for "we're better than them and we don't want them around" is passed.

That's kind of my compendium to your suggestions for Perl programmers. I agree with what you have to say but wanted to add more. That lecturing isn't directed at you per se ;) But to you I'd like to suggest that you check out Higher Order Perl -- or even better, if you can stomach it, Structure and Interpretation of Computer Programmers. Do that and you'll look back and think, wow, I was barely capable of solving simple problems before, and now I'm now capable of solving extremely difficult programming problems. Another book I highly recommend is Object Oriented Design Heuristics. Unlike the trendy set of OO books, this one treats a hard subject like a hard subject, full of intricacies and corner cases, rather than giving you a select smattering of simplifications that sometimes work in some cases and ignoring the cases where there is no cheat. That'll give you an appreciation for the old timers who led design for large, complicated projects in C++.

Cheers!

-scott

17

z

Monday, December 8th

David, I'm glad you have gained from this experience, and particulary glad that you're left the ranks of Perl detractors. However, the story is still frustrating in a typical way.

There's a question I was looking for that was never asked, and that's why you didn't learn Perl earlier. I mean, a trait of good programmers is that when given a new language to use, they learn it. I don't get why, coming out of university, you were content with using a language for two years without learning it. Learning from the codebase does not count, especially given its problems. As others have mentioned, there are lots of good Perl books, why wouldn't you buy one and actually try to be a better programmer than the person who left you a mess of Perl?

Another thing is that Perl is almost never taught formally, while many schools will teach Java and PHP - it is no surprise that there are many people who program Perl very poorly to start, and who think that Java/PHP/whatever is great language in comparison.

Cheers.

18

Hi Chris, I found your article over at dzone.com and thought it was quite interesting. I'm still not convinced about whether Perl will once again gain the momentum - I learned Perl several years ago (in the Glasgow area like yourself, there must be something in the water!) and still find it very useful. In fact, I wrote a blog post (http://www.equivalence.co.uk about my usage of Perl last week, and the general feeling I got from the comments was that a lot of Perl programmers have since moved on to pastures new - with Ruby appearing to be popular.

I'm afraid it looks to me as if the press a language gets is a key factor in its uptake, and convincing a fresh graduate (or even a seasoned developer) to learn Perl instead of Ruby or Python, when they read the many negative posts about Perl on Reddit or dZone, is definitely a hurdle.

Finally, and probably mostly due to the press issue above, convincing an employer to start a green field application in Perl is going to be difficult. I mean even you were not convinced by its merits before you started :-) .This will be even more difficult in a technology company, whose concerns may be that they may not find enough Perl programmers - especially graduates. Don't get me wrong, I don't see the latter as an issue but I think many would.

Anyway, I enjoyed reading the post.Gregg

19

anon monkey

Monday, December 8th

Also, take a look at Rose::DB/Rose::DB::Object. A better alternative to DBIx::Class, Class::DBI, etc.. IMHO.

20

Generally, when I find myself defending Perl (from the perspective of a "Perl guy" 16 years and counting), my first argument is the community itself, of which CPAN is just one part. A large, shining part I'll grant you, but still just one part of the whole.

21

Wow, didn't expect a response like this at all. Thanks for posting your thoughts guys, I appreciate it.

@Peter

mod_perl is fantastic, but with Fast CGI (or mod_wsgi et al) most languages compete on a level playing field when it comes to mod_perl's major benefits.

It was an important point to raise though, since mod_perl's ability to compile modules at server start up is especially important for Moose, which has a notable compile time hit (even with make_immutable).

@ Searle

Thanks for the book recommendation, always looking for interesting technical texts to read (making up for lost time!). I'll have a look at it.

@ Scott

That was a very interesting post. I studied Java, almost exclusively, at University so I am very familiar with the concepts of the strongly typed language :) For me there is a role in software development for both strongly typed languages and dynamic languages and I don't really agree with trying to turn Perl into something that it's not. C# and Java are always there if you need the benefits of strong typing and there are a lot more subtle ways to encourage higher quality code in Perl in my opinion.

@ z

That was mentioned on the reddit comments also. A lot of it was to do with my general state of mind when I left University (I'll probably write a post about this one day!), but I also think some of the blame lies with the management where I work. I was completely new to Perl and rather than encourage me to learn the language, I was just taught the basics of using the framework before I was thrown into the deep end of Getting Stuff Done.

I can't just lay the blame on management though - a good developer would have treated the language with more respect and picked up a book - so I obviously wasn't a good developer at that point.

@ Gregg

Absolutely. When it comes to Perl versus Python versus Ruby then I don't think there is too much between them in terms of how well designed the languages are. You certainly won't find "they suck" articles that rip the fundamentals of the languages apart like you would PHP. It mostly does come down to the stuff like supporting tools, ease-of-entry and hype.

That's why to 'save Perl' I think it's important to demonstrate that Perl IS the equal of Python and Ruby first. Then start marketing the hell out of it.

22

I've been coding in Perl for 10 years or so - whether what I do counts as hacking or programming is still open to question. I don't necessarily agree that it's dying, but support has been eroding. There are a few reasons I can think of.

- Perl Modules - probably the main reason people moved away from Perl was that you had to be system administrator to install Perl modules.

- CPAN. I know, a lot of people cite it as a strength. And it is. But it needs to be cleaned up - there are modules that haven't been maintained since 2002 in there, and worse. We need new rock-solid modules for web 2.0 and the rest.

- Perl 6 - never arrived. Oh, I know, people are working on it - or on Raduko, or Parrot, or whatever. A whole bunch of stuff we didn't need, instead of the basic language upgrade we did need. When growth in the development of a language stops - as it manifestly has - the language itself begins to die.

23

Stephen, I couldn't agree more with everything that you said. Now that I think about it, not having root access to our dev machine at work had a much bigger part to play with me not liking CPAN than it being different from PHP.

I think there are lot of tools in there to help provide web 2.0 type functionality, but you're also right that it can be hard to find them amongst all the cruft. It either needs cleaning up, or at the very least some sort "most popular" in terms of downloads or ratings, so that begineers to CPAN can cherry pick the best.

Sitting on IRC all day should never be a prerequisite for knowing a languages best tools.

26

rumi

Thursday, December 11th

Hey man

Hearing a story like yours makes me so happy! I'm realizing more and more that you can write good or bad code in any language.

I've myself have had a period of dissing PHP (the language i work in), but have learned to love it and now really feel I can express myself in it. Also checking the c source to php and writing c modules has really helped me appreciate why php is the way php is.

After doing some actual work in python and ruby I've realized that there is a lot of the down-and-dirty features from PHP that I really miss. PHP is not pink and metrosexual like ruby or cool and dangerous as python, but its so fast to use and really WORKS.

Its awesome to read that you have had a similar experience with perl. I guess in the end you just have to take responsibility for the code you create! At the end of the day, leaving the office knowing that your codebase is a little better than when you came.

Your little datamodel example looks very cool and useful!

RumiCopenhagen

27

Programmer

Tuesday, December 23rd

Why save it? Just let it die. Python and Ruby already do everything it does and they're both easier to read.

And the guy who said Perl's "simple" OO system is actually *good*.... talk about Stockholm syndrome. It's system is awful, the same thing C has basically with just one magic function for changing method lookup behavior. Great. But you're probably one of those guys who says the world doesn't need Mac or graphical OS'es because command line is the most advanced way to work with a computer (i.e. someone the rest of the world can and does ignore)

28

James

Thursday, January 22nd

'Programmer': Really, easier to read? Are you talking about python that is available at python.org and not some other language called python? Python is a whitespace mess, it makes moderately large modules and functions unreadable. As for Ruby, it has speed and scoping problems and has about the same readability (assuming good perl and good perl code) as perl.