Hacker News Reader

Comment by nocman | Hacker News Reader

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.

View on HN

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.

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.

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.

$, 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.

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

You have to be able to understand that if it's a two character variable of all punctuation you may need to look it up to figure out what it is. Typing `!perldoc $"` into duck duck go sent me to https://perldoc.pl/variables/$%22 ... which is roughly equivalent to `!g [docker error]` which I already do all day long.

    $ perldoc '$'
    No documentation found for "$"

I hope perldoc search improved on Perl6, because it only used to match section titles, and none of the line noise vars are there.

(Yes, after a while one should learn yo search for the section that explains all the vars, at least if he's coding Perl all day. But it's a ton of useless trivia to keep in mind anyway.)

The correct invocation to search for a variable named $" (not $) is perldoc -v '$"', which the variable search on perldoc.pl was modeled after.

A glance at "man perldoc" (or "perldoc perldoc") will tell you of the very useful other switches, such as -f and -q.

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.

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.

Reply on news.ycombinator.com