I love the programming reddit. This week was an especially good one in terms of relevant content for me, with discussions on the death of Perl 5, the difficulties of hiring Perl programmers and how stupid it is to write your own framework. By strange coincidence, I just finished the alpha of a new in-house Perl 5 framework for my development team at work. And we're hiring!
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.
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.
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):
package Feature;
use Snow::Model::Sugar;
extends 'Snow::Model::Class';
table 'features';
field 'feature_id' => (type => 'Int', primary_key => 1);
field 'title' => (type => 'Char', length => 255, required => 1);
field 'slug' => (type => 'Slug', from => 'title');
field 'reporter_id' => (type => 'Int', required => 1);
field 'assigned_to' => (type => 'Int');
field 'status' => (type => 'Enum', choices => ['open', 'development', 'complete']);
field 'posted' => (type => 'Datetime', auto_on_add => 1);
field 'description' => (type => 'Text', required => 1);
# essentials
__PACKAGE__->meta->make_immutable;
1;
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.
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.
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.
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 :)
Cheers!
I am always on the hunt for chat about Moose.
Good work.
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!
I think the writing is on the wall for perl, and in my opinion rightly so - we just have better founded languages and tools.
http://badgerpower.com/ might be of interest to people looking for more more examples of elegant, maintainable and tested code like the kind found on the Mojo project...
Hi David,
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
Take a look at NYTProf for profiling. Much better than Devel::DProf!
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.
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).
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.
True, Damians book is good.
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.
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
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.
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
Also, take a look at Rose::DB/Rose::DB::Object. A better alternative to DBIx::Class, Class::DBI, etc.. IMHO.
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.
Oh, and I happen to be job-hunting at the moment... :-)
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.
local::lib eliminates the need for root with CPAN (actually it was not necessary before, but this makes it super easy.
@ Stephen, David
Here's a recipe for installing perl modules without root.
$ mkdir ~/local
$ cpan
cpan) o conf makepl_arg PREFIX=~/local
cpan) o conf prerequisites_policy follow
cpan) o conf commit
cpan) install Acme
cpan) quit
To put ~/local on your module search path, you'll probably want to set PERL5LIB.
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!
Rumi
Copenhagen
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)
'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.
Hi, good post. I have been woondering about this issue,so thanks for posting. I’ll definitely be coming back to your site.
1
mark
Sunday, December 7thI 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+).