Unless I'm using it repeatedly in some code, I never expect to remember the order of the 9-element list returned by localtime. The doco clearly provides that information; it also tells me that $wday is a zero-based index with 0 representing Sunday (which is something else I don't expect to have committed to memory).

There are lots of other functions, which I use infrequently, and return long lists; e.g. getgrent (4); getpwent (10); stat (13). I find looking these up is a lot quicker, and far less error-prone, than code trial-and-error: 6 was correct for [6] as it was Saturday; 6 could have easily been returned for a number of other indices depending on the date and time.

Having perle to hand, means I never have to remember to type the -M options nor expend the time and energy to actually type them. Furthermore, warnings is a lexically-scoped pragma; I can turn it off wholly or partly anywhere in my code (neither -w nor -W provides that freedom).

Any piece of example code that I've posted here as

perl -E '... single line ...'
[download]

or

perl -E '
    ... code ...
    ... on ...
    ... multiple ...
    ... lines ...
'
[download]

would have been tested with perle instead of perl -E beforehand. That way, I can be more confident about the validity of the code, without needing to provide an explanation of perle.

I also use perle for personal work which never gets published. I find it incredibly useful and have no hesitation in recommending you do something similar (i.e. an MSWin equivalent).

By the way, it's unary not unitary (which means something different). In terms of operators:

• + operand1 (unary)
• operand1 + operand2 (binary)
• condition ? true_value : false_value (ternary)

perlop has multiple examples of these terms.