If you want to understand Perl, spend some time on two things: 1) The ecosystem in which it developed and from which it borrows; 2) Larry's understanding of and perspective with respect to natural languages and the way they work.
Sometimes, Perl trades depth of knowledge for length and explicit minutia of code. It can be confusing if you are not familiar with the dialect, but terribly powerful if you are.
And behind the scenes, a lot of effort has been put into making DWIM (Do What I Mean) not only intuitive but often quite good at implementing an optimized solution (e.g. quite performant data representations).
P.S. Thank you, chromatic, for your continuing generosity and... I guess I will call it "belief", in the Perl community I encountered 15 years ago.
P.P.S. I never was a Perl "expert", and I'm woefully out of touch, these days. But the occasional bit I read leads me to believe that the above still pertains. And I'm curious to learn about version 6, which while a long time coming, really wanted to "take it to the next level". If and as it succeeds, it should be very interesting indeed.
I remember reading an earlier version of this, about 4/5 years ago (maybe the first edition?). It stuck in my mind as being fairly cleanly written, and also as being the tipping point at which I started to grok OOP in perl (and Moose).
Perl's greatest features (for me) have always been community and documentation/literature. In the beginning I thought every technical community was like Perl just because it was all I knew. I was quite surprised to find out how poor documentation was elsewhere and how disconnected the users were.
I owe a lot to random Perl community people for helping pull me up (literally since I was a child) to the point that I could get a job, then get better jobs, and eventually choose my own work and support a family.
Its been years since Perl has been the main tool in my toolbox but there is plenty in ~/bin and I plan to give Perl 6 another go. Still, I think of Perl often and fondly.
Has anyone else ever had that "If I am ever wealthy I will help __some open source community__"? More and more I realize life is passing by and being wealthy isnt important to me at all. So I better just say thank you here. ;)
The problem I've found in newer communities is they are so disconnected now.
Perl had p5p to guide them, and various conferences and very close knit groups which I was proud to be a part of.
I'm now more in the node.js crowd, which is huge, but feels like there's no good guiding group. I'm a mod in #node.js but the traffic there isn't communal. The node.js mailing list gets about 5 posts a day. I don't even know where people go to ask/talk about Node any more. Is it stack overflow? Somewhere else? Or do people just flail about not really knowing what they are doing? Sadly it feels like the latter.
And yes, the documentation of perl modules still far surpasses anything I've ever seen in other languages.
Yes! Close your eyes and flail your arms around and eventually you will hit something.
The way I use Stack Overflow makes me feel dirty. Usually it starts when I Google an error message because I'm using a new (to me) combination of language/framework/module/plugin. My mindbrain and fingers conspire to automatically select the Stack Overflow link even though it might be 3rd result and #1 and #2 might be from the official docs of whatever technology.
When I get to SO I read the answers first. That is often enough to shake something loose in my brain about my own problem. If that doesnt help I'll read the question to make sure I'm reading the right thread. I only comment or answer on rare occasion because it means that 1. I ended up on an inappropriate thread but actually know the answer and 2. it happens to be a fresh unanswered question. Seriously, I hope some of you are using SO the way they want it to be used and clicking on ADs or whatever. ;)
I used to answer questions in IRC channels just because I was already hanging out there, knew some people, and hey- I got answers from this group I might as well give back. But on SO I dont feel any attachment to a community, its just about Internet points. And for those who arent keeping score its just get-in-get-out. Maybe its just me.
If you don't yet, I recommend you subscribe to the perl weekly: http://perlweekly.com it's a great, concise overview of what's happening in perl (5 and 6). A very simple, low effort way to give back financially would be to sponsor the newsletter via GratisPay http://szabgab.com/gratipay.html Obviously there are also many other ways, financial and non-financial, to contribute to the community.
In my case, I find the Moose ecosystem much preferable to almost any other OO system I've used. Better multidispatch would put Moose over the top.
The last time I looked at Python 3, Perl still had much better Unicode support. In particular, grapheme support in regexes, built-in casefolding, and easy normalization made a 100+ country project much easier.
The stability of the language, core libraries, and CPAN modules across major releases really helps with maintenance. Python's 2/3 break was a bummer for a lot of people for a long time that I'm glad to have (mostly) avoided.
Generally, dealing with data in multiple encodings is far more pleasant in Perl (or at least less unpleasant). I came back to Perl for this very reason when I had to write a script that pulled data from our Active Directory (unicode), our ERP system's database (Latin-1) and a bunch of text files (CP1252), merge it and render it into a HTML file or an Excel sheet (unicode). I tried using Python, but I quickly gave up in frustration.
I hope so. It's pretty bare at the moment, but it shouldn't take too much to get it to where, say, Go-lang was when people started to adopt it in earnest.
Won't Perl6 make the book redundant, I mean the whole reason we needed a Modern Perl book was because there was an old and crufty way of writing Perl5...but Perl6 ditched all that baggage so the only way to write Perl6 will be comparable to Perl5's "modern Perl" paradigm?
Modern Perl book was first released a few years before P6, which isn't even released yet. The companies that currently use Perl (at $work, even) are not going to switch to P6 any time soon, but can, and do benefit from the more recent best practices using Perl 5.
First, Perl is installed on millions of machines by default, with full access to the CPAN--still one of the largest repositories of freely available libraries, with Perl's backwards compatibility and testing offering a lot of stability. If P6 comes out and succeeds, it'll still be quite a while before it can offer anything like that.
Second, I've given away electronic versions of the book for five years. It's not about the money or the job prospects for me. I figure the book's helped more people than I can count, so why not continue?
I figure the book's helped more people than I can count, so why not continue?
It's one of the finest programming books out there, about any language. And your work is very much appreciated. (We've never met, so I hope you don't mind me saying).
Long-time Python dev here, recently started picking up Perl (both 5 and 6).
As with anything, learning another language will give you insight into how things _could_ be done, and you'll pick up a new perspective on programming.
More concretely, I've been liking perl because it's much more expressive than python, especially when writing small unix-y programs or scripts to control the machine.
And of course, sometimes it's just nice to have a variety of tools in your toolbox. We may as well ask whats the reason for learning Python when $LANGUAGE exists. The answer is always going to be some variant on "just because".
I'm not sure I agree that that there is clear winner in expressivity between Perl and Python. In Perl dealing with nested data structures feels really awkward. And Python's list and dictionary comprehensions and generator expression are very handy and highly expressive. Anonymous functions are much more pleasant in Perl than in Python. The added flexibility in placing 'if' and 'while' in Perl is nice sometimes, but I don't think it is a huge advantage.
Going over this (personal) list made me realized I'd probably like Perl 6 better than either Perl 5 or Python...
I think you misunderstood what "more expressive" meant. It doesn't mean "more concise", though Perl can excel at that too. It means that expressions can be stated in more meaningful ways.
do_the_thing() if $is_ok;
warn_the_user() unless $is_ok;
The if/unless pair, along with the ability to put conditionals either before or after the statement to execute, is just one example of Perl's ability to be very readable.
If we're honest with ourselves these discussions are never really about anything more than taste and have almost no technical foundation, but with that said I don't think the trailing conditional is more readable. In the rest of Perl the order in the text of an action normally indicates the sequence of the side effects, but here the first thing to be executed is after the first thing in the text.
Larry Wall is a linguist first, and the design of Perl's syntax reflects that. So I can totally buy taste being more important than technical foundation, in the same way good graphic design is done.
These expressions with the conditionals on the end are supposed to reflect English phrasing. English isn't strict about the order of parts of speech; you can mix them around to change the emphasis. These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent, the way one programmer might explain the logic to another programmer.
> These expressions with the conditionals on the end are supposed to reflect English phrasing.
But nobody's ever explained why that would be a good thing to do. We say things like 'you can read it out loud and it sounds like English', without ever arguing why this is a good thing.
Do most programmers even have English as a first language?
I'm not sure aspiring to be like natural languages actually has any merit. I think we should aspire to precision and clarity. Natural languages rarely have those qualities.
From DougWebb, explaining why this would be a good thing to do.
>> These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent.
We can achieve perfect precision and clarity by naming all of our variables x1, x2, x3, x4, etc. But it's better to give descriptive variable names because it helps us and anyone else reading the code understand what it does. This sort of expression is similar.
I can't see any argument in there. 'meant to express programmer intent'? What does that mean? Basing programming languages on mathematical notation or something else would also of course be 'meant to express programmer intent'.
Why are natural languages a better foundation for programming languages than, for example, maths notation or calculi? Everyone in the Perl community seems to think they just intuitively know it is, but can't explain why.
When you're speaking to another programmer, explaining what a bit of your code is trying to do, do you speak in mathematical notation? I doubt it. I don't think even mathematicians do that.
If you want a well-expressed explaination for why Perl's approach is a good idea, you should read what Larry Wall has written about it. All I can really say is that it worked really well for me and my team for many years. We rarely misunderstood each other's intent, even though our code reviews were mostly just reading commit diffs.
Think of it as a commenting or documentation system that's also interpreted by the language. Comments that can never get out of date.
If you think that human-readable comments and documentation are not useful... then I'm not going to try to convince you that you would benefit from perl's syntactic flexibility. But surely you recognize that there are some people that like documentation, useful comments, and informative variable names.
It's actually "if x { y }" in Perl rather than "if x then y".
This favours blocks of multiple expressions whereas "y if x" is good for a simple single expression.
A lot of the Perl branching and looping directives provide both methods so you can choose what you prefer.
Having both ways is great for the Perl one-liners :
cat file | perl -e 'while (<>) {next if /^SKIP /; print if /<fancy regex>/;}'
If all someone wants to express to a reader is literally `if x then y` then `y if x` doesn't really help.
But we typically don't write utterly trivial one-liners with single letter names for conditions and actions.
In actual programming there are times when it's more like a series of lines, each of which is something akin to `if some-expression-that's-so-much-longer-than-a-single-letter-that-you-start-to-consider-factoring-it-out-in-to-another-variable-or-function then some-function-or-flow-control`.
And when that happens there are times where by far the most important thing a writer wants to first bring to the attention of a reader (eg themselves, later) is some-function-or-flow-control.
Sticking with made-up examples for a moment, there's:
if long-complex-conditional----that-you-might-start-to-read-thru-in-an-attempt-to-understand-the-code-you're-reading---is-true then blow-rocket-up
vs
blow-rocket-up if long-complex-conditional----that-you-don't-need-to-read-and-understand-to-understand-that-the-rocket-will-blow-up-if-it's-true----is-true
Or it takes me I estimate less than a second to know the gist of the overall control flow of this fragment from a recent Advent of Code entry[1]:
next unless (() = /[aeiou]/g) >= 3;
next unless /(.)\1/;
next if /ab|cd|pq|xy/;
$count++;
I can immediately see that it increments `$count` unless it bails out of the containing loop (`next`s) due to any of several (complicated looking) conditions.
In contrast, it might well take me more than a second to figure that out if they'd written:
unless (() = /[aeiou]/g) >= 3 { next } ;
unless /(.)\1/ { next };
if /ab|cd|pq|xy/ { next};
$count++;
While these examples are pretty weak, I have hope that they might at least give you pause for thought. If you don't see anything going on here worth even thinking about, or more importantly seriously reflecting on, well, at least I tried. And if you're a trained linguist and/or able to quote science to refute what other scientists are finding in recent studies[2], please quote away. :)
In that you can see more or less visually what the intent is rather than having to mentally parse the text. But perhaps that's just personal taste.
IMHO, expressiveness and conciseness are largely the same idea because when you talk about the former, you mean being able to bang out an idea in fewer lines of code yielding the latter.
Having a complex grammar and a myriad of ways to do the same thing seems very neat, but in the end the productivity gained in the writing, you waste several times in the reading, so it ends up being a net loss.
But Perl lost the dynamic language wars a long time ago -- I think perhaps some of the flavor got picked up in Ruby?
And having a language read like English is IMO, a bad idea -- English is very ambiguous in many cases -- mimicking this in your programming language would be a bad idea indeed.
It's precisely a slippery slope argument[1], which is generally much debatable.
Perl somewhat indulged the nix culture tendency to write extremely concise and cryptic one-liners, but* this does not mean that verbosity is good and expressiveness is bad.
I use Python usually but Perl is simply faster at processing large amounts of text.
And while Python has made great strides in regex readability since the 90s, Perl's regexes are still more cleanly and flexibly incorporated into the language.
I started as a Perl dev, and I must say that some of the principles I learned there that I still feel are underutilized in other languages even though the syntax could support them.
I think the very nature of Perl meant that I had to learn additional tricks to make the code make more sense when I returned 6 months later...tricks that I wish other languages embraced. Having your code not be obscure is the minimum, not the maximum you should be shooting for.
Also - I'd still write short scripts (basically glorified one-liners) in Perl vs Python. JS is getting up there, but still isn't as expressive as Perl.
Edit: And I say this with full respect for other languages, particularly Python that has done a lot for many areas of development
Perl often gets flak for "There's more than one way to do it", and sometimes that's justified: It's confusing to do things a billion different ways. BUT, sometimes you can use those different ways to be meaningful. So:
foo() unless (condition) vs if(!condition){ foo() }
They are FUNCTIONALLY the same, but COMMUNICATE differently. If you don't pay attention to the latter, then TIMTOWTDI will be an enemy. If you do, then it can really help.
Also: "not", "and", "or" - I wish more languages had these. && and || might seem to be the same thing, but there's no reason to cling to foreign symbols where native (for english speakers) symbols do the same. ! is particularly bad, since it's so small, can easily blend in to an adjacent paren, and yet REVERSES the meaning. Don't get me started on the terrible switch/case syntax that is perpetuated for no reason other than C did it.
Moving away from syntax, hashes/dictionaries/associative arrays/Js objects, these guys all have the same basic addressing style. If you're using them in a context where the key will almost always be present, why not use that?
instead of addresses[currentAddress]
use address_of[current] (or addressOf[current]
Instead of building variable names that are 4-5 camelCase words, use the hierarchy of your structures to communicate more clearly.
variables are WORDS. Too few words doesn't communicate clearly, but too many is just as obtuse.
There are a great many "clean" bits of code out there - nicely structured, nothing wrong, but I'll still have to read the whole to understand a part of it. Similar to the semicolon argument: The reason I object to dropping semicolons is not that the statement needs it - but that I need to read the next statement to retroactively know if the statement needs it.
If you can write code so that a reader understands what is happening as they read, rather than understanding the whole and then viewing the parts in that context, your code becomes that much more maintainable.
Personally, I use Perl for small-ish programs (roughly less than a thousand lines, counting comments and long text constants such as SQL queries) dealing mostly with text, and in that area it is fairly hard to beat.
Also, while Python's library ecosystem has grown a lot over the years, in Perl you can find so many modules on CPAN, ranging from very common tasks (like talking to a database / ldap directory / network service) through fairly exotic (at least in my perception: e.g. formatting datetime values in just the right way to feed them to MS SQL Server, figuring out if a given day is a holiday in a given federal state of Germany) to downright silly (but in a clever way: CPAN's ACME::* branch). You think of it, CPAN probably has it.
One thing I have grown to appreciate about Perl is its mentality of helping you getting the job done no matter what. Python is a - relatively - clean and simple language, where Perl is not ashamed to be messy, but it's oh-so-useful I just cannot stay mad at it. ;-)
Last but not least, the Perl community is awesome, there are so many friendly and helpful people around willing to share insights, code, and words of encouragement. (That is not to say other languages have bad communities, not at all!)
> One thing I have grown to appreciate about Perl is its mentality of helping you getting the job done no matter what.
It is incredibly effective at helping prototyping rapidly small ideas.
> the Perl community is awesome, there are so many friendly and helpful people around willing to share insights, code, and words of encouragement.
And CPAN helps a lot too! It can be considered as an important part of what makes this community so special, it is a very serious repository of modules, I mean not only code: it is incredibly usable, with lots of documentation and a crazy test infrastructure (http://www.cpantesters.org/) that helps to build quality distributions.
The good thing with the Modern Perl book is that, before explaining the language itself, it explains the Perl philosophy. And then it explains about the community and the CPAN. Being modern is also about not writing code and re-using long-tested modules from CPAN with cleans APIs: it helps to compose quality code and make maintenance easier.
Not really. As in, I wouldn't start from zero and try to learn enough to get a day job at it, at this stage.
There are still so many negative tradeoffs in Perl 5 -- especially, and most crucially, for new adopters -- that I don't think it will ever make up the ground it has steadily lost to Python/Ruby/PHP over the last 15 years. P6 has addressed many of P5's most notorious faults, while perpetuating others, and quite likely introducing a whole family of newer, far subtler traps and pitfalls. All while being not particularly fast, poorly document (last I checked -- about a year ago), and like Perl 5, just plain.... zany.
That said, there are a lot of incredibly bold -- we might even say, "ahead-of-their-time" ideas in Perl 6 (just as there were in Perl 5, in its time), and I sincerely hope many of these will be carefully studied -- and I won't be surprised if some of them are incorporated to whatever "lingua franca" that ultimately emerges and ends up burying Python, hopefully not too long from now.
> incorporated to whatever "lingua franca" that ends up burying Python, hopefully not too long from now.
Sincerely, at this point (Dec 2015) I feel like python is well too far along to be buried. As you state, if something better comes along I too would welcome it, but, and correct me if I'm wrong, python has been around for 20+ years, I don't see it being buried anytime soon.
> Is there a reason to learn Perl these days when we have Python?
Yes, the GIL - global interpreter lock (in python) is a reason if you are doing multithreaded stuff in a scripting language (which i think is a bad idea by definition because suddenly you are debugging problems in your program as well as the interpreter/runtime)
Perl 5 has an interpreter instance per thread, so it doesn't have a global interpreter lock. It will have other problems with threads though - you can easily run into deadlocks for example.
Let's not pretend perl threads solve concurrency issues in dynamic languages.
The third item in the threads perldoc, after the table of contents and the version, is a big, fat warning about how you shouldn't use them [1]:
> The "interpreter-based threads" provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that make them easy to misuse. Few people know how to use them correctly or will be able to provide help.
>The use of interpreter-based threads in perl is officially discouraged.
> Perl 5 has an interpreter instance per thread, so it doesn't have a global interpreter lock. It will have other problems with threads though - you can easily run into deadlocks for example.
Which makes threads more expensive than processes on *nix because you don't get the advantages of copy-on-write processes. Also most of the librarys that use perlxs modules aren't thread-safe.
> Let's not pretend perl threads solve concurrency issues in dynamic languages
i didn't 'pretend' that - that's a misstatement; still a big fat lock in the interpreter isn't a concurrency solution at all, instead of running concurrently your threads will be mainly blocked on the lock.
Interpreter threads is an approach that does without a global lock, but as i said it is still a pain to debug the result - as you are effectively debugging both your program and the runtime.
> Which makes threads more expensive than processes on *nix because you don't get the advantages of copy-on-write processes.
threads are not copy on write processes; that is not unique to perl threads. The advantage of threads is that it makes easier to share data - with processes you will need to do a shared memory segment for that. Also it is less costly to create a thread rather than a process.
> The advantage of threads is that it makes easier to share data
Sharing of data is of marginal benefit when you have to pay the cost of duplicating all of your data to begin with. Perl also has modules that make forks just as easy to use as threads.[1] This is doubly so when most libraries have little to no regard for thread safety because perl's threading support it so bad.
> Also it is less costly to create a thread rather than a process.
Not unix because of copy on write processes [2][3]. Perl threads copy not just the interpreter but all local variables. [4] The only place threads are useful is on windows where the cost of a fork is higher than a thread.
> most libraries have little to no regard for thread safety because perl's threading support it so bad.
Fwiw Perl 6's concurrency and parallelism is very much one of its strengths, not one of its weaknesses.
(It's pretty obvious to me that you are writing about Perl 5, not Perl 6, but it might not be obvious to others. Indeed some folk will even claim Perl 6 isn't a Perl, but Perl's original creator Larry Wall thinks Perl 6 is a Perl, and I think he has a point.)
Indeed. But the book is about Perl5. Perl6 is such a different language that someone moving from Perl5->Perl6 will likely be mostly/completely a rewrite.
... unless, I suppose, they are following the practices in Modern Perl ala Moose and some other things. I guess maaayybbeee they could translate across. But it would be touching ever single line, in a transformation that would be on par with switching to Ruby (or Python I suppose).
It seems disingenuous to imply that moving to Perl 6 from Perl 5 is akin to switching to Ruby or Python (much less "touching every single line"). Perl 6 supports Perl 5 syntax with Inline::Perl5. So, in theory, one could move Perl 5 code directly into a Perl 6 project without changing much at all.
Edited: an earlier version of this comment that referred to an outdated FAQ (mentioning a perl 5 to 6 translator).
Yes, I updated my comment, but my point still stands: Perl 6 supports Perl 5 syntax and migrating is nowhere near as hard as was implied. Sorry for confusion.
Your comment is still blatant disinformation. By the same measure Perl6 is also Python and Java and JavaScript, because somebody could make an Inline:: for any of those.
You could say that a number of hooks exist to make it easier to write various Inline:: variants, and you would be correct. But claiming that there is a special soft spot for the Perl5 interpreter is factually wrong.
What disinformation? Perl 5 is supported when using Perl 6. The comment I replied to states:
"Perl6 is such a different language that someone moving from Perl5->Perl6 will likely be mostly/completely a rewrite."
Rewriting is not always necessary due to Perl5 support.
The comment further states:
"I guess maaayybbeee they could translate across. But it would be touching ever single line, in a transformation that would be on par with switching to Ruby (or Python I suppose)."
Touching every single line is technically not necessary due to Perl 5 support.
To your comment:
"But claiming that there is a special soft spot for the Perl5 interpreter is factually wrong."
Nowhere in my comments did I make any such claim. I was simply refuting the statement that people with Perl 5 code will have such a difficult time with Perl 6 that it would be just as painful as dropping all their Perl code and switching languages.
Although to switch to ruby or python you'd likely end up either typing out a lot of things Moo(se) give you or trying to port them (see also the MooseX gem and Elk)
I think it would be closer to say "Perl 6 and Perl 5 are two completely different languages, and have about as much in common as Ruby and Perl 5". All the languages in that sentence are Perlish languages, so to me it conveys the relationships better. Perl 6 definitely has a lot to do with Perl 5, especially the mistakes therein. If anything, it's the most Perlish of them all.
It's the latter, except that you can 'use Inline::Perl5;' in perl6 to get at perl5 code and 'use Inline::Perl6;' in perl5 to get at perl6 code. I don't think we're likely to see modules attempt to provide the same interface to both, but then again, given the above I don't think we need to :)
There has been some work to integrate Perl6 modules with MetaCPAN. I'm not sure what the current status is, but that's one possible route. This would mean the modules would be uploaded via PAUSE.
The page says that there is no DRM on the ebook, yet every page of the PDF is watermarked with the name you used to order. Sounds like managing digital rights to me.
You can copy it as many time as you want, read it concurrently on any device that can read PDF, and you can use it offline. And if PragProg goes bust, you can still read the book.
I agree that it might be a bit ugly to have your name on it repeated but it is quite "discreet" nonetheless,
and unless your name overlaps with a particular perl keyword, it should not impact full text search.
It's not that easy to remove. To be completely sure all identification info including IDs and other generated differences are removed you would need two files sold to different people and remove everything that differs. I'm not going to buy two copies of a book just to get the clean file that they should be selling in the first place.
O'Reilly and NoStarch don't do it because they honour their customers. Watermarks are a disgrace and a potential risk for the customer, because they put the liability to protect the book from third party access onto the customer. I'm not going to accept this. I only buy untouched books. Calling books DRM free when personal identification information is stored into a digital file to restrict the customers usage rights is ridiculous. Shame on those sneaky publishers.
It's really not drm but it sure is ugly Manning does it to.
Fortunately it's super easy to unpack a pdf with pdftk or the like then you can delete the text of the watermark with sed or perl if you like then compress again.
I have a script that removes a list of watermarks automatically prior to importing to calibre.
Come to think of it I should propose this as a feature for calibre.
It's in the bottom left corner and in light gray text. Not much of an issue. Plus, the author and publisher are doing us a favor by letting us have the ebook for free.
Perl 5 has an extremely mature, diverse, and vetted ecosystem, with 20+ years of Perl 5 code out in the wild that people use, maintain, and continually develop.
Perl 6 does not. It will hopefully one day, but come Christmas time, we're not all going to just drop Perl 5 and start coding Perl 6 exclusively. They're Sister languages; Perl 6 does not deprecate Perl 5.
Ah I remember when I was trying to learn Perl. Because I knew PHP at the time, I thought it was awesome, even better than PHP. Now I just use Ruby, but I'm happy Perl is still alive.
Sometimes, Perl trades depth of knowledge for length and explicit minutia of code. It can be confusing if you are not familiar with the dialect, but terribly powerful if you are.
And behind the scenes, a lot of effort has been put into making DWIM (Do What I Mean) not only intuitive but often quite good at implementing an optimized solution (e.g. quite performant data representations).
P.S. Thank you, chromatic, for your continuing generosity and... I guess I will call it "belief", in the Perl community I encountered 15 years ago.
P.P.S. I never was a Perl "expert", and I'm woefully out of touch, these days. But the occasional bit I read leads me to believe that the above still pertains. And I'm curious to learn about version 6, which while a long time coming, really wanted to "take it to the next level". If and as it succeeds, it should be very interesting indeed.