Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

An Apology for Puncish

by rir (Vicar)
on Jan 27, 2009 at 20:17 UTC ( [id://739330]=perlmeditation: print w/replies, xml ) Need Help??

When I first encountered the idea, presented in Conway's Perl Best Practices, that use English be a best practice, I just thought it another of theDamien's attempts to enable novice Perlers. Many of those practices might rankle a more experienced Perler, but I see the sense of them and only fault the idea if it creates a bar to advancing the skill of the crew.

I don't see using a different name for something as a loss or gain of skill. I scarcely ever mentally verbalize $_ and such, so having a precise and formal name in front of me would seem to be an asset.

But the use English practice continued to seem artificial to me and I could not formulate a reason. What made it curious is that I don't use puncish variables much--it was a small issue: why do I resist using English? but it persisted.

I'm pretty comfortable around these: @_, $_, $/, $., $|, $/, $0, $@, and $,. And I think I'd usually recognize: $`, $', $!, $$, $\, and $^O. There will need to be powerful contextual hints for me to know, on sight, most of the others.

Well, I eventually clued to why puncish is beautiful. And it was all about how puncish vars help a coder who is not well versed with them. When I read $LIST_SEPARATOR, I may be confused as to its derivation; perhaps there is some parsing or data packing happening in user code. When I see the equivalent $", I will know that perldoc perlvar has the definition. The beauty of puncish variables is in the ease with which they can be recognized as perlvars. There is an elegance to the namespace. When I do need to know what $< is, I'll know right where to look.

Be well,
rir

Replies are listed 'Best First'.
Re: An Apology for Puncish
by BrowserUk (Patriarch) on Jan 27, 2009 at 22:16 UTC
    The beauty of puncish variables is in the ease with which they can be recognized as perlvars. There is an elegance to the namespace.

    I absolutely agree.

    I've two counter arguments to the use English; justifictions:

    1. Pick up any technical document, be it a music score; mathematical thesis; engineering drawing; medical report; chemical analysis or other scientific paper; legal treatise; or computer program. They all contain specialist nomenclature: abbreviations, symbols, overloaded terms and jargon specific to the field.

      And they all do it for the same good reasons. Perhaps primary of these is that it simpler and more efficient for those familar with the field.

    2. If use English; is a good idea, then we should also have use French;, use German;, use Italian;, use Spanish;, use Chinese;...

      And what about use Cockney;, use Scouser;, use Geordie; & use Glaswegian;?

      Maybe we need something along the lines of use Dialect qw/ ... /;. Isn't that going to make code much clearer!?


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: An Apology for Puncish
by moritz (Cardinal) on Jan 27, 2009 at 20:36 UTC
    The "specially named" variables are good case of "huffman coding", ie commonly used constructs should have short names.

    To exaggerate a bit: if I wanted to type $INPUT_RECORD_SEPARATOR instead of $/ (or System.out.println instead of say), I'd code in Java instead of Perl.

    More to the point: making things practical to use has always been one of Perl's philosophies - and long names simply aren't practical.

      I'd disagree that these are generally 'commonly used constructs', with the exceptions of $_, $!, and $@. Most of them seem to only be needed once in a blue moon, in fact.

      I agree with your logic otherwise, just not with the specific premise that these are the commonly used values.

        I think many of these short variable names were chosen to deal with the limits of interpreters on 1960s-ish machines. At that time, some of the principles underlying Huffman encoding were in play.

        Perl just adopted many of these names as part of its mission. That Larry Wall chose to preserve the distinctive nature of this namespace and keep its expansion out of the spaces that would be commonly chosen for user tasks seems to me to be one of the insightful decisions in Perl's design. That it continues with ${^Word} style names is good.

        Be well,
        rir

        Update: very minor language cleanup

        Update: reworked poor sentence: the struck out stuff. You can't expand an ad hoc namespace because you're creating a new one. The underlined text replaces: add most of his other predefined variables into a namespace that ... words are failing me a bit, but he kept the namespace distinctive and

        "Commonly used" depends very much on what programs you write. I write one-liners very often that extract one or two columns of data from somewhere, so I do use $0 very often, probably more often then explicit $_.

        I'm sure that's different if you spend most time on highly engineered OO programs or other areas.

        I think it depends on what you mean by "used." Many of them are used in the background constantly. $. and $/ (at least?) are implicit in every file read, for example.

Re: An Apology for Puncish
by Erez (Priest) on Jan 28, 2009 at 08:58 UTC

    The concept of the default variables is not without its linguistic roots.
    Consider this sentence "Jack stood when Jill entered," and "he did it because she was tired".
    This makes perfect sense, to anyone with fair reading skills. If you just started on reading, and are not familiar with the idea of context; or, if your overall reading comprehension skills aren't that good, you might need to explicitly read it as "Jack stood up when Jill entered, Jack stood up because Jill looked tired when she entered."

    Now, if the second part of the sentence appeared 3 or 4 paragraphs later, there would be a need to use the explicit version of it, rather than the pronouns one.
    In this sense, if the nature of the special variable is important to the understanding of the code, use English is a good practice. In the same way that naming your iteration variable is, at times, a good practice. Otherwise, feel free to be punc'd.

    "A core tenant of the greater Perl philosophy is to trust that the developer knows enough to solve the problem" - Jay Shirley, A case for Catalyst.

      Erez, I guess I agree with the first part of your post regarding "default variables" having a correlation to or derivation from pronouns. That is the standard wisdom and I have accepted it without much thought; the etymology of $_ has never seemed important enough to question. I would say that is just a fact that I collected. Whether it really is a fact, I don't know.

      The point I was making had nothing to do with default variables or pronoun-like tokens needing nearby antecedents. Nearby antecedents in language correlate to not acting at a distance in programming; these seem very different somehow.

      $_ is the accumulator of Perl; an ordinary pronoun needs an antecedent while $_ more often needs local-ization to break it away from its prior value. Between the two, the confusion we might get feels very similiar, but the mentation we should apply is inverted in some way.

      Be well
      rir

Re: An Apology for Puncish
by Mutant (Priest) on Jan 29, 2009 at 23:26 UTC

    Agree 100%. If I'm scanning some code, and I see $LIST_SEPARATOR, unless I've memorised everything in 'use English', I might not realise that it's from there. I might think it's a global constant defined somewhere else (and I've had to work with code that defines globals all over the place).

    If I see a punctuation variable, I know immediately that it's a special Perl variable. For better or worse (and often worse) Perl has many of these, and I could only name a handful, because I barely use them myself. But that doesn't mean others don't use them, and I might have to maintain (or just read) their code. I'd much rather they used the punctuation versions - it helps reading for me immensely.

    Kind of ironic in a way, because this is just the sort of thing that people outside of Perl claim makes Perl code so unreadable.

Re: An Apology for Puncish
by talexb (Chancellor) on Jan 28, 2009 at 18:03 UTC

    Another way of putting it is that Perl defaults to an 'Expert' mode, but you can dial that back a little using English to make things a little more readable. But BrowserUK has nailed it with the comment that abbreviations are commonly used in a variety of fields -- music is an excellent example of that; it's why I know so many Italian adverbs. ;)

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      That is saying something completely different. My contention is that to the uninformed
      • @+ and $LAST_MATCH_END
      • $? and $CHILD_ERROR
      • $^C and $COMPILING
      • $^T and $BASETIME
      • $^I and $INPLACE_EDIT
      • $" and $LIST_SEPARATOR
      are all obscure. If you don't know that Perl has a list separator concept, the name $LIST_SEPARATOR leaves you to look everywhere for its meaning. I would not know $^I's meaning, but by understanding the naming convention, I know it is a token defined in perlvar; in some cases that may be enough to guess/remember its meaning because I don't need to consider concepts that come from the
      • problem, -- is $LIST_SEPARATOR part of user output
      • general programming, -- or is it about a data structure
      • host system, -- or is it about porting
      • or a specialty domain. -- or a bit of arcana from some lib

      Be well
      rir

        If you don't know that Perl has a list separator concept, the name $LIST_SEPARATOR leaves you to look everywhere for its meaning.

        It's actually worse than that, because of what I referred to above as 'term overloading'. For example, Haskell has the concept of 'list separator', but the new book takes great care to point out that:

        Commas are separators, not terminators

        Some languages permit the last element in a list to be followed by an optional trailing comma before a closing bracket, but Haskell doesn't allow this.

        It's a minor example, but shows that by using the english versions it may induce assumed understanding in the reader due to term overloaading.

        The symbolic versions do not suffer from this. Someone encountering $" for the first time will not make the same assumptions and will have to look it up in the documentation. Which is a Good Thing.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://739330]
Approved by kyle
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (4)
As of 2024-03-19 04:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found