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!?

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.

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.

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

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.

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. ;)

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."