Exactly. Larry Wall cited an analogy somewhere: if you want to know where to put walkways on a new campus, wait until pedestrians have worn trails into the grass and pave there. Perl docs repeatedly makes jokes along the lines of, "it does what you want, unless you want consistency. Bottom line, Perl was designed without predictability and consistency in mind. This makes it blazingly fast for development by one person, but the administrative overhead between multiple programmers balloons.
Because of a natural inclination to reduce the number of characters one uses, as you get comfortable with Perl you start taking more and more shortcuts. A singular moment in my long career occurred when I opened some old Perl code after leaving the language for a time. I stared for a long moment, dumbfounded. It was as if an alien had visited my computer and overwritten my code with what Wall has affectionately described as "line noise."
Also, I was awed by the feature set in Perl 6. I don't think any language outside of Lisp, C, and Smalltalk has had such profoundly new ideas. Pronouns in Perl 5 are still unique to my knowledge after 20+ years. Wall is wildly imaginative.
Perl is what made me realize, in the mid-90's, that OO is largely just a marketing term. A sufficiently powerful language provides whatever portions of OO you need a la carte.
Larry Wall (primary author of record for both Perl 5 and Perl 6) noted in an article[1] that:
"Perl 6 is also a completely different language ... [that specifically addresses] readability"
Or, in greater depth:
"Perl 6 is also a completely different language that has been rethought and rebalanced on every level, with much stronger support for both functional and object-oriented programming as well as reactive and concurrent programming.
There is now pervasive concern for composability, evolvability, readability, and maintainability.
We try to "hang everything on the right peg" to allow proper separation of concerns.
While we still believe in providing multiple ways to accomplish something, we now try to encourage one of those ways as an appropriate starting default.
So we think the language scales both down and up to the level of talent of the programmer; the programmer can start out in "baby talk" without getting into too much trouble and then whenever he or she is ready to learn a new concept, the language is ready to support that and to make it easy to refactor the code as the programmer grows in sophistication.
For developers who are already sophisticated, they'll see that most of the problems endemic to the currently available dynamic languages are solved in Perl 6.
We understand lexical and dynamic scoping. We detect most typos at compile time. We don't have a global interpreter lock. We encourage Smalltalk-style trait composition over uncontrolled mixins, multiple inheritance, or monkey patching."
[1] http://www.infoworld.com/article/2882300/perl/perl-creator-l...
JavaScript, for all its blecherous losing horror, had a compelling use case - it ran in browsers. Later, Node became a compelling use case, for dealing with both performance issues and package management problems that plagued other systems (including Rails).
Python had multiple compelling use cases. It became very popular in math programming and teaching, for its clarity and consistency.
Perl's compelling use case was with Perl 4, as a general purpose glue scripting language in a Unix world. It solved tremendous problems. Perl 5 didn't have a compelling case, and it grossly exaggerated the already bad problems with complexity and inconsistency. Am I talking about Perl 5? Yes, because for 22 YEARS, we've been saddled with that crap. Two decades of waiting for Perl 6, for Perl to unfuck itself and become something useful for more than one person at a time. That's like, my entire career. Longer than most programmers in this industry have been in the industry. Longer than some of them have been alive. 22 years.
So why, why, why should I switch? What's the promise now? What problem am I having with Ruby that it can solve?
Ruby's "DSL" ability is what allowed Rails, in Perl 6 everything is a DSL. Even strings are written a customizable DSL. You can turn on and off string features, and add new ones. It goes even deeper than that, you can swap the parser out with a new one mid-parse. One implementing Ruby for example. ( While it is possible to do this today, this isn't specced yet, as the exact way to do this is still in flux to get it to the same quality as the rest of the language ) So in a sense, all programming languages can be thought of as a subset of Perl 6. ( There would be little point in doing this for assembly though, as it will probably have to be emulated in most cases ) This feature is usually only used to slightly alter the existing parser currently.
That isn't even the best part, many features from other high level languages have already been brought together in Perl 6, in a way that makes them seem as if they have always belonged together.
If you asked a random sampling of people about which feature that they like in Perl 6, you will probably get a different one from each.
All good questions. My personal answers boil down to "no need" (to switch), "see the rest of this thread" (to read what promise Perl 6 might have), and perhaps https://docs.perl6.org/language/rb-nutshell (to read how someone familiar with Ruby explains how to map Ruby knowledge on to Perl 6).
So why do it? Mainly, if the framework I'm currently using can't do things I need to do, or if it's incredibly painful to use. To the extent that someone has neither of those problems, a new language is a cure worse than the disease, whatever its benefits.
Look at it this way... imagine there's a rib joint across the street. It may not have the best bbq, but it's there. Do I walk across the street for bbq, or do I drive halfway across town to get slightly better? I'll take what's there, thank you. Now, if I'm a vegan, I'll get up and go somewhere else.
My rule is pretty similar now: Perl or Bash is fine for one-liners or a script which fits in an 80x25 window and doesn't use non-scalar data structures but anything longer or which has much expectation of maintenance is written in something like Python where the culture and tooling favor readability.
Around 2000-2001, I worked on Perl 5 in a close-knit team at a dotcom startup. Even with daily interaction, it was really hard to keep coding standards straight and readability under control. The problem with Perl is that it tends to be a different language for every programmer. Its flexibility leads to arcane code that can only be easily understood by the person who wrote it.
Years later, in different roles, I've worked extensively with both Ruby and Python (I prefer Ruby). I will never, ever, ever go back to Perl for anything more than one line long. I still use Perl for 'perl -e' one-liners in the shell, mostly complex greps. That's it. If I write anything small enough that structure doesn't matter, I use /bin/sh. If I write something large enough that structure matters, I use Ruby.
Why? Because I like to be able to read my code.
Ruby is wonderfully expressive. It can do everything Perl can, and it does it in a much more readable, much more human way.