4 ms·

I don't think you should place too much emphasis/concern/whatever on most of the special variables available in Perl 5. I would wager that most Perl programmer

by nocman 7y ago

I don't think you should place too much emphasis/concern/whatever on most of the special variables available in Perl 5. I would wager that most Perl programmers never use about 95% of them (that is, the short 2-3 character ones listed on that man page). At the very least, I would guess, most Perl programmers almost never use 95% of them -- and many would choose (as the perlvar man page says) to 'use English;' -- and thus use the readable version. An example would be using $LIST_SEPARATOR instead of $" (which is what I would do). I write Perl 5 code frequently, and that man page is chock full of short variable names I never use.

Grinnz 7y ago
In practice (from a rough survey of CPAN code and Perl code in the wild I've looked at), people rarely use the English versions, and tend to memorize the few punctuation variables that are commonly used: $_, @_, $/, $], $$, $@, $!, $? (and note that some of these are out of familiarity with other languages) and ignore the rest unless needed for a specific problem.
- nocman 7y ago
  This is probably accurate. I personally use this subset all of the time (for reasons that will be obvious to Perl programmers): $_, @_, $@, $!, $? I have occasion to use $$, but not too often. I tend not to use much else, and like others have said in this thread, I just look up things that I need when I need them. If it is not obvious what something does (especially if it is one of these special variables), I will add a comment to explain (as I would in any programming language I use). I understand why people don't like this particular characteristic of Perl, and it is a legitimate thing to have differing tastes. But I don't personally find it to be anywhere near as "end of the world" awful as many people who can't stand Perl make it out to be.
DonHopkins 7y ago
Yet you have to know both versions of them all, and be able to recognize and understand both kinds when reading other people's code. How does it improve the language to be so top-heavy and chock-full of obscure unreadable arbitrary syntax, 95% of which nobody every uses, but that everyone still needs to memorize and understand in order to read? That's exactly why Perl's philosophy of TMTOWTDI is intellectually bankrupt, and encourages write-only "creative snowflake" Perl code that's an inscrutable, unreadable, unmaintainable nightmare. The language isn't any better for having $" as a shortcut for $LIST_SEPARATOR (or $LIST_SEPARATOR as a mnemonic for $", depending on how you look at it), because now you have to learn twice as many things, and all that duplicated effort and mental stress and syntactic surface area doesn't make it any more powerful or easy to use, has absolutely no tangible benefits, only pointless costs, and makes it twice as hard to learn and read and maintain Perl code.
- Grinnz 7y ago
  Memorizing everything is not required, there is reference documentation. Learning the language would familiarize you with the important syntax, as with any language, and all languages have such oddities, they just appear in different forms.
  - DonHopkins 7y ago
    No, all languages do not have such oddities. That's a false equivalence. And it doesn't excuse Perl's bad design or justify its intellectually bankrupt TMTOWTDI philosophy. Python's philosophy of "There should be one — and preferably only one — obvious way to do it" is diametrically opposed to TMTOWTDI, and Python's vastly more successful than Perl because it's much easier to learn, read, use and maintain. Can you name any schools teaching Perl as a first programming language, like so many teach Python? Forcing you to look punctuation up in the reference documentation is even worse than having to memorize it. Pausing from reading code to look up punctuation in the manual slows you down by orders of magnitude, and knocks you out of the flow. Random punctuation is not easily memorizable or mnemonic or searchable or indexable. You also have to have memorized the ASCII order of punctuation to index through the manual, which is different than how punctuation is arranged on the keyboard! Is a comma or underscore less than or greater than a double quote or back quote, and why should I care? How exactly do double quotes imply "LIST_SEPARATOR"? Shouldn't it be $, because comma is the standard list separator, instead of $" which looks like it could be "STRING_DELIMITER", or does $, mean something completely different? And how am I supposed to remember all that? It's totally arbitrary, annoying, and off-putting. Now tell me how Perl is any more powerful by having twice the number of ways necessary to express the every concept? Perl pointlessly has twice as many inane pieces of syntax to memorize or look up, to do the same number of things. There is no upside to that, only cost. And that's one reason Perl is dead.
    - cestith 7y ago
      $, is the output field separator, which in short or English form is very rarely used. Generally people explicitly determine what they want on output with something like sprintf(), printf(), or join() rather than sending a list to print(). Just like a natural language, there's a tiny pidgin subset you can learn and use to great effect. You then learn obscure vocabulary on the rare occasion you come across it. If you have had to maintain code by people who intentionally obfuscate it, you should be at least as angry with those people as with the designers of their tools.

by nocman 7y ago

Grinnz 7y ago

In practice (from a rough survey of CPAN code and Perl code in the wild I've looked at), people rarely use the English versions, and tend to memorize the few punctuation variables that are commonly used: $_, @_, $/, $], $$, $@, $!, $? (and note that some of these are out of familiarity with other languages) and ignore the rest unless needed for a specific problem.

nocman 7y ago
This is probably accurate. I personally use this subset all of the time (for reasons that will be obvious to Perl programmers): $_, @_, $@, $!, $? I have occasion to use $$, but not too often. I tend not to use much else, and like others have said in this thread, I just look up things that I need when I need them. If it is not obvious what something does (especially if it is one of these special variables), I will add a comment to explain (as I would in any programming language I use). I understand why people don't like this particular characteristic of Perl, and it is a legitimate thing to have differing tastes. But I don't personally find it to be anywhere near as "end of the world" awful as many people who can't stand Perl make it out to be.

DonHopkins 7y ago

Yet you have to know both versions of them all, and be able to recognize and understand both kinds when reading other people's code. How does it improve the language to be so top-heavy and chock-full of obscure unreadable arbitrary syntax, 95% of which nobody every uses, but that everyone still needs to memorize and understand in order to read? That's exactly why Perl's philosophy of TMTOWTDI is intellectually bankrupt, and encourages write-only "creative snowflake" Perl code that's an inscrutable, unreadable, unmaintainable nightmare. The language isn't any better for having $" as a shortcut for $LIST_SEPARATOR (or $LIST_SEPARATOR as a mnemonic for $", depending on how you look at it), because now you have to learn twice as many things, and all that duplicated effort and mental stress and syntactic surface area doesn't make it any more powerful or easy to use, has absolutely no tangible benefits, only pointless costs, and makes it twice as hard to learn and read and maintain Perl code.

Grinnz 7y ago
Memorizing everything is not required, there is reference documentation. Learning the language would familiarize you with the important syntax, as with any language, and all languages have such oddities, they just appear in different forms.
- DonHopkins 7y ago
  No, all languages do not have such oddities. That's a false equivalence. And it doesn't excuse Perl's bad design or justify its intellectually bankrupt TMTOWTDI philosophy. Python's philosophy of "There should be one — and preferably only one — obvious way to do it" is diametrically opposed to TMTOWTDI, and Python's vastly more successful than Perl because it's much easier to learn, read, use and maintain. Can you name any schools teaching Perl as a first programming language, like so many teach Python? Forcing you to look punctuation up in the reference documentation is even worse than having to memorize it. Pausing from reading code to look up punctuation in the manual slows you down by orders of magnitude, and knocks you out of the flow. Random punctuation is not easily memorizable or mnemonic or searchable or indexable. You also have to have memorized the ASCII order of punctuation to index through the manual, which is different than how punctuation is arranged on the keyboard! Is a comma or underscore less than or greater than a double quote or back quote, and why should I care? How exactly do double quotes imply "LIST_SEPARATOR"? Shouldn't it be $, because comma is the standard list separator, instead of $" which looks like it could be "STRING_DELIMITER", or does $, mean something completely different? And how am I supposed to remember all that? It's totally arbitrary, annoying, and off-putting. Now tell me how Perl is any more powerful by having twice the number of ways necessary to express the every concept? Perl pointlessly has twice as many inane pieces of syntax to memorize or look up, to do the same number of things. There is no upside to that, only cost. And that's one reason Perl is dead.
  - cestith 7y ago
    $, is the output field separator, which in short or English form is very rarely used. Generally people explicitly determine what they want on output with something like sprintf(), printf(), or join() rather than sending a list to print(). Just like a natural language, there's a tiny pidgin subset you can learn and use to great effect. You then learn obscure vocabulary on the rare occasion you come across it. If you have had to maintain code by people who intentionally obfuscate it, you should be at least as angry with those people as with the designers of their tools.