develooper Front page | perl.perl5.porters | Postings from March 2021

Re: Perl feature wish: quote-word array-ref operator

Thread Previous | Thread Next
Felipe Gasper
March 10, 2021 16:12
Re: Perl feature wish: quote-word array-ref operator
Message ID:

> On Mar 10, 2021, at 3:09 AM, Smylers <> wrote:
> Felipe Gasper writes:
>> Perl, for better or for worse, suffers a reputation as being hard to
>> read. In that light, I do think special care is justified when adding
>> additional ways to do everyday tasks like creating an array reference.
> As Eirik said, I think this makes code _easier_ to read. Less
> distracting clutter of multiple nested brackets, or trying to work out
> what each do.

As I wrote earlier, there are wins and losses. Less syntax is a readability win, but having multiple ways to do familiar things is a loss. For example, if I write:

my $foo = [ 1, 2, 3 ];

my %bar = (
    abc => qa/a b c/,
    def => qa/d e f/,

my @baz = qw/ ha ha ha /;

… then someone has to grok both syntaxes for arrayref-literal creation, as well as qw, in order to comprehend the code.

>> qa// will save us relatively-few Perl veterans a few keystrokes here
>> and there. This is “a bit of a win”. It will also complicate things a
>> bit for the (I suspect) relatively-many Perl neophytes out there to
>> grok a veteran’s code.
> There are many levels between those two extremes. A beginner may not
> even use qw at all:
>  my @words_list = ('swa_a_p', 'bonk', 'clash');
>  my $words_list_ref = [@words_list];
> But when they're ready for qw, I don't think they'd find it hard to pick
> up qa at the same time.

My concern is more the task of reading/maintaining.

>> Given that disparity of numbers, IMO the liabilities seem rather a
>> greater loss than the gain we longtimers will realize.
> I'm not sure that [qw/.../] plays that well with beginners either.
> Either you have to think about what each of the levels are doing there
> and compose them in your head (which is more complex than having a
> single construct); or you've internalized the pattern and see it as a
> whole (in which case you can definitely cope with the concept of this as
> a single operation, and cleaner syntax for it would be an advantage).

Consider “if (!$foo)” versus “unless ($foo)”. It’s visually more elegant to have fewer symbols, but that elegance comes at the cost of widening the “vocabulary” required to be conversant with the language.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About