I've found a lot of embedded wisdom in the "old school" stack. If you edit in vi, add some sed / awk / grep, and learn some bash, you'll find these tools start to come together and leverage one another up substantially. Perl might be more post-Bell Labs but it still was written and used by smart people to Get Stuff Done. It stands to reason that there are large returns on learning it.

But it isn't as approachable as Python. When I needed a glue language, I first looked at "Learning Perl" -- after a few days I concluded that, if this was The Path, then I would never get There. Python was much more approachable, and my code already gathers so many hacks that I'm glad my language forces me to make these at least somewhat intelligible.

I would learn Perl faster now. But for what? I've learned some PHP to meet client demand, and for web development the next language would be RoR. I bet Perl is better than bash for various sysadmin and utility tasks, but bash feels good enough for the simple stuff I do. If I needed to do something really beyond bash I'd turn to Python, and I'm not sure why Perl would be better. I suspect there's a lot of general knowledge embedded in Perl but I'm not sure how that gets extracted and made current among today's toolset for the tasks I have.

So to my mind, Perl is something of a sysadmin tool, better than bash and very useful for a workload focussed on system and file processing, on *nix, without much service to HTTP. I'd love to hear how it pays returns for people more focussed on back-end support of web development.

Minimalism, is both an advantage and a curse. You may be able to learn python quickly, and that is because the syntax and semantics are designed with a goal to do that. But unfortunately that is not the only problem programmers have, Learning how to program is problem only for first few weeks of your programming career, there after its hardly a problem. Beyond that verbosity becomes a curse, once you begin to understand what 10's of lines of code do, you wonder why you even need 10's of lines of code when something can be expressed more elegantly.

In my experience people complain about learning Perl for the same reasons why they don't get awk/sed/tr and other text processing utilities. Tools like that are a little difficult to start with, but offer tremendous advantages. Skip learning them, and suddenly you put yourself in a situation where you start your eclipse and write Java programs for every small bit of text processing task. That sucks up your time, effort and code forever. So its better to learn tools that are better designed to solve such problems.

>>and I'm not sure why Perl would be better.

Perl and Python are both excellent languages, so you find a range of problems that can be solved in both languages well. But try solving problems that Perl was specifically designed to solve, Pick up the book Higher Order Perl by Mark Jason Dominus(Its Free) and see for yourself how Perl helps you solve a certain kind of problems. I'm sure its the same case with Python too! Its good for academia, as its easy psuedocode.

Problems that can be solved in both Python and Perl can obviously be solved in any of them.

>>So to my mind, Perl is something of a sysadmin tool, better than bash and very useful for a workload focussed on system and file processing, on *nix, without much service to HTTP. I'd love to hear how it pays returns for people more focussed on back-end support of web development.

You have just described a very small subset of problems Perl can solve. Perl is used for developing very large application in nearly almost every industry.

Web programming != Entire Programming world.

Much of the software world never writes a web page. And they do programming too. But like us they don't tweet/Facebook/blog every time they finish writing a class.

To pick one thing - Perl's testing infrastructure. It's just awesome. I miss it in other languages.

See http://news.ycombinator.com/item?id=4040005 for a discussion.

But there's probably a great deal more value to be had to knowing just one of the big three scripting languages (Perl|Python|Ruby) deeply than in knowing just a smattering of each.

Long-time perl programmer here, until I found Python. Perl is powerful, but Perl is for the programmer, not the programmer's coworkers. It's not even for the programmer 6 months down the line. This is nothing new, and it has become a stereotype in the community.

Yes, this argument has been made and refuted many times, but I argue the reason isn't the language, but the dominant language paradigms.

Perl's "monk" ideal is not sustainable in the long term, and encourages "clever hackers" who can do things with the fewest lines of fundamentally unreadable code. Yes, the language has evolved. Yes, it is slightly easier to read now. But the goals of the community still tend toward the ideals of becoming a master of arcana who can pass his wisdom down to the less experienced.

Give me a language that the commoners can read, that a beginning programmer can feel empowered to learn because he can take one look at the source code of someone truly experienced and know at least a part of what is going on.

You can change Perl all you want, but you cannot get away from the fundamental guiding principles of the language, which encourage antisocial, clever, and magic code.

I have seen so much really wonderful, readible, maintainable Perl code, that I don't think your characterization works.

You know if I come back a couple months later and don't like my code, I rewrite it based on my objections. It doesn't happen often but it does sometimes. It happens in any language.

If you value maintainability, you will eventually write maintainable code. The only flaw Perl has is in promoting valuing getting things done more than maintainability, but that's a culture of programmers, not the language. You can get good groups together than can write beautiful, maintainable code. I have done it. I know.

    > What is modern Perl? Python.

I am also a Perl to Python refugee. For most applications I get far more enjoyment out of Python. But try implementing Higher Order Perl in Python and you won't get past Chapter 1 without some weirdness. Using decorators, lambda, map, reduce, itertools, even generators all feel like bending over backwards to achieve what comes naturally in Perl.

This isn't an attack on Python. I'm just saying, Python is not meant for functional programming any more than Perl excels at OO, and that's why I disagree with your thesis.

Check Moose and related on CPAN, modern Perl has probably the best OO among the usual scripting languages (Python, PHP, Ruby, etc).

I think that both Perl and Python programmers disagree with your statement.

I'll enjoy Python when pypi doesn't frustrate me many times more than CPAN, there is some Python equivalent of Moose (Python 3.5, 4?) and the grammar is extensible like Perl 5 (using CPAN modules).

He gives away his ebook for free, so I guess giving him free domain might be very good for your karma :)

Until one morning a colleague of mine, saw me doing some stuff I was taking really long to finish. He just walked up to my cubicle and just said 'Why dont you use Perl to do this' and then started my crazy journey with Perl. What I really like about languages like Perl/Python and Ruby is how quickly you can go from learning to building something really useful.

Perl has seen atleast 3 major rise in its popularity since its inception. First one among sysadmins, its from these days that you will powerful terse, small but elegant solutions to a range of problems. If you ever get a chance, do browse and read essays from Tom christiansen written during those times. They are just pure gem. The second was during Perl/CGI days. And third was the most recent with the Modern Perl movement. Much of the thanks for this goes to People like Chromatic, Audrey, People of p5p, Moose devs and etc. From each of those times, you will see varying variety of code written. Starting from really amazing one liners to at times some frustrating code during the dot com bubble, to now where Perl code really looks very nice.

Modern Perl really is set of many successful sub projects. And its not just code, it covers everything. Code is just the beginning. To give you an example, these days you have very nice cpan package managers. You can search packages using Metacpan in a very user friendly GUI with nice syntax highlighting. You have awesome documentation, Modern Perl book really is the Perl's equivalent of the K&R book. There is Moose, And there are things like Class::MOP. There are things like DBIx::Class.

In terms of other new breath taking stuff you will see things like Devel::Declare. This allows new syntax extensions to be written using Perl itself. Then as a result you have a range of modules like Moosex::<extensions>,Try::Catch, Gather::Take etc.

In terms of web frameworks your have Catalyst.

So its really these many many successful subprojects together which form 'Modern Perl', if you wish to describe it that way. Its no one thing. Code, documentation, culture, events, infrastructure etc etc all together form the 'Modern Perl' thing.

If you come to the Perl core development, then they have real good time based releases. They are fixing bugs, adding new features, and doing a lot of amazing stuff. There have been pretty neat syntax features added in the past few releases and I guess much of Perl 6 based features will continually seep into Perl 5 as needed over time.

Modern Perl, or other wise. Perl continues to retain its niche. Which is text heavy lifting, automation, rapid prototyping, development, a deep learing curve and larger gains in productivity with time. Its still the go-to tool for most back end tasks. If you wish to get something done faster, with little effort, sanely with little bugs in say over a weekend, You have little alternatives apart from Perl. If you are in dev ops and you have P1 tickets standing on your head pretty often, a tool like Perl is indispensible.

And most importantly its areas of strengths are only growing- Unicode, regular expressions, CPAN, powerful syntax etc. If you ever get a chance Higher Order Perl is one book you must read. It really opens your mind to elegant solution to a range of problems.

But like every other language, you need to invest time and effort incrementally to keep yourself updated.

This being said like most frameworks it is extremely important to know when to leave the framework or leave things out. While I LOVE working with Moose, my own projects are very heavily stored procedure centric and therefore an ORM like DBIx::Class really does me very little good. DBIx::Class by all reports is an excellent ORM but it's still an ORM. ;-)

There is no better glue language I have ever encountered than Perl We use it in LedgerSMB to glue together stored procedures, web templates (in Template Toolkit), and the web server interfaces. It's a wonderful language and I can't recommend it highly enough.

As for Perl 6, it has joined HURD 1.0 as one of those projects that will be released when pigs fly. I suspect that Perl 5.x will be as far as Perl gets.

I spent a fair amount of time hanging out in #ledgersmb a while back and in spite of being the project founder of DBIx::Class, I don't think I ever felt I had a convincing argument for using it, so honestly I'm glad you're not doing so (if I ever come up with an O<sproc>M or something I'm sure you'll find out :)

Actually some of your recommendations are pending getting rid of old code (we simply can't move everything to PSGI when we have the mixture of old and new code we have, so it's CGI only for now still). However we are giving hard thought as to the best way to do so and I expect that as we continue that process things will become more PSGI friendly until it is just a matter of changing one sub somewhere.

I should note you have convinced Josh Drake on the merits of DBIx::Class for other projects though.

Finally I think it is worth noting that I think that in the 1.4 tree we've come out (I hope) of the contageous effect of the bad SL code, and so the coding styles which evolved so much during LSMB 1.3 are being formalized and moved to Moose in 1.4.

There has also been quite a bit of change in the perl Web Framework world as well. IMHO Catalyst is no longer king. Mojolicious has really taken the spotlight. It's fast, the community behind it is really creative and it supports websockets. :D Mojo really does make perl web development fun again.

There is also a Sinatra inspired framework, Dancer.

It is a bit of a marketing term, though. Not many of the "modern" features are really new to Perl, but basically rather common modules. In the case of Moose, they do change the language use significantly, but mostly it's about showing that Perl can be used beyond small, one-file Unix scripts. And it's been able to do that for quite a while, the Perl 4 days are long gone.

Still, getting some new-found traction is important, and popularizing some great CPAN modules definitely won't hurt.

There are now dozens of CPAN modules with names like "common::sense" and "Modern::Perl" that provide no useful code, but introduce packaging dependencies and administrative overhead in the name of not having to type "use strict;" out by hand.

Modern Perl is using Moose::Any instead of just using a language that does what you want. Modern Perl involves an average of 130 CPAN dependencies for any give application.

Modern Perl is when perl stopped being perl and started being awful.

But a lot of these things are not for all projects. I use Moose but not DBIx::Class in most of my projects.

I think Moose is wonderfully designed, but that's just me. you may differ in your opinion and build your own modules your way. There's more than one way to do it!

I had the impression it was more a cultural shift, a renewed interest in Perl and people wielding it much differently. There's a different CPAN web interface[1], a lighter cli client[2], and everyone is on GitHub and writing hundreds of tests. I guess Moose is part of that shift but I'm torn a lot of the time - I support modern Perl but I hesitate to support blindly copying the warts from other languages just to appear modern.

This[3] is a result of searching for common::sense ... yikes.

[1]: http://metacpan.org [2]: https://metacpan.org/module/App::cpanminus [3]: https://metacpan.org/module/Real::Handy

It pushed a much more declarative approach than usual, that swaps over to other projects (Moo, Mo, even Class::Accessor supports has declarations now). It has a community that is focused on best practices with regards to OO. It put introspection more in the spotlight (like the idea of getting Getopt definitions by introspecting classes).

It is also flexible, which allows for lots of extensions to its functionality. That means a lot of concepts are tried out on CPAN already. Even if someone doesn't use Moose, there is lots of OO knowledge to be found in the ecosystem. Same goes for runtime type constraints/coercions.

Then there's the p5-mop project, that would provide a common core, so many of the things above could find themselves in a much more light-weight and broadly usable variety, with side-effects like less heavy anonymous packages.

Personally, while I'm very excited about where Perl 5 has come so far, I'm even more excited by the things we haven't thought of yet.

Moose is a bit heavyweight. It may not be what you want in some applications. However, it strikes me as an inspiring example of design done right, and for that reason it's worth learning.

I think this exemplary aspect is why Moose has had the impact it has, not only being somewhat widely used, but also defining approaches that many other object approaches have borrowed. The fact that things are declarative is very helpful.

Your post might've been a well founded rant against the topic at hand, unfortunately you've lost any credibility by default when you added specific and personal insults. Poor taste..

C++? Yeah, brand new version out with whole new metaphors (An... rvalue reference?! And what is that -> operator doing there?).

If you want compatibility, you have it. 15 year old perl scripts run fine on 5.14. If you want the community to not invent new stuff... dig yourself a hole I guess.

I've written two.

Perl changes so often that writing about it is like trapping a unicorn.

Not really. I document things with staying power. For example, I documented only the parts of smart match that are easy to explain. Everything else is up for debate, and thus not really worth recommending. (Besides, I'm not trying to replace the documentation.)

Perhaps there is a happy medium somewhere between these extremes, though.

(there seems to be just a bit of sarcasm in the above post, though -- writing about the moving Perl target is hard, but having a non-moving base one is employed to build on has its own "joys", as well)