Perl secret operators and constants | Hacker News Reader

Perl secret operators and constants

search.cpan.org

89 pointsfofoni45 comments

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.

1 - https://simple.wikipedia.org/wiki/Main_Page

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

I once managed to get some obfuscated Perl into an official Red Hat document (as a subtle joke): https://access.redhat.com/documentation/en-US/Red_Hat_Enterp... (search for "simple perl").

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

I write perl everyday, I never use this stuff.

Same here, I didn't even know about most of these, except the list interpolation trick, "@{[ fncall() ]}", which is pretty common where I work.

I use a few of them in javascript. In fact, Venus can be shortened to just "+", ie.

+"123234" +"1e29" +"abc" // -> NaN

In Perl, no, because + is an unary identity operator, used e.g. to properly leave function call parentheses:

  print +(1 + 2) * 3;
  print ((1 + 2) * 3);
  print (1 + 2) * 3;

Me too. Except maybe for goatsee operator sometimes, because it gives you a forced list context, similar to "scalar" builtin.

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.

The rest are mostly for show.

Reading this actually makes me feel like my company has done a good job of outlawing the "write-only" type of perl.

Would this be valid?

$x +=!! =<>=~ s/readable-code//g;

It kind of looks valid to me, yes.

No, for the same reason that $x += = 3 is invalid.

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.

Perl golf is meant as a thought exercise. Code should be human readable. The compiler will cope with verbose code just as easily as terse code.

It's articles like this that give Perl a bad reputation.

Mostly it was all the terrible code that got written in Perl by the first wave of non-programmers to start building web apps.

Then the bad reputation of PHP was the second wave of non-programmers building web apps?

So, same fate as PHP?

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.

it's the existence of this that gives Perl a bad reputation. You can write Perl as though it were Python. In the Perl world that's called "baby talk"

https://www.google.com/search?q=perl+"baby+talk"

in the real world it's called clean, maintainable code.

I think there's a difference between "baby talk" and using Perl as Perl.

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/

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.

This is just the nature of Perl.

> 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.

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.

The ones that I occasionally use:

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.

I wonder how many other languages have well-known secret operators?

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.

That's not an operator, it's just precedence rules.

    while ((x--) > 0)

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.

The second worst code I have had to fix was in Python (sadly the worst was in Perl). Both bioinformaticians.

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.

Interesting, but the title is misleading. They aren't operators, but rather mostly combinations of operators with potentially useful side effects.

Clearly you didn't read the DESCRIPTION section.

A description section doesn't change the fact that the title is misleading. Clickbait is clickbait.

I have been using Perl since 1996, but I only use a handful of the secret operators. For me, the power with Perl is CPAN and the stability of Perl 5.

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.

When I use unusual or difficult language features, or basically anything I expect someone else reading the code won't understand, I leave a comment.

Ah, yes - Perl, the language I have learned many times.

My vote for most over-the-top: The Goatse.

I used !! in many languages including Perl. Not exactly secret and very useful

Reply on news.ycombinator.com