==> Is this a feature that Perl authors are promoting about the language? If so, I can understand why it's not gaining traction. Coding like this benefits absolutely NO ONE--including the one who wrote the code. The hipster coder who's just excited to learn perl for the first time may try it out, just to come back the next day and wonder "what the hell did I write"
This kind of response is as reflexive as it is common; every innovation in programming language notation meets with it immediately. I think it has to be regarded as a middlebrow dismissal, indeed the middlebrow dismissal in its class. It's Tall Poppy Syndrome applied to programming languages: no unfamiliar expressions allowed.
No language makes sense before you learn it. Therefore unfamiliarity should cause us to suspend judgment, not rush to it. Otherwise we end up with what Alan Kay calls pop culture programming, which tragically junks things like the breathtakingly beautiful and powerful APL, and limits us to surface tweaks around the edges.
I studied natural language processing so have used perl a lot in the past. I kind of drifted away since then, but remember that it made me feel cool when I was writing a perl code, but made me feel stupid when reading one--even the ones I wrote--kind of like how regular expression is easy to write but hard to interpret. I think a language needs to be both easy to express and easy to comprehend in order to gain adoption and that's what I was trying to say.
If reading regexes you wrote is a pain point for you, then you're not making as much use of the readability tools Perl provides as you could, i.e. the /x modifier to make unescaped whitespace insignificant, and in-regex comments. ( http://www.perl.com/pub/2004/01/16/regexps.html )
And well, honestly, more often than not i found that "hard to read" perl code would be just as hard to read if it was written in lisp, python, c, or any other language you care to name; since more often than not that code is hard to read due to variables and functions having names that don't help the reader understand what they're holding or doing, and long blocks of code not having been encapsulated into functions well enough.
And lastly, to tie in to dang's point: Having "used Perl a lot" does not mean much if you have not also "learned Perl a lot". I've known, in the extreme, a Perl dev of 10 years experience, who had started out as a C dev, and yet did not use or trust Perl hashes, instead opting to write his own data structure encoding format. Have you ever read chromatic's Modern Perl?
If you watch the presentation, you can see those few slides were just used to add humour to a dry technical presenation. There's a huge number of mathematical symbols and physics notations (not to mention other fields) that could use their native symbols in programs.
You know, it's possible that some programmers are not native English speakers and might want Unicode availability in their entity names... you know... since they might not be using the Western American alphabet, and all that.
==> Is this a feature that Perl authors are promoting about the language? If so, I can understand why it's not gaining traction. Coding like this benefits absolutely NO ONE--including the one who wrote the code. The hipster coder who's just excited to learn perl for the first time may try it out, just to come back the next day and wonder "what the hell did I write"