To be fair it wasn't _just_ that particular thing, that's just the part I remember. There were other things that every time I have to go back to the docs for.
It _is_ a memory competition though. In the various languages I've learned, Perl feels like it has the most to remember about how things work or interact (ymmv of course, I'm speaking of my experience here).
I have to agree with that, it could maybe take an extra work week in the beginning, to get beyond baby language. (But it wasn't as bad as C++ was for me. :-) )
Expressive is the good side of this. But you really need to have coding standards in place.
On this subject, to upgrade to Perl 6 will be a bit scary, like driving a much faster car. :-)
The problem there of course (migrating to Perl 6) is also finding matching packages for the _huge_ list we presently use. I can also only imagine the fallout from various issues like places we may have accidentally used the outcome of a dualvar accidentally, or other interesting side-effects of Perl 5.
6 Looks just fine as a language, but it really does feel like a completely new language which means it's less a migration and more a re-write. Which then leads to the question: if we're going to re-write, should it still be Perl?
Come on, don't exaggerate -- dualvar has to be explicitly imported and used. (I've never seen it in the wild, I have no clue what Perl::Critic says? Edit: pbp has nothing to say about them?)
And I'm not touching the "Perl 6" naming discussion.
There is inlining for using Perl 5 libraries in Perl 6, which smoothen the road. But it is a hard start to motivate projects in a new language, which is incrementally better. I would be happy to try.
Dualvars come up naturally. Treat a number as a string (try using Data::Dumper on some scalars) and suddenly your json ends up coming out like: {"something": "12"} rather than {"something": 12}
Just because both slots are filled with the same "value" in perl, doesn't mean it's _not_ a dualvar. It's just a side-effect of the way scalars in Perl work.
How many times have you actually written a regular expression that matches a bell, versus how many times have you had to explain to people that \a matches a bell while \A matches the beginning of the string (which we know is at least once)?
The discussion was \z contra \Z. I always clear out the new lines and use \Z, so I never bothered.
The ASCII table used to be the alpha and the omega. :-)
That is, it was not so much of unnecessary extra detail when the char codes was inserted into Reg exps. The newfangled Regexps and grammars of Perl 6 cleaned out a lot of lint.
You could probably make an argument for starting to remove, not only add, [more] features when you declare a perl version in a script.
(And personally, I only ever used \n, \r, \t and similar. Everything else is as Cthulhu meant it to be, octal. Regular expressions' problem always was readability, I never used more features than I need and /x is my friend. That said, the "modern" Perl 5 regular expressions are like grammars, really cool.)
1. PCRE copies the Perl regex syntax almost completely (except some much newer cases than \A and \Z). See e.g. http://www.rexegg.com/regex-quickstart.html for \A, \Z, \z
2. If you check http://perldoc.perl.org/perlre.html then:
Edit: You might want to note that the regexps are redone quite extensively in Perl 6 and to a large part replaced with grammar for those use cases.