develooper Front page | perl.perl5.porters | Postings from August 2008

Re: [PATCH] Add open "|-" and open "-|" to perlopentut

From:
Aristotle Pagaltzis
Date:
August 26, 2008 07:50
Subject:
Re: [PATCH] Add open "|-" and open "-|" to perlopentut
Message ID:
20080826145032.GL32015@klangraum.plasmasturm.org
* Tom Christiansen <tchrist@perl.com> [2008-08-25 10:40]:
> Using a double-quote (chr#34, "), no reader will ever wonder
> whether the current font and point size--and unbespectacled
> eyes leaing back--are sure there's looking at a single-quote
> (chr#39, ') or a back-quote (chr#96, `). Everyone has come upon
> this scenario, and either guessed, scratched 'is head, or leant
> forward to peer ever-closer at the ambiguous glyph at 3 in the
> morning.

Would you use a typeface that does not have a slashed or dotted
zero for programming? Then why would you use one that does not
make the quotes properly recognisable? In the words of one
Mr. Dominus, you can’t do good work with bad tools.

* Tom Christiansen <tchrist@perl.com> [2008-08-25 18:55]:
> Lastly, if you start out with single quotes, you'll too often
> have to change the whole thing when you later find yourself
> needing to include some backslashed character or a variable.

This has not been the case for me. In recent memory I have not
had to do this, and while I cannot say how often I may have had
to, in the majority of cases where I find myself having to change
the quoting style of a string literal, by at least one order of
magnitude, it is to turn double quotes into `qq()`.

* Tom Christiansen <tchrist@perl.com> [2008-08-25 10:40]:
> That's why we write
> 
>     @hits = grep { /somepat/ } @targets;
> 
> instead of 
> 
>     @hits = grep(/somepat/, @targets);

False dilemma. I would never ever write the latter, but that does
not mean my only option is the former.

    @hits = grep /somepat/, ( $foo, $bar, $baz );

Isn’t Perl wonderful?

> This is just as occurs if you write:
>
>     lc($heredoc_text) 
>
> The function does not receive the variable's name or address,
> but its contents. That's because this is Perl's nature. In all
> but extremely fridge cases, it makes nary a weaselly whit of
> differnce to write that as 
>
>     lc("$heredoc_text") 

It may not make a difference in the case of `lc`, but the
difference is hardly cosmetic and the cases in which it matters
are hardly just a fringe. If you pass a variable to a function
it receives an alias, not a copy; while most people proceed to
assign this to a freshly declared lexical variable, thereby
attaining copy semantics, Perl’s nature is most decidedly not
to be interpolative in this context.

> If not, then I give you one further scenario whereby the
> obsequious fawning over 'asdf' instead of the more legible and
> more intuitive "asdf" will cause trouble for any beginner, or
> maintainer, or software.
> 
> Consider the humble shell programmer, writing:
> 
>     % echo -n '\t' | wc -c 1 % echo -n "\t" | wc -c 1 
> 
> Or the C programmer writing 
> 
>     putc('\t'); putc('\n');
> 
> vs the one writing 
> 
>     puts("\t");
> 
> gets a chr#9 ("\cI") emitted, plus a newline.
> 
> As you see, both write a single character #9 to stdout,
> followed by a newline. There are not slackbatches slinking
> about.
> 
> And so we have a culture--no, strike that--we have *two*
> cultures, where they are expecting \t, and \n too, to mean a
> single character.

By that argument, you should agree with Damian’s admonition that
one should always use the `/m` modifier on patterns, because that
will make `^` and `$` behave as programmers from other cultures
expect, even though in Perl they behave differently, and a Perl
programmer knows how they do behave in Perl.

So: do you agree?

If not, the obvious question that would arise is what difference
makes this argument valid in one case but not another.

                 --------- * ---------

Now let me return to an earlier part of your argument:

> Consider execution-quotes; that is, the interpolated commands
> provided by grave accent marks.
> 
>     $answer = `cmd $arg1 $arg2`;
> 
> Tell me please: who expands $arg1 and $arg2? It is the shell,
> or is Perl? Of course the answer is Perl. And unlike the shell,
> no amount of funny mixed quoting is quoting to change this. 

This is why I never ever use backticks in my Perl code (which is
another reason why the purported confusion between single quotes
and backticks is completely irrelevant to me). If I want the
output of a command, which is very rare, I use `open` with a
`-|` mode, so that I won’t need to care about whether there
is whitespace or any other shell metacharacter in one of the
arguments. In the almost non-existent case where I actually
do want strings with whitespace parsed into a list, I use
`&Text::ParseWords::shellwords` to do that job myself.

This has little to do with the rarity of these tasks in my work.
If I needed them often, I would wrap the work up in a function
with a short name.

> I have also shown that that in turning by default to
> suppressive quoting, one must do continual battle, swimming
> upstream as it were, against Perl's fundamental, underlying
> interpolative nature, a leitmotiv that courses through Perl
> again and again and again.
> 
> To battle against that nature is not only more bother than
> sense, it also risks causing needless, irritating, and perhaps
> even dangerous confusion amongst writers and maintainers fr
> Perl code.
> 
> So I needs must ask: *why* are you fighting Perl? Cui bono?

Let me quote Dan Bernstein[1]:

    I have discovered that there are two types of command
    interfaces in the world of computing: good interfaces and
    user interfaces.

    The essence of user interfaces is *parsing*: converting
    an unstructured sequence of commands, in a format usually
    determined more by psychology than by solid engineering,
    into structured data.

    When another programmer wants to talk to a user interface,
    he has to *quote*: convert his structured data into an
    unstructured sequence of commands that the parser will,
    he hopes, convert back into the original structured data.

    This situation is a recipe for disaster.

[1]: http://cr.yp.to/qmail/guarantee.html

And so I always prefer to keep data in a structured form for as
long as possible, and to convert it to a structured form as soon
as possible and in as few separate stages as possible.

If to do so is to go against Perl’s nature, may Perl forgive me,
but it has yet to let me notice any reluctance to host me; for
all of my mistreatment, it has tolerated me so well that I have
no possible complaint to register against its hospitality.

Thank you, Perl.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About