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
Re: An Apology for Puncish
by BrowserUk (Patriarch) on Jan 27, 2009 at 22:16 UTC
|
| [reply] [Watch: Dir/Any] [d/l] [select] |
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. | [reply] [Watch: Dir/Any] [d/l] [select] |
|
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.
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] |
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.
| [reply] [Watch: Dir/Any] [d/l] |
|
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
| [reply] [Watch: Dir/Any] [d/l] [select] |
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.
| [reply] [Watch: Dir/Any] |
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
| [reply] [Watch: Dir/Any] [d/l] |
|
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
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
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.
| [reply] [Watch: Dir/Any] [d/l] |
|
|