Perl seems like a great language for a lot of text processing jobs, but while its learning curve isn't too steep, it goes on forever. I will continue to use it for quick little projects like cleaning up excel files, but I don't think I could ever get into things like Perl golf.
Numification is important if you output to another language, for instance, with JSON, where the other language will care about a string showing up where a number should have been.
List interpolation is occasionally necessary for syntax reasons, though I don't think of that as an operator, but the composition of its parts.
!! is for if you don't really love the loosey-goosey nature of Perl, and want to have a function that really, truly returns a boolean, and doesn't just return something that may or may not be a value that is either falsy or not. If you think in OO you may not want people coming to depend on the exact falsy value returned, which may expose internals. Generally I just go with the general Perl/scripting language approach, except when I know I'm leaking internals that I really, really don't want people to couple to.
I am not sure I would call this obfuscated. The only real confusing piece of that code is if the reader doesn't know that you can use most punctuation characters with s///g
Well, that's half PHP's problem. The other half is that it had very little coherent design in the beginning, which resulted in idiosyncratic an confusing syntax. It focused on a few things Perl did, while ignoring the important context they were housed within (for one, the whole idea of context as Perl implements it, for another being consistent within your own rules).
Perl, as confusing as it can seem, has fairly consistent rules that it follows. Learning those and keeping them in mind will generally let you intuit how something is expected to work.
you're wrong though: it's not just up to the individual to learn more about the language, it's also up to to every single person who maintains that code afterward! If you learn something, you force your maintainer to learn it.
This is particularly true because many syntax elements are literally impossible to Google. If you didn't happen to learn some idiom (syntax), you just can't deduce or discover what it does, unless a comment precedes it exactly listing the effect.
I would encourage you to check out some of the more recent tools and books on Perl that help greatly in making code readable and maintainable, like the Modern Perl book, the Perl Best Practices book or things like Moose - or even if I dare say, Perl 6.
The Perl Community has come a long way since when I started in 1999, that's for sure. So has the entire Industry, to be quite honest.
Just because you seem to have a C-centric view of the world doesn't mean restricting yourself to C-like syntax and code structure is the "correct" way to do it. At that point, there's no reason to be using Perl over Python. You wouldn't complain that people using Haskell were writing unmaintainable code just because it didn't follow the idioms from C-like procedural languages, would you? Why would you lay the same claims at a Perl? Just because it superficially has some similar syntax and you can restrict yourself to that subset?
Learn the language you are writing code in, and use idiomatic code for that language.
Being able to write "good Perl" doesn't speak to the likelihood of such being created; writing good Perl is an uphill battle at the cost of self-discipline, which is finite.
if nothing else, most of these operators have immense nicknames. Now I just need an excuse to involve a flaming x-wing in my code...
Operator Nickname Function
======================================================
0+ Venus numification
@{[ ]} Babycart list interpolation
!! Bang bang boolean conversion
}{ Eskimo greeting END block for one-liners
~~ Inchworm scalar
~- Inchworm on a stick high-precedence decrement
-~ Inchworm on a stick high-precedence increment
-+- Space station high-precedence numification
=( )= Goatse scalar / list context
=< >=~ Flaming X-Wing match input, assign captures
~~<> Kite a single line of input
<<m=~m>> m ; Ornate double-bladed sword multiline comment
-=! -=!! Flathead conditional decrement
+=! +=!! Phillips conditional increment
x=! x=!! Pozidriv conditional reset to ''
*=! *=!! Torx conditional reset to 0
,=> Winking fat comma non-stringifying fat comma
()x!! Enterprise boolean list squash
0+!! Key to the truth numeric boolean conversion
~~!! Serpent of truth numeric boolean conversion
||() Abbott and Costello remove false scalar from list
//() Leaning Abbott and Costello remove undef from list
When I first learnt perl, twenty years ago, I loved it because it was full of clever devices and syntactic virtuosism. Now, I don't like it anymore exactly for the same reason. It's cool, but the wrong kind of cool.
That's exactly the problem with Perl: cleverness -- especially other people's "cleverness" -- gets to be tedious, if not an outright pain to put up with and maintain, after a while.
It's my own "cleverness" that winds me up the most. I've written a few bits of 5am code that amazingly and finally work though I no longer have any clue how or why o_0
Perl is actually relatively easy to learn and get productive with. You can write it in several transitional styles depending on where you are coming from, and the community doesn't care all that much. It's a little bit like using "Basic English" [1] to program with.
But it's a really deep language, and not necessarily in ways that academic language designers want it to be. Perl always feels more like having a conversation with your computer than programming it. These kinds of operators are like having a whole host of additional highbrow verbs you can use in conversation if you want.
If you are working on a code base with others, it would be cruel to use some of these. However there are operators that could be beneficial to the advanced Perl users.
These do not look like "operators". They look like combinations of Perl operators that produce a "useful" result. I mean they are built from the basic operators.
None of these secret operators are actual operators.
(Some of them aren't even collections of operators - }{ is a form of code injection, and the <<m=~m>> thing has only one operator, applied to a string and a regex.)
Obviously you should never use any of these in a production code base. Perl lets you write very bad, anti-team unreadable code in countless ways. You have to actively avoid these traps designed as neat toys.
0+ - venus - numification: When you really need a scalar value to be represented as a number and not as a string. Useful when you're generating JSON and you need the types to be correct.
@{[ ]} - baby cart - list string interpolation: This is very useful when you need to interpolate arbitrary expressions inside a list. Useful when you're generating an SQL query, for example:
SELECT * FROM Office WHERE id IN (@{[ join(',', ('?') x @ids) ]})
!! - bang bang - boolean conversion: When you want to return a boolean value from a function, but you don't want to leak implementation details.
,=> - winking fat comma - non-stringifying fat comma When you want to create a hash whose keys are constants.
45 comments
[ 4.7 ms ] story [ 94.0 ms ] threadWould this be valid?
$x +=!! =<>=~ s/readable-code//g;
+"123234" +"1e29" +"abc" // -> NaN
List interpolation is occasionally necessary for syntax reasons, though I don't think of that as an operator, but the composition of its parts.
!! is for if you don't really love the loosey-goosey nature of Perl, and want to have a function that really, truly returns a boolean, and doesn't just return something that may or may not be a value that is either falsy or not. If you think in OO you may not want people coming to depend on the exact falsy value returned, which may expose internals. Generally I just go with the general Perl/scripting language approach, except when I know I'm leaking internals that I really, really don't want people to couple to.
The rest are mostly for show.
Perl, as confusing as it can seem, has fairly consistent rules that it follows. Learning those and keeping them in mind will generally let you intuit how something is expected to work.
https://www.google.com/search?q=perl+"baby+talk"
in the real world it's called clean, maintainable code.
You can write Perl that looks like Python, or C, or whatever, but you're missing out on what makes Perl, Perl.
"baby talk" Perl is another name for being able to much with Perl, knowing very little of it. Also known as, "Getting your job done".
It's up to the individual to learn more about the language, which can be done gradually, much like a natural language.
"Clean, maintainable code" in Perl is actually known as, "Modern Perl" [0]
[0] http://modernperlbooks.com/
This is particularly true because many syntax elements are literally impossible to Google. If you didn't happen to learn some idiom (syntax), you just can't deduce or discover what it does, unless a comment precedes it exactly listing the effect.
This is just the nature of Perl.
I would encourage you to check out some of the more recent tools and books on Perl that help greatly in making code readable and maintainable, like the Modern Perl book, the Perl Best Practices book or things like Moose - or even if I dare say, Perl 6.
The Perl Community has come a long way since when I started in 1999, that's for sure. So has the entire Industry, to be quite honest.
Learn the language you are writing code in, and use idiomatic code for that language.
But it's a really deep language, and not necessarily in ways that academic language designers want it to be. Perl always feels more like having a conversation with your computer than programming it. These kinds of operators are like having a whole host of additional highbrow verbs you can use in conversation if you want.
1 - https://simple.wikipedia.org/wiki/Main_Page
I know of C's secret "limit" operator:
int x = 10; while (x --> 0) { printf("%i", x); }
prints 9876543210
Of course, in some ML dialects you can define your own opreators - such as (f |> g) to mean (g o f) which is actually very useful.
(Some of them aren't even collections of operators - }{ is a form of code injection, and the <<m=~m>> thing has only one operator, applied to a string and a regex.)
0+ - venus - numification: When you really need a scalar value to be represented as a number and not as a string. Useful when you're generating JSON and you need the types to be correct.
@{[ ]} - baby cart - list string interpolation: This is very useful when you need to interpolate arbitrary expressions inside a list. Useful when you're generating an SQL query, for example:
!! - bang bang - boolean conversion: When you want to return a boolean value from a function, but you don't want to leak implementation details.,=> - winking fat comma - non-stringifying fat comma When you want to create a hash whose keys are constants.