Secret Perl Operators(catonmat.net)
catonmat.net
Secret Perl Operators
http://www.catonmat.net/blog/secret-perl-operators/
5 comments
Thanks for the comments. I fixed the wording mistake of 3.99 being an integer. You are right about everything you say. @{[]}, <=>, and =()= are acceptable in production code, but the others are not. These other "operators" actually were invented to chop off characters in Perl Golf competitions. This article wasn't meant as "good Perl coding tips and tricks", it was more written for fun.
}{ Useful for one-liners, but has no use in production code.
What about production one-liners? Let us not underestimate the power of a well-applied one-liner.
What about production one-liners? Let us not underestimate the power of a well-applied one-liner.
I wouldn't underestimate the power of a one-liner.
That's why I'd avoid using one!
With great power comes great responsibility - and it's hard to cram the responsibility part into one line as contrasted with a clear, well-behaved subroutine.
That's why I'd avoid using one!
With great power comes great responsibility - and it's hard to cram the responsibility part into one line as contrasted with a clear, well-behaved subroutine.
Well said!
I think this is tongue in cheek. Just re-read:
Compare these two examples:
print "these people @{[get_names()]} get promoted"
and
print "these people ", join " ",get_names(), " get promoted"
Clearly, the first example wins for code clarity.
Compare these two examples:
print "these people @{[get_names()]} get promoted"
and
print "these people ", join " ",get_names(), " get promoted"
Clearly, the first example wins for code clarity.
I tend to prefer using ${\...} for interpolation - so
Oh, and remember - sometimes makefiles that do useful things to and with production code should contain one liners.
Don't assume that the intersection of "one liner" and "production" is zero - when I ran the Web Server Survey at Netcraft about 3/4 of it was one liners driven by make ...
print "${\join ',', @array}";
Oh, and remember - sometimes makefiles that do useful things to and with production code should contain one liners.
Don't assume that the intersection of "one liner" and "production" is zero - when I ran the Web Server Survey at Netcraft about 3/4 of it was one liners driven by make ...
Oh Perl, will you never stop being a source of witty fun?
It's official, Haskell's boob combinator, (.) . (.), has competition. From the Goatse operator.
Alternate title: "8 Reasons Not to Use Perl". Why do people who use Perl get such a kick out of junk like this.
Perl is designed around linguistic concepts. You may as well ask "why do people who use language get such a kick out of junk like this:poetry, rhymes, prose, novels, etc.?"
I don't think it is but to go along with the metaphor, those things you list are methods of conveying stories and emotions. A programming language is a method for conveying instructions to a machine. Theses would be 8 reasons not to use any human<->machine language. The Perl biosphere just seems to produce non-sense like this as a matter of routine. To me posts like this are about on par with pictures of cats.
I don't know why you got downvoted so hard, I think you have a fair opinion (even though I disagree with it).
IMHO, the absolute best programmers I've ever worked with looked at programming as a game, as something clever to do. They reveled in the beauty of elegant code, and they got angry when reading bad code, and laughed heartily at particularly clever code etc.
To them, they had internalized the language of the machine and were trying to create art with their code, not science.
One thing that I've never been unsure of is that L. Wall understands that machines can be approached 2 ways, either as a raw tool, issuing instructions to be completed precisely as directed. Or the other approach, which is to think of the machine as a being (albeit one with a particularly different kind of mind) and the language is a lingua franca that you can use to communicate with it. Perl false squarely on the side of a programming language being a language (in the communication sense) vs. being a language (in the "set of instructions" sense).
The reason Perl 1 liners are so interesting, for example, is that they convey implicit little secrets between you and the machine, much like you might do with a certain kind of nod to a friend at a party when a certain topic comes up that conveys a world of meaning between you and your friend.
The reason these little "operators" are so witty is that they convey lots of meaning between you and the machine relatively simply, and look clever at the same time.
I think most programmers at one time or another realize that though, in theory, computers are supposed to do exactly what you've told them to do, the ecosystem their software is running in is just on the edge of nondeterminism and wish for a way to convey to the computer what they "mean" for it to do rather than what they tell it to do. "Machine, I wish for you to open this file and count the number of times the words foo and bar show up in it". Perl is targeted at these kinds of cases.
That's now to say that other languages are bad, just different. Perl also has the unnerving ability to so quickly become obfuscated that it can be very hard to untangle by another developer. Languages like Python aim for code simplicity and readability and thus are much more suitable to large scale development practices than Perl is (that's not to say that Perl isn't used in these kinds of large projects, or that Python isn't used for one off scripts).
IMHO, the absolute best programmers I've ever worked with looked at programming as a game, as something clever to do. They reveled in the beauty of elegant code, and they got angry when reading bad code, and laughed heartily at particularly clever code etc.
To them, they had internalized the language of the machine and were trying to create art with their code, not science.
One thing that I've never been unsure of is that L. Wall understands that machines can be approached 2 ways, either as a raw tool, issuing instructions to be completed precisely as directed. Or the other approach, which is to think of the machine as a being (albeit one with a particularly different kind of mind) and the language is a lingua franca that you can use to communicate with it. Perl false squarely on the side of a programming language being a language (in the communication sense) vs. being a language (in the "set of instructions" sense).
The reason Perl 1 liners are so interesting, for example, is that they convey implicit little secrets between you and the machine, much like you might do with a certain kind of nod to a friend at a party when a certain topic comes up that conveys a world of meaning between you and your friend.
The reason these little "operators" are so witty is that they convey lots of meaning between you and the machine relatively simply, and look clever at the same time.
I think most programmers at one time or another realize that though, in theory, computers are supposed to do exactly what you've told them to do, the ecosystem their software is running in is just on the edge of nondeterminism and wish for a way to convey to the computer what they "mean" for it to do rather than what they tell it to do. "Machine, I wish for you to open this file and count the number of times the words foo and bar show up in it". Perl is targeted at these kinds of cases.
That's now to say that other languages are bad, just different. Perl also has the unnerving ability to so quickly become obfuscated that it can be very hard to untangle by another developer. Languages like Python aim for code simplicity and readability and thus are much more suitable to large scale development practices than Perl is (that's not to say that Perl isn't used in these kinds of large projects, or that Python isn't used for one off scripts).
> A programming language is a method for conveying instructions to a machine.
The preface of SICP disagrees (see http://mitpress.mit.edu/sicp/front/node3.html ), with a quote many, many programmers can quote in spirit if not to the letter.
The preface of SICP disagrees (see http://mitpress.mit.edu/sicp/front/node3.html ), with a quote many, many programmers can quote in spirit if not to the letter.
These operators sound even worse for people to read; perhaps that's why they're obscure.
I've read Larry Wall on the natural evolution of human and computer languages but I don't think anyone can demonstrate that Perl is the product of a clear, informed linguistic process that makes it superior to, say, Ruby or Python.
And further, there's a reason that legal contracts normally avoid limericks (feel free to insert the obligatory "counter-example").
And further, there's a reason that legal contracts normally avoid limericks (feel free to insert the obligatory "counter-example").
I think your concept of programming is far to restricted if all you can compare it to is legal documents.
sad face
I grew up in this environment http://demoscene.tv/
and quite often saw programmers taking very creative and artistic approaches to their code. They saw programming as art and wanted to express their art this way.
Is this applicable in a modern, large scale, corporate environment? Probably not, but just as it wouldn't be appropriate for me to fill out all of my TPS reports with oil paints it doesn't mean that oil painting doesn't have a place.
sad face
I grew up in this environment http://demoscene.tv/
and quite often saw programmers taking very creative and artistic approaches to their code. They saw programming as art and wanted to express their art this way.
Is this applicable in a modern, large scale, corporate environment? Probably not, but just as it wouldn't be appropriate for me to fill out all of my TPS reports with oil paints it doesn't mean that oil painting doesn't have a place.
err:to=too
>>there's a reason that legal contracts normally avoid limericks
Afaik, lawyers also play with language to learn to use it. It might be hard to believe, but I have heard (3rd hand) claims some lawyers and programmers even read a bit of poetry...
But I've never seen that used as an argument against them -- except by language war trolls...
Afaik, lawyers also play with language to learn to use it. It might be hard to believe, but I have heard (3rd hand) claims some lawyers and programmers even read a bit of poetry...
But I've never seen that used as an argument against them -- except by language war trolls...
People with brains tend to be rather playful.
Creative people tend to be playful with their tools (see the origins of many styles of visual arts and music).
Please let me know when you find a language that doesn't have "8 reasons not to use it". I will switch immediately.
In which case, I'd claim that
http://www-users.cs.york.ac.uk/susan/joke/unix.htm
must be a lot more than eight reasons not to use UNIX?
Really. We get a kick out of it because it's fun.
I don't understand why people consider a bit of light humour junk; maybe it just means they don't get the joke - but I often wonder if it more means that they take programming too seriously.
I enjoy my job. I enjoy jokes related to my tools. I'm really sorry you don't.
http://www-users.cs.york.ac.uk/susan/joke/unix.htm
must be a lot more than eight reasons not to use UNIX?
Really. We get a kick out of it because it's fun.
I don't understand why people consider a bit of light humour junk; maybe it just means they don't get the joke - but I often wonder if it more means that they take programming too seriously.
I enjoy my job. I enjoy jokes related to my tools. I'm really sorry you don't.
Not the same. No one is going to read that and then try to use those in their work. I suspect people have read this article and thought "dam those might come in handy, let me bookmark that."
Possibly because all people are not you. Life is more interesting that way.
>> Why do people who use Perl get such a kick out of junk like this.
Alternative question from the last half dozen times I've seen Perl mentioned in a good light on HN:
Why do Python/Ruby/X people get such a kick out of language wars?
It was well formulated here: http://news.ycombinator.com/item?id=963706
Alternative question from the last half dozen times I've seen Perl mentioned in a good light on HN:
Why do Python/Ruby/X people get such a kick out of language wars?
It was well formulated here: http://news.ycombinator.com/item?id=963706
It's a cultural thing. Python people value doing complicated things with simple code. Perl people value doing simple things with obscure language features, then basking in the glow of being called a "wizard".
In other words, every other language community cares more about what you do than how you do it.
In other words, every other language community cares more about what you do than how you do it.
Totally untrue.
Personally, I never use any of these constructs. I never see them in any modules I use. None of my friends use these. (And trust me, if you know Perl, you know my friends.) The only place I see them is during conference talks about "strange things that happen to be possible with Perl syntax".
Do I know what they do? Yes. Would I freak out if I saw them in someone's code? No. Would I add them to my own code when a clearer construct would suffice? Never.
Just because you would never use these constructs in Real Code doesn't mean that this is not something that's fun to think about. Are you a code monkey, or can you step back from the "must implement maintainable application in 42 hours OR DIE" and enjoy the art of programming?
Personally, I never use any of these constructs. I never see them in any modules I use. None of my friends use these. (And trust me, if you know Perl, you know my friends.) The only place I see them is during conference talks about "strange things that happen to be possible with Perl syntax".
Do I know what they do? Yes. Would I freak out if I saw them in someone's code? No. Would I add them to my own code when a clearer construct would suffice? Never.
Just because you would never use these constructs in Real Code doesn't mean that this is not something that's fun to think about. Are you a code monkey, or can you step back from the "must implement maintainable application in 42 hours OR DIE" and enjoy the art of programming?
If these things are almost never used or should never be used, why are they allowed to exist?
For the most part, they don't exist! Only the <=> operator in that list actually exists. The rest are combinations of perfectly sensible operators.
"Why does Haskell have (.) . (.)?" It doesn't. It's just a combination of legal characters that happens to also be a joke.
(And as wacky as <=> may appear, in the context of Perl, with its separate string vs. numeric comparison operators, it's not even that strange. It is a combination less than, equal, or greater than operator. "cmp" is the equivalent for strings.)
"Why does Haskell have (.) . (.)?" It doesn't. It's just a combination of legal characters that happens to also be a joke.
(And as wacky as <=> may appear, in the context of Perl, with its separate string vs. numeric comparison operators, it's not even that strange. It is a combination less than, equal, or greater than operator. "cmp" is the equivalent for strings.)
TMTOWTDI (http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_...)
Such freedom is at the core of the language.
Such freedom is at the core of the language.
The question was:
Why do Python/Ruby/X people get such a kick out of language wars?
Your response was:
Python people value doing complicated things with simple code. Perl people value doing simple things with obscure language features, then basking in the glow of being called a "wizard".
Methinks there's a disconnect somewhere here.
Why do Python/Ruby/X people get such a kick out of language wars?
Your response was:
Python people value doing complicated things with simple code. Perl people value doing simple things with obscure language features, then basking in the glow of being called a "wizard".
Methinks there's a disconnect somewhere here.
It's merely an observation. See how many times the word "wizard" appears in the Perl documentation. Then try the same in, well, any other language.
There's no war to fight. Perl has its place. I might even use Perl again if I need a throwaway 10-liner.
There's no war to fight. Perl has its place. I might even use Perl again if I need a throwaway 10-liner.
Perl has "wizards" Ruby has "rockstars" and so on.
They are all irrelevant monikers.
Use whatever works for YOU. Taking the conversation any further is as pointless as any other religious war discussion.
They are all irrelevant monikers.
Use whatever works for YOU. Taking the conversation any further is as pointless as any other religious war discussion.
Indeed. Perl has many sub-communities. Some "wizards" enjoy obscure syntax. Other people enjoy figuring out new ways to make reusing code easier. Some other other people enjoy talking about testing. Some people do all three. etc., etc.
Basically, "Perl" is a very large community, and different people in the community use Perl for different things. Some just want to have fun and others have real engineering problems to solve and are solving them with Perl. Perl is welcoming to everyone. It's a shame that people think the playful applications of Perl make it unsuitable for real work.
Basically, "Perl" is a very large community, and different people in the community use Perl for different things. Some just want to have fun and others have real engineering problems to solve and are solving them with Perl. Perl is welcoming to everyone. It's a shame that people think the playful applications of Perl make it unsuitable for real work.
UNIX has "wizards" too - and perl's origins as a super-awk place it firmly in the UNIX cultural tradition in a lot of ways.
I write more perl than anything else but I work in shell, make, perl and C regularly depending on what level I'm trying to work at (and often think in lisp for prototyping).
UNIX is my IDE. perl5 is my VM. CPAN is my language.
I write more perl than anything else but I work in shell, make, perl and C regularly depending on what level I'm trying to work at (and often think in lisp for prototyping).
UNIX is my IDE. perl5 is my VM. CPAN is my language.
No. Sorry. You're confusing the old perl4 culture with modern/enlightened perl culture.
We value doing complicated things elegantly so that the program so produced best reflects the intent of the programmer. So yes, that's caring about how you do it.
We care about "how you do it" because expressivity brings readability and maintainability.
The key difference is that python optimises for having one common idiom for a given thing and achieving expressivity through the way these idioms are structured together. Perl tends to have multiple idioms for a given thing and achieve expressivity through which one is used for a given reason.
See http://shadowcat.co.uk/blog/matt-s-trout/pizza-snakes-bicycl... for a longer but hopefully better attempt at explaining what I mean.
We value doing complicated things elegantly so that the program so produced best reflects the intent of the programmer. So yes, that's caring about how you do it.
We care about "how you do it" because expressivity brings readability and maintainability.
The key difference is that python optimises for having one common idiom for a given thing and achieving expressivity through the way these idioms are structured together. Perl tends to have multiple idioms for a given thing and achieve expressivity through which one is used for a given reason.
See http://shadowcat.co.uk/blog/matt-s-trout/pizza-snakes-bicycl... for a longer but hopefully better attempt at explaining what I mean.
Yes. But you forgot to mention that, "People who need to get Real Work(tm) done use $my_favorite_language."
}{ Useful for one-liners, but has no use in production code.
=()= In production code, I'd prefer to see the match results assigned to a named array, and the array used in a scalar context to get the length. Alternatively, I'd accept a comment explaining why there is an assignment to an anonymous array. It had better not call =()= an operator, though.
~~ You can force scalar context using the scalar keyword, which is much clearer.
~- You can type $x-1, which is much clearer and works for numbers <= 0 too.
-+- I didn't know "3.99" was an integer... in any case, would probably use printf or sprintf for formatting numbers for display, using explicit formats rather than relying on whatever -+- spits out.
0+ Again, I would use printf or sprintf in most cases where 0+ might be used.