Ovid

We've been using subroutine signatures for a while at $WORK and it's a huge improvement. I really wish I could use them with my CPAN code too.

I use $" a lot. Writing it using join is just awkward. Sure, in your simple example, it doesn't make much of a difference. But it does for:

my $query = do {local $" = ", "; <<"--"};
    SELECT  foo, bar, baz
      FROM  SomeTable
     WHERE  id IN @{[("?") x @ids]}
--

It all depends on what you are used to. When I started learning Perl, I thought the use of ‘and’ and ‘or’ for control flow to be confusing. Now I’m used to it. Would you really suggest that one avoid those so as not to confuse new devs? I’m sure your answer is no. But where do you draw the line? That’s what nobody agrees on.

FWIW, if you don't want to create another lexical, you can still use @{[ ]} with a join inside there, no?

my $query = <<"END_SQL";
    SELECT  foo, bar, baz
      FROM  SomeTable
     WHERE  id IN @{[ join ', ' => ('?') x @ids ]}
END_SQL

Also, in Perl 6 there's a .join method of which the delimiter parameter is optional.

say @array[2,4].join;

You got a semicolon in there that should be a comma.

What's @. ? I can't find it in perlvar.

my $query = <<"";
    SELECT foo, bar, baz
      FROM sometable
     WHERE id IN (${\ substr ',?' x @ids, 1 })

What? Oh, we weren’t golfing?

More seriously, global variables bad, because action at a distance bad, and to the extent that Abigail’s version of the code is less readable than other formulations I find it’s mostly owing to the distance between setting the punctuation variable and the effect that that assignment has.

There's at least one valid use of $" that can't be replaced with join:

my @regexes = list_of_qr_objects();
my $combined = do { local $" = '|'; qr/@regexes/ };

If any of the regex objects contain (?{ }) or (??{ }) constructs, using join would decompile and reparse the code. That in turn would require use re 'eval' in scope for the final qr, and even then it would break the use of any lexical variables that those code blocks might close over.

However, qr/@regexes/ uses the compiled form of each of the @regexes directly, including the ordinary Perl code inside their code blocks, so this works fine.

Of course, this doesn't provide a direct argument either way about whether it's good to reach for punctuation variables by default, but I think it's interesting regardless, as well as an occasionally useful technique.

This is one of the few examples where i know an even better trick, at least as long as you are using DBD::Pg

my $query = <<"END_SQL";
    SELECT  foo, bar, baz
      FROM  SomeTable
    WHERE  id = ANY(?)
END_SQL

And then pass an array reference as the value. \o/

I'm with Ovid. I love that perl will let me do very concise things and has all these features, but they should be used appropriately. Invoking perl with -e on the command line to do some one-off task is often only really possible this way, and knocking up a quick helper utility for something is much quicker and easier with these features.

But Abigail's example wouldn't make it past review onto a production server. I'm on a multi-decade project and there's an inevitable turnover of staff so maintainability of code is critical; moreso even than having it work properly (maintainable but faulty code is fixable; working but unmaintainable code that needs updating is useless). Other people who are new to my code (and that really includes me more than a couple of weeks after writing it :/ ) must be able to maintain it as easily as possible. It is increasingly difficult to find experienced perl devs and much of the resistance from others comes from all that "perl is line-noise" nonsense. I think it behooves us to write perl that is not line-noise, and is as far from it as is reasonable.

*frowns at Liz* :)

I applaud this article and others like it. At $work we are constantly fighting bugs in code that is "too clever" and not explicit. Also fascinating to see what may seem obvious to some (e.g. the Babycart operator) but quite confusing to newbies.