On the scoring of PHP and Perl
J B's post is commonly linked back to in defense of a particular scoring, most often for Perl. Although I agree with his post in large part, there are a couple points that I am not in complete agreement with, or that I believe were not adequately addressed.
As a foreword, I consider myself a fairly active member of this site, and the majority of my submissions have been in either PHP or Perl. At the time of writing, I have 92 submissions in Perl (20 accepted, 72 unaccepted), and 66 in PHP (11 accepted, 55 unaccepted). As far as I can tell, I am the most prolific contributor of either language. I therefore have a vested interest in a fair and consistent scoring of these two languages in particular.
1. Programs are Programs
This is a point that I believe J B failed to adequately address. Both PHP and Perl support saving code to a file and executing it, and this is in fact the primary usage. The shortest invocation of each is
php program.php and
perl program.pl respectively. If the question specifically asks for a program, as most do, it is my opinion that the supplied code must be executable in this manner. If the code cannot be run in this way (e.g. it can only be run from the command line), it is, in my opinion, not a program.
To be clear, this would restrict the Perl options
-E, and the PHP options
-R from any challenges requiring a program.
2. Every Additional Command Line Byte Counts
"I count those as a difference in character count to the shortest equivalent invocation without them."
- J B
I am in complete agreement with this, although I have not to this point been following it (and instead counting only "functional" bytes, i.e.
[^- ]). This would mean, for example, that
-p as in
perl -p program.pl should be counted 3 bytes heavier than its shortest invocation
perl program.pl, and
-pl as 4 bytes, etc. This is entirely consistent with the "Unofficial Official" Perl Golf Rules, and all entries in the Perl Golf History Book were scored in this way.
For challenges where a program is not required, the same rule should apply: every additional byte is counted. For example, the difference between shortest invocation
perl -e'code' and
perl -pe'code' is only one, and therefore
-p should be counted as one in this instance.
I also believe that
-M5.01 (and it's more verbose equivalent
-M5.010) should be scored in the same way, just as one would score
-Mntheory. Of course, if a program isn't required,
-E is no longer than
-e, and therefore should be "free" in this sense. J B argues that this option falls under "options to bring the language level to a specific point", as would, for example
gcc -std=c99. I disagree. The closest equivalent I can think of is Python's
from __future__ import, which I also don't think should be free. If you're writing code for Python 2, you should be writing for Python 2, taking the good with the bad, and not picking and choosing Python 3 features that could make your code shorter. As an example, this solution could be one byte shorter with a "free"
from __future__ import division, so that
x could be initialized to
1, rather than
I feel the same way for Perl.
use 5.10 is short-hand for
use feature qw(say state switch), all of which were back-ported from Perl 6.
3. Assume Default Settings
4. Default Encoding
Some online interpreters, for example ideone.com, will silently convert any input to UTF-8, potentially invalidating an otherwise valid solution. In PHP, for example,
~õ is a common shortcut for
"\n". It is my suggestion that the encoding be assumed as ISO-8859-1, unless otherwise specified. Solutions using multibyte encodings should be counted in bytes, and not characters.
5. Prefer Shebangs
This is more of a suggestion for style rather than scoring. For interpreters that allow post-hoc command line options via shebang (e.g. Perl and Ruby), this should be the preferred way to convey this information. There are two primary advantages. For users unfamiliar with the language, and its available command line options, when copy-pasted the code will still work "as is." For others, it will allow them to immediately see what the program does and how it works, even when scanning quickly, without having to stop and read the accompanying description.